WordPress / wporg-mu-plugins

Development of the Global Header and other mu-plugins used on WordPress.org.
60 stars 29 forks source link

Login/Register links, move to secondary navigation, remove adminbar #647

Open jasmussen opened 5 months ago

jasmussen commented 5 months ago

Now that the majority of sections across WordPress.org are updated, with a consistent header and secondary navigation bar, the sections of the site that—when logged out—show the WordPress adminbar, stand out. Those sections feature the adminbar only to offer login and register links, features which are not going to be relevant to the majority of visitors. The adminbar appearing causes both a layout shift, and gives undue prominence to links that are only situationally relevant to a minority of users:

Here's a recent audit of sections that feature the adminbar, showing a ❌ next to the sections that still include it:

i2 before

From this audit, we can extract the following sections still showing the adminbar, purely to support login/register links:

For those pages, there appears to be plenty of room to simply add a "Sign-in" link to the secondary navigation toolbar, like so:

i2 key changes

Doing so would both avoid the layout shift of the adminbar appearing or disappearing as you navigate across the site, and it would also make the sign in link secondary to the primary navigation, thus implying its context implicitly: I can sign in here to submit a theme.

When you click "Sign in" you see this page:

login

On that page, if you click "Create an account" you see this page:

register

Here's a full flow of the suggested changes:

i2 flow

Note, this flow includes the mockup for a refreshed login page (#241). That's a separate effort.

Figma.

When you are successfully logged in, show the adminbar across the whole site. Shown here, logged out, and in, for the Forums section:

i2 logged out and in alt

Summary:


Issue updated Aug 21.

Previous version of this issue ↓ Doing a quick review of navigating across all sections of WordPress.org this morning, and noticing a jump in the top navigation for every page that shows the adminbar. It seems that in every case where the adminbar shows, it exists to surface the login and register links. Here are pages that show the adminbar for this reason. News: ![news](https://github.com/WordPress/wporg-mu-plugins/assets/1204802/ba945188-ef3a-4bdd-a590-0f83d149b89d) Themes: ![themes](https://github.com/WordPress/wporg-mu-plugins/assets/1204802/7c3d45f1-33eb-4f21-93bf-9e5b25987e23) Plugins: ![plugins](https://github.com/WordPress/wporg-mu-plugins/assets/1204802/5885eb03-2d7d-4a1f-aad7-976704979737) Patterns: ![patterns](https://github.com/WordPress/wporg-mu-plugins/assets/1204802/883d8696-56e6-49d8-9a1b-0c4965aa6b82) Learn: ![learn](https://github.com/WordPress/wporg-mu-plugins/assets/1204802/60206db3-07f9-41cf-aab3-fefd2cd892c6) Forums: ![forums](https://github.com/WordPress/wporg-mu-plugins/assets/1204802/45009b26-23f4-43c8-a493-e2333788fc68) Make (both landing and all P2s): ![make](https://github.com/WordPress/wporg-mu-plugins/assets/1204802/707231d7-64a3-4cf1-9edf-d5c2f4a0a6df) Photos: ![photos](https://github.com/WordPress/wporg-mu-plugins/assets/1204802/67efb6b0-e4d5-4865-ae79-1399c5c97d07) FFTF: ![fftf](https://github.com/WordPress/wporg-mu-plugins/assets/1204802/e4699b72-a6b6-4037-9961-431de968f12c) Also for reference, when you click "Log In" you see this page: ![login](https://github.com/WordPress/wporg-mu-plugins/assets/1204802/2687c5f3-1b8d-43b7-a16e-e20274b8ca63) When you click "Register" you see this page: ![register](https://github.com/WordPress/wporg-mu-plugins/assets/1204802/e8a5544d-6b96-4fe8-a9c2-3f40b55386b6) In all these cases, those login/register links exist in context of those pages either being editable by contributors, or places where people can submit themes patterns, or otherwise. Those are all page-contextual actions, however, which suggest hierarchically those links should exist in context of the page, rather than in context of _the site_ as they do when they are the first thing on the page. Outside of fixing the hierarchy, addressing the jump is especially important on mobile, where those buttons get extra prominence and height: ![mobile news](https://github.com/WordPress/wporg-mu-plugins/assets/1204802/21d96550-d98c-4227-afd4-6e133b69ab24) **Suggestions** * Can we remove the log-in links and adminbar from Five for the Future? It's not clear why it needs to be there at all. * Move all login and register links into a secondary navigation bar. Mockup showing a single unified Log in/Register link: login register links This single link leans into WordPress/wporg-main-2022#241, which puts a "Register" link right on the login page that'll take you there: login-register-page
dd32 commented 5 months ago

Can we remove the log-in links and adminbar from Five for the Future? It's not clear why it needs to be there at all.

Done. It's there because it's primarily for logged in users, as that's how you manage your pledge - but if you don't know how to login, probably not actively contributing.

jasmussen commented 5 months ago

Ah good note. To clarify, if you are logged in it's okay to show the adminbar across all sections. And in fact ideally we show it across all sections if you're logged in, so you don't get an inverse jump in that case of the adminbar disappearing.

tobifjellner commented 5 months ago

Is showing menu items like "my favorites" for not logged-in visitors desirable?

jasmussen commented 5 months ago

Is showing menu items like "my favorites" for not logged-in visitors desirable?

I'd think so, yes, it makes clear a benefit you get from logging in. Besides, clicking Favorites if logged in, would take you to a screen prompting you to do that.

ndiego commented 1 month ago

I wonder if we could explore something similar to the Amazon experience.

image

The login/register is combined with more info revealed in a dropdown, and it's placed in the primary header. This is tricky with the Navigation block, but might be worth exploring.

jasmussen commented 1 month ago

I've updated this issue based on a fresh audit of the WordPress.org site after the recent string of style refreshes, then collaborated with @fcoveram to leverage the new secondary navigation bar for a simple and claer sign-in link that's contextual to the pages that need it.

It's a big win that improves an increasingly frustrating aspect of the new experience, so I added a high priority to it.

I also opened WordPress/wporg-mu-plugins#646 to make the logo bigger, which pairs well with this change now that we're in the same space, code-wise! Penny for your thoughts?

keoshi commented 1 month ago

Wondering what's the rationale behind the switch from the “Log in” expression to “Sign in”.

Especially inconsistent in this flow where a “Sign in” link leads to a log in page with a “Log in” action:

When you click "Sign in" you see this page:

image

jasmussen commented 1 month ago

Good point. "Log in" can work equally well. The motivation for "Sign in" was to simply emphasize the link a bit more.

ryelle commented 1 month ago

For the Photo Directory & Make sites, it looks like your screenshots are not using the current site, but the redesign mockups. Should those…

  1. Wait for the redesign to apply, so they would keep the admin bar for now?
  2. Remove the admin bar, add sign in to the current "local nav", with the caveat that Photo Directory doesn't have a local nav on the homepage.
  3. Something else… (that isn't "do the redesign" 😅 )

These should be fine to update, no issues. It will require updating each theme, and disabling the Admin Bar plugin on each site.


These are lower priority or have other concerns

When you are successfully logged in, show the adminbar across the whole site.

We have some mu-plugins code which currently handles hiding it unless you have permissions, but that can easily be updated.

jasmussen commented 1 month ago

Doing it on themes, plugins, patterns, learn and forums would be a big step forward. We migth be able to wait for refreshes of Make and Photos, to ask, how hard would it be to add the new secondary navigation bar to those? A rough sketch could look like this:

i2, headers, with the not-refreshed sites

Though I recognize those secondary bars would need to disappear when you're logged in. A hacky alternative (rough sketch) could be this:

i2, headers, with the not-refreshed sites alt

Would either of those be feasible?

We have some mu-plugins code which currently handles hiding it unless you have permissions, but that can easily be updated.

The motivation is to remove the layout shift, so it'd be nice to show it across the whole site once logged in. That should also at least give you quick access to logging out, or editing your profile, even if you're on a page you don't have other permissions for.

Thank you for looking!

ryelle commented 1 month ago

Would either of those be feasible?

The second option would be more likely than adding the local nav without any other redesign updates, especially for Make. But a nav banner might be possible on the Photo Directory, it just wouldn't do the scrolling behavior that the others do.

The motivation is to remove the layout shift, so it'd be nice to show it across the whole site once logged in. That should also at least give you quick access to logging out, or editing your profile, even if you're on a page you don't have other permissions for.

Yes, I was saying we can do that.