[WP][UX] Simplify the various login pages so that they look less busy and dated (and provide a backwards-compatible opt-in)

[klonos]

Moving this part of the discussion out of #3309, in order to not derail the recent momentum and direction of that issue.

The most recent PR in that issue provided an option to suppress the layout (regions other than the main content region), which resulted to this:

After some feedback, a border was added around the login form:

I proposed to use 0.25rem solid #bbbbbc for the border in the login page, which is the same as the horizontal line used in the top-border of the footer in Basis (where Drop the dragon is sitting):

...I tried to find any other borders used in blocks etc. in Basis that we could mimic, but couldn't find anything else.

If I was to suggest further styling for the login pages in Basis, then it would be to consider wrapping the h1 site name in a div, and styling it similarly to the header in Basis:

...we could add the same background pattern as the one used in the hero block:

...or make it plain black/white if people think it's "too much":

In general, I am looking for more consistency with the Basis theme.

In order to be as backwards-compatible as possible, we can offer a flip switch in the UI, to allow the legacy-styled login pages to be used on existing sites, as contrib and custom themes are adapted to accommodate for the new design/templates. This is a screenshot of what was in the PR sandbox at the time of writing vs. what I am proposing:

The wording in labels and help texts needs further thought/improvement, however the current "Use tabs" and "Hide regions" are too techie and don't sound like a new feature. They also do not explicitly convey what you get before/after.

[klonos]

We should do some research on what is considered common UX practice, and consider a11y as well.

When it comes to popularity of the style of login pages, here's what some of the most commonly-used CMSes provide OOTB:

• Wordpress:
• Joomla:
• Typo 3:
• Magento:
• Craft CMS:
• Grav CMS (Admin plugin):

[klonos]

Started doing some research, and the following resources came up at the time of writing this:

• https://www.interaction-design.org/literature/article/login-screen
• https://blog.hubspot.com/website/login-screen
• https://medium.com/@fiona.chiaraviglio/best-practices-for-login-sign-up-from-a-ux-perspective-e5d14b6ffce0
• https://arounda.agency/blog/10-examples-of-login-page-design-and-best-practices
• https://uxdworld.com/2021/12/22/12-best-practices-for-sign-up-and-login-page-design
• https://wpamelia.com/login-page-design
• https://www.invisionapp.com/inside-design/login-page-design
• https://www.uxforthemasses.com/login-page
• https://www.imaginarycloud.com/blog/12-powerful-tips-for-sign-up-and-login-page-design/
• https://app.uxcel.com/courses/common-patterns/loginsignup-best-practices-854

There's a few common suggestions in all of these articles:

• [ ] keep it simple we need to work on this 🔨 🔧
• [x] keep it safe
  • we've got that in covered in core 👍🏼
  • we also offer customizable options for failed login attempts throttling (to minimize the impact of brute force attacks)
  • we provide sensible defaults that should work OOTB for most sites, so 0 configuration required.
• [x] clear errors/messages
  • we've got that in covered in core 👍🏼
  • we can file separate issues to improve UX as we discover potential problems or room for improvement ...we have been doing that for a while, for many user-facing elements
• [ ] indications for things like caps lock key being pressed we should explore that 🤔
• [x] separate login form vs. sign up form we've got that in covered in core 👍🏼
• [x] ask for email instead of username
  • we've got that in core 👍🏼
  • we provide option for both by default, but can be limited to only email 👍🏼
• [ ] provide social login options
  • sounds like something that people expect nowadays, but doesn't feel like something that should be in core
  • we've got some contrib projects that provide that - do they work? ...how popular are they?
  • we can consider promoting one such contrib project via the project browser or something (the goal being that people should be able to add that functionality quickly and with ease)
  • expose that as documentation or a blog article perhaps?
• [ ] remember returning visitors ("remember me" checkbox)
  • we should explore that 🤔
  • we should port any contrib that offers that functionality:
  • https://www.drupal.org/project/remember_me
  • https://www.drupal.org/project/persistent_login

[izmeez]

@klonos Thanks for sharing your research. While all the examples Wordpress, Joomla, Typo, Craft, Grav follow the same design template they do not appeal to me. They seem to be more a "plug" for the CMS itself not the site. My preference is for a login that integrates with the site. I think from an end user perspective a login that integrates with the site is a nicer UX.

[klonos]

All the UX research I have done so far suggests to "keep things simple" and "limit elements to the task at hand". When a user either intentionally clicks the "login" link from the home page of a site, or is redirected to the login form after trying to access a restricted section of the site, then the only task at hand is to log in - everything else is a distraction, which is not good UX.

In the login form, the only links that should be available are:

• context-specific links (forgot password, register account etc.)
• link to home page (can be the site logo that serves that purpose)
• a "back" or "cancel" link, if the trigger to lead to the form was a redirect

The only UX pattern that I've seen (not explicitly being recommended - just mentioned) that has a login form integrated with the rest of the site is to provide the login form in a sidebar (what in Backdrop can be achieved with the "Login" block). But if a "login" link has been explicitly clicked, then the sole focus and best UX/workflow is to limit page elements to the login action.

The above pattern made me think that opening the login form in a modal dialog, which pushes the rest of the site to the background and focuses on the form itself, should also be an acceptable UX.

[klonos]

They seem to be more a "plug" for the CMS itself not the site.

I'm assuming that that's because the screenshots are from "vanilla" installations. In Backdrop, we should be replacing the CMS logo with the actual site logo and name. It should be all about providing context to the person trying to log in that they are logging into the site - not promoting Backdrop in any way here.

...but perhaps we can consider adding a subtle "powered by Backdrop" link. If we decide to do that, then we should be respecting whether the "Powered by Backdrop" block has been removed from the default layout. In that case, we shouldn't be rendering anything related to the CMS.

[bugfolder]

The above pattern made me think that opening the login form in a modal dialog, which pushes the rest of the site to the background and focuses on the form itself, should also be an acceptable UX.

On a complex site I manage, there's a lot of members-only stuff, where an anonymous user sees text on a page that says something like "to access this stuff, please login and then return to this page." The link sends them to the login page with a destination=... query. If there were an easy way to put up a login modal dialog over the current page, so that they never have to leave whatever page they're on, that would be a big UX improvement. (Probably out of scope for this particular issue, which assumes a dedicated login page, but since you brought up the model dialog, I'll mention it.)

[klonos]

I think that we already have an issue for that @bugfolder ...or something similar to that at least 👀

[klonos]

...there you go: #2207 🙂

[yorkshire-pudding]

remember returning visitors ("remember me" checkbox) we should explore that 🤔

I think Backdrop already does that OOTB; as long as cookies remain it keeps the session alive for quite a while. In my experience, sites that offer that through a checkbox still require occasional logging in. If we want to keep simple, then why clutter with a checkbox that probably won't make any difference?

[klonos]

I think Backdrop already does that OOTB; ...

Yes, it does. And it is a security concern. The default should be to expose it as an option, with help text that says "Do not tick this if you are on a shared computer". (this feels like a separate issue though)

... If we want to keep simple, then why clutter with a checkbox that probably won't make any difference?

As I said, security concern. It can be optional (but denoted as recommended), and I would like to include it in #3624 as well.

[docwilmot]

Here's an attempt to accomplish this with layouts.

Borrowed code from @klonos https://github.com/backdrop/backdrop-issues/issues/6569 and @sbgraphicdesign https://github.com/sbgraphicdesign/Backdrop-Custom-Login-Pages

[klonos]

Thank you once again @docwilmot! 🙏🏼 ❤️ ...still a few missing bits from other issues/PRs, as well as some pending decisions/consensus, but I personally like where this is going 👍🏼

I know that @jenlampton has objections to adding another default layout, but I find it a reasonable/acceptable alternative (in #3309, some people expressed concerns when it comes to suppressing the layout in order to achieve this design). We can discuss that further in the next UX/design or dev meeting.

Other than that:

• I like the fact that we are using a layout that allows for optional header/footer blocks, in case people want to add something there.
• Should we also allow left/right regions? ...on that: I realize that we need some customizations in order to place the form in the center of the page, but do we really need a new template? Not an objection - just trying to understand the limitations that lead to that decision is all.
• If we do end up with a new template, I'd be happy to provide an icon for it (although it was suggested that we should replace those icons with SVGs, so we'll see)
• The option to replace the horizontal tabs with links that will come in with #3309 is one missing piece of the puzzle.
• Adding some theming for Basis will be required ...as well as for Seven, in the odd case that it is being used as the frontend theme (intranet sites etc.).
• We need the logo added above the form, and it also needs to be a link to the home page of the site. This would server two purposes:
  • UX, since we are removing the breadcrumbs that provide a link to the home page
  • Site branding/identification (people need to know where they are logging into)
• This design needs to be opt-in, in order to not break existing sites.
• We'll need telemetry, as it would help us see if this is what people prefer. Then we can make this the default in Backdrop 2.0.
• Should it be the "Login" block explicitly that is added by default to that layout? (instead of the "Main page content" block)
• I tried adding a custom header and footer block in the respective regions, and the site design reverted to the old style, which is good 👍🏼 ...but when I moved these blocks into the "MAIN" region, they wouldn't be rendered 👎🏼 🐛

[klonos]

...but when I moved these blocks into the "MAIN" region, they wouldn't be rendered 👎🏼 🐛

They are if you clear caches. Ideally we'd be doing that when saving the "Manage blocks" form, and only be clearing specific caches if possible.

[docwilmot]

as well as some pending decisions/consensus ... I know that @jenlampton has objections to adding another default layout

I hope someone could mention it at a Thursday meeting so we can get some consensus.

Should we also allow left/right regions?

It just a template; if users want more regions they can use another layout template, or modify this one.

Adding some theming for Basis will be required ...as well as for Seven, in the odd case that it is being used as the frontend theme (intranet sites etc.).

We should actually need to add styles for all core themes

We need the logo added above the form, and it also needs to be a link to the home page of the site.

I think the ideal is to design a new Login Page Header Block with itself a template.

This design needs to be opt-in, in order to not break existing sites.

Its a layout; so users can just use the same template as the default, or whatever they like, if they don't want a special login page. For this PR we'd add an update hook to set the Login Page Layout to use the default template and blocks (also check if the existing site has overridden the login pages and use that template instead.

Should it be the "Login" block explicitly that is added by default to that layout? (instead of the "Main page content" block)

No, login block doesnt have password reset and new account pages.

when I moved these blocks into the "MAIN" region, they wouldn't be rendered

Pages are cached for anonymous by default, I forgot. THats fixed now.

[klonos]

I hope someone could mention it at a Thursday meeting so we can get some consensus.

Will do 👍🏼

It just a template; if users want more regions they can use another layout template, or modify this one.

Fair enough 👍🏼 ...I need to check if using a flexible template works with the centering of the form and all (perhaps all it takes is adding a CSS class or something).

I think the ideal is to design a new Login Page Header Block with itself a template.

Why not use an instance of the existing "Header block" block? That block already has settings for showing the site logo/name/slogan, and it works (although need to address positioning of the horizontal tabs):

Its a layout; so users can just use the same template as the default, or whatever they like, if they don't want a special login page. For this PR we'd add an update hook to set the Login Page Layout to use the default template and blocks (also check if the existing site has overridden the login pages and use that template instead.

I like that approach 👍🏼 ...although, perhaps we can have the layout be created and be disabled by default (on both existing and new sites for now). Then later on, if we have telemetry data to suggest that the majority of sites are using the simplified layout, we can have it be enabled by default on new sites (still disabled on existing sites).

No, login block doesnt have password reset and new account pages.

Fair enough 👍🏼 ...although that sounds like an oversight 🤔 (separate, follow-up issue though).

Pages are cached for anonymous by default, I forgot. THats fixed now.

It is fixed indeed 👍🏼 ...as an added check, perhaps we should be clearing caches when the site name/logo/slogan change in /admin/config/system/site-information. I tested adding the "Header block", and that got updated straight away - but when I updated the site name/slogan, it took another cache clear for the changes to take.

I've also left a couple of comments in the PR for consideration. Thinking that perhaps we should introduce a login context and be using that.

[klonos]

@irinaz shared this on LinkedIn (thanks 🙏🏼 ), which I found a good read, and relevant to this issue here: https://matthewstrom.com/writing/ui-density

[klonos]

@docwilmot not sure if you watched the recording from the dev meeting - I brought this issue up, but we were missing people to make a decision and move this forward. I'll make sure to bring it up during next week's dev meeting too.

[jenlampton]

First, 💯 on this issue. I made similar changes to the Borg theme specifically because I wanted Backdrop's login page to feel less Drupally. This goes much further :)

There is value to maintaining a site's branding (not CMS branding) on the log-in page so the current behavior should be preserved. However, having CMS branding there by default will be better for Backdrop -- if we do it right -- and I expect that's why many of the other examples show their own Branding there instead of anything to do with the sites themselves.

As far as implementation:

• I have concerns about adding a new Layout in core mostly because layouts are already confusing, and the more stuff we add to the Layouts listing page, the more overwhelming the layout system is for people seeing it for the first time. (It will increase the UI density on the Layout listing page, in order to decrease the UI density on the log-in page.)

• I don't want to add a new core layout template. The same goal can be accomplished using the Boxton layout and some additional CSS on these pages, especially now that we have a new way to identify login-specific pages. (We could use that to add a new body class!) New core layout templates should only be added when we need different regions, but the regions here are not any different, we just don't have blocks in most of them :)

• I do think it's important to include the new "Login pages" context for Layouts, since that will enable everyone to do whatever they want for these pages - be it the current behavior, new visibility rules for blocks, a new layout, or even a new layout template.

• That said, I'd love to have this login experience OOTB, and I think we can probably do it with a single backwards-compatible setting. A checkbox called something like "Simplify login experience" that would trigger these "Login pages" to bypass the layout system entirely, and render the login block similarly to how content is rendered in modals. (If we do include the "Simplify login experience" option, we'll also need to add sufficient warnings if someone has that setting enabled but is also trying to use layouts to change that experience.)

[docwilmot]

A checkbox called something like "Simplify login experience" that would trigger these "Login pages" to bypass the layout system entirely

So https://github.com/backdrop/backdrop/pull/4750 then?

[klonos]

This was discussed during the Design/UX meeting today, at 47:28 into the recording. Here: https://youtu.be/l2SAcL907AQ?t=2848

[docwilmot]

@jenlampton sounds like suppressing layouts is a preference, but I think there was quite a bit of negative reaction to suppressing layouts on the related PR, although I still think is the better option as per this comment.

@jenlampton am I misinterpreting your comments?

Eveeryone else change their mind toward accepting suppressing layouts? Curious how this will swing.

[klonos]

Eveeryone else change their mind toward accepting suppressing layouts?

I never had any real objection to that. I'm fine either way and think that the most value is for the end-feature to become available. Personally, I prefer(ed?) the separate layout solution for the reason that it is easier for people to tweak things that are pre-built for them, rather than creating something from scratch or introducing something "magic" (trying to explain that this is a layout, but not a layout, because it is being suppressed etc.).

My 2c

[olafgrabienski]

@docwilmot I don't think everyone else changed their mind. Personally, I'm still in favor to provide a layout for the login pages. That said, I also see the disadvantage of yet another layout, and looking at @jenlampton's third bullet point, a custom layout based approach could however become more powerful than before. Conclusion: I'm also fine with a "Simplify login experience" option, as long as I'm free to choose a layout based solution for some of my sites.

[yorkshire-pudding]

@docwilmot I don't think everyone else changed their mind. Personally, I'm still in favor to provide a layout for the login pages. That said, I also see the disadvantage of yet another layout, and looking at @jenlampton's third bullet point, a custom layout based approach could however become more powerful than before. Conclusion: I'm also fine with a "Simplify login experience" option, as long as I'm free to choose a layout based solution for some of my sites.

+1 - I'm thinking the same - don't mind as long I can still use layouts.

[docwilmot]

Added some Seven styles to the layout suppress version.