[UX] Simplify various login pages so that they look nice.

[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.

Avocate: @docwilmot

[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 🔨 🔧
• 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.
• 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 🤔
• separate login form vs. sign up form
  we've got that in covered in core 👍🏼
• 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 #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 [WP][UX] Remove "tabs" from log-in, register, and password reset pages. #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 backdrop/backdrop#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.

[quicksketch]

I'm working on the test coverage and headings.

[quicksketch]

backdrop/backdrop#4957 now includes test coverage for the new hooks and uses an <h1> for the page title.

[herbdool]

Looks good to me! I've tested and reviewed the changes. Tests passing.

The only thing left for a follow-up now is "Handle the theme-switch-by-config-or-UI".

[indigoxela]

Perfect, all my (small) concerns addressed. Also RTBC from my side.

We'll create an issue for the theme switch discussion proposed by @herbdool

And maybe @olafgrabienski wants to further discuss the optimal logo dimensions?

Neither of those needs to delay the merge here.

[quicksketch]

Woo! Yay thank you @indigoxela! I wanted another review before merging. Thank you so much for providing many rounds of feedback on this pull request (whomever was working on it)!

I have merged backdrop/backdrop#4957 into 1.x for 1.30.0! What an incredible improvement in our out-of-box experience. Moving forward, I imagine nearly all sites will prefer this new simplified system; unless they are specifically a community or member-based site (i.e. non-admins logging). And then those users can enjoy the new "tab-less" design. And of course it's backwards-compatible with the current (admittedly very poor) login experience.

This could probably use a change record, despite not being an "API change", having a place to document use of the new hooks would be good.

Big list of thank you's for this one: First and foremost, @docwilmot!! What an amazing effort to continuously try new solutions until one sticks. Not only that, but I think you knocked out like 4 issues simultaneously with this. Thank you!!

But this was a huge team effort!

• @argiepiano came in not only with frequent technical direction, but then the new cleaner solution and what became the final PR!
• @herbdool with constant reviews and directly addressing feedback in the pull requests. We really ping-ponged this to the finish!
• @olafgrabienski for testing different themes and continuously thoughtful feedback.
• @stpaultim for herding the cats as usual, finding what's holding things up and directing focus.
• @bugfolder for feedback and Civi testing.
• @indigoxela (again) for all the reviews! I think I had a 100% nightly review rate from you. I go to sleep and there's always feedback in the morning!
• @klonos for the original suggestion and extensive existing solution research. That really helped guide our solution here!
• @izmeez, @yorkshire-pudding and @jenlampton for jumping in with feedback.

Overall, really grateful for our amazing community working together to make Backdrop friendlier and easier. Thank you everyone!

backdrop/backdrop@2812d65 by @docwilmot, @argiepiano, @herbdool, @indigoxela, @quicksketch, @olafgrabienski, @klonos, @stpaultim, @bugfolder, @izmeez, @jenlampton, and @yorkshire-pudding.

[indigoxela]

Follow-up created in #6799 - issue description needs some elaboration.

I go to sleep and there's always feedback in the morning!

😂 timezone magic. 🪄

This issue and PR was a great demonstration of Backdrop CMS teamwork. 🎉

[herbdool]

Here's what it looks like in Gin. Pretty good.