Untangle Admin Bar

[jameskoster]

Note

The following mockups arose from the discourse in this issue. Please read the full discussion for additional context

WordPress logo menu

• Add link to Sites dashboard
• Add link to Domains dashboard
• Remove 'Documentation', 'Learn WordPress' and 'Feedback' links
• Update 'About WordPress' to include current version number

PRs

• Admin bar: add subitems to the top-left WP.com icon menu #100627
• Admin bar: add subitems to the top-left WP.com icon menu jetpack#42099

Account menu

• My Profile Edit Profile
• Edit Profile should link to profile.php
• Add "My WordPress.com account" button, linking to /me/account

PRs

• Admin bar: add "My WP.com Account" profile submenu jetpack#42058
• Admin bar: add "My WP.com Account" profile submenu #100545

General

• Remove logic to hide the Updates button
• Reader button should include visible text label on desktop

PRs

• Admin bar: bring back updates and comments menu #100645
• Admin bar: bring back updates and comments menu jetpack#42146
• Add label "Reader" to top nav on Atomic sites jetpack#42071

Original issue

As noted in p58i-ioo-p2 there are a couple of tasks relating to untangling the admin bar:

• Make the admin bar the same as core
• Remove the frontend actionbar

By adopting the core admin bar (replacing the calypso 'masterbar'), we'll need to migrate any features across. For the most part this seems trivial, in fact there is already close alignment:

wp-admin

Calypso

Migrate actionbar actions

By removing the frontend actionbar we'll need to find a home for the various actions therein:

Move to blocks

An idea discussed in #96202 is that important frontend visitor actions like 'Subscribe', 'Reblog', 'Comment', 'Copy short link' could be blocks. Indeed 'Subscribe' has already shipped using the Jetpack Subscribe block. This approach has a number of benefits;

1. Users have much more flexibility around the appearance of each action, effortlessly making them blend in with their general site aesthetic, customizing, repositioning, etc.
2. Users have granular control over which actions to include, rather than a single toggle for the entire action bar.
3. Thanks to block hooks we can conditionally add appropriate actions based on flags triggered during onboarding. E.g. only include the 'Subscribe' block if the site includes a blog.
4. Creates scope for enhancement down the road; perhaps Jetpack adds a 'Blog actions' block which is sticky (with positioning options) and includes the relevant actions as child blocks.
5. As blocks, wporg and wpcom are inherently aligned.

Most importantly it enables the removal of the action bar on the frontend, reducing conceptual overlap with the admin bar.

Move to admin bar

Any actions that don't make sense as blocks could move to the admin bar. Actions for which we intend to create blocks could also move in the short term.

[github-actions]

OpenAI suggested the following labels for this issue:

• [Feature Group] Accessibility & Navigation: The issue discusses the navigation elements within the interface, namely the Action Bar and Admin Bar.
• [Feature] Action Bar: The issue specifically mentions 'Action Bar', suggesting changes or considerations regarding its design and functionality.
• [Feature] Calypso & wp-admin Navigation: The exploration of consolidating the Action Bar and Admin Bar relates to the navigation experience in both Calypso and wp-admin.

[Copons]

@jameskoster I've seen that Zenith is working on the Action Bar: #98042

Would it make sense to make this issue specifically about the Admin Bar (part of Untangling), rather than mixing both in the same task? 🤔

[jameskoster]

Yeah there's a lot going on here, all closely related.

#98042 seems to be about fixing issues with the Action Bar as it exists today.

This issue is more about the following points outlined in https://wp.me/p58i-ioo:

• Make the admin bar the same as core
• Remove the frontend actionbar

In other words; determine which actionbar features should be consolidated with the admin bar. I updated the OP to better reflect this.

[ciampo]

I'd like to add some considerations and propose an alternative approach.

As part of my initial explorations, while re-acquainting with Calypso, I noticed that the current implementation of the Masterbar is far from ideal: even if it visually resembles the admin bar from WP-admin, the underlying markup, semantics and even mouse/keybaord interactions are different.

So far, I focused on fixing the biggest offender while keeping the amount of code changes to a minimum.

I was wondering if we could ever take into account an alternative approach, where Calypso doesn't try to imitate the WordPress admin bar and instead comes up with a new dedicated interface:

• it allows us to rethink the information architecture, potentially incorporating the action bar, and adapting to the new "wp-admin" vs "calypso" split;
• the new masterbar would adopt a different UI, more in line with "calypso"'s
• by rebuilding the masterbar, we would be doing it in an accessible way from the start, inherently solving the problems afflicting it today

(side note: the WordPress admin bar has also a lot left to improve in terms of accessibility, semantics and UX).