Plugins: Don't show the adminbar

[jasmussen]

It's okay to show the adminbar when you're logged in. But we should not show it logged out:

The login and register links can usefully be shown when you enter a "Submit a plugin" flow. As part of https://github.com/WordPress/wporg-mu-plugins/issues/647 we can also show them in secondary navigation.

[ryelle]

Should we remove the admin bar for logged-out/no-site-permissions users now, or does this require https://github.com/WordPress/wporg-mu-plugins/issues/647 to be in place first?

[jasmussen]

I would lean towards yes. Can you elaborate on "no-site-permissions users", however? If a user is logged out, how would we know their permissions?

But the main instinct for showing this: the login/register links are very prominent and not well contextual. There's a "Submit a plugin" flow already, that features a log-in link, so if you are logged out and need to log in, there's a flow for that, even before we can finish the larger piece.

[ryelle]

Can you elaborate on "no-site-permissions users"

Logged out users are a separate case. Logged-in users are users with a WordPress.org account, but that doesn't mean they have permission to do anything on a given site. Most people are "no site permissions" users, though that's different for different sites. For example, someone might have permission to post on make/core, but can't view the plugin moderation queue.

Put visually, here's the admin bar for the Plugin Directory for each of the 3:

"Logged out": Anonymous user, can only log in or register (those are two separate links).

"No site permissions": Logged in, your average user, has no actions on the site.

Logged in, this is my super admin account, but any moderator/author/etc would also have at lease some actions here. This is the one I think we need to keep, because these actions are useful.

But the main instinct for showing this: the login/register links are very prominent and not well contextual.

Honestly I think adding these links into the local navigation bar will make them more prominent & unexpected, but that's another discussion. In general, the things that require log in (viewing favorites, making submissions) do have "log in" links first (I've checked patterns, plugins, and themes).

[jasmussen]

Thank you for clarifying. The main thing is that the admin-bar works best as an affordance for logged-in users of a WordPress site, and so it's mainly the logged out users case we need to handle.

The problem with log-in links in that space is that it's hierarchically not the best page, suggesting global context rather than local. I know that's the case, but conceptually it isn't, and we want to avoid people thinking they need to log-in in order to use the site. I suspect they also feel less prominent probably because us WordPress users are trained to ignore the adminbar unless we need it. In this particular case, I'd agree with you that the submit/edit plugin flows is the most useful place to show log-in links. The secondary toolbar can work in addition to that, and feels worth a shot.

[StevenDufresne]

@jasmussen Can you summarize the expectations here for clarity?

[jasmussen]

Some of the challenges with the adminbar:

• It's usually an "I'm logged into WordPress" affordance. For those familiar, it might be perceived as just that, and fade into the background as a result — be perceived as admin-UI, not content-UI. So we can't really place links here that people aren't used to from their other WordPress installs. "Try the new theme" is one example of this.
• Related to the above context, it is also implied to be site wide-contextual, rather than per-section contextual. Even if sections of WP.org count as individual sites, conceptually it comes across as one, and it has a unified login.
• The majority of users won't need to log in. Those that do will likely do so in context of specific flows: I want to upload a theme, I want to upload a plugin, I want to comment in the forums.
• We don't want people to think they need to log in, in order to use the site, or download WordPress, plugins, or themes.
• Log-in and register links do not need to be present on all sections. And when the log-in and register links as part of the admin-bar show up in some sections, but not others, we get layout shifts of the main toolbar as you navigate across the site.
• The adminbar takes up 32px on desktop, 46px on mobile. Especially on mobile, this ends up taking up a lot of space.

That suggests a few things:

• Perhaps we shouldn't show the admin-bar on mobile, even if you're logged in.
• It may not be the best place to show login/register links, or any of the managerial links you'd log in to get access to (upload theme, plugin, edit profile, change password). All such links are likely best integrated into the content itself, in context of each section (for example #420). This would be especially important if we were to hide the adminbar on mobile, even for logged in users.
• By integrating log-in links into the flow of the content, we would not only contextualize them (you need to log-in to upload a plugin), but their prominence would be increased as a result. We would avoid layout shifts, and taking up too much space on mobile.

My suggestions would then be:

• Only ever show the adminbar for logged in users, on desktop. And when we do show it for logged in users, show it across the site to avoid layout shifts.
• Integrate log-in links in context of the sections that need it. Whether it's what's outlined in #420), or something just as part of the "submit a plugin/theme/pattern, write a P2" flows.

[StevenDufresne]

Thanks for the clarity @jasmussen. @ndiego Since most of that feedback applies across the site and is not specific to plugins, should we move this conversation to a different place?

[ndiego]

Yes, I think we can close this and address follow-ups for the site as a whole separately. https://github.com/WordPress/wporg-mu-plugins/issues/647 seems a good place to continue the discussion.