Make WordPress Core

Opened 5 weeks ago

Last modified 13 days ago

#65220 new enhancement

Toolbar: Show site title always even on mobile viewport, by moving shortcut menus under site menu

Reported by: fushar's profile fushar Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Toolbar Keywords: has-patch has-unit-tests
Focuses: ui, css Cc:

Description

Problem

On wp-admin pages in mobile resolution (<= 782px), when we have many sites (e.g. on a multi-site network), it's not easy to quickly identify which site we're currently working on, because the site title is only displayed in desktop viewport.

Proposed Solution

Show the site title in all resolutions. To make room for it:

  1. Move the "shortcut menus" (Updates, Comments, New, etc) as submenus under it. I believe it's a valid tradeoff. I feel it's more important to be able to see the site title, than having quick access to Comments / New. Also, on narrow resolutions, we already hide such icons progressively, e.g. this CSS (https://github.com/WordPress/wordpress-develop/blob/7938204d20159fa863e6d34af352bb7557524354/src/wp-includes/css/admin-bar.css#L1135-L1140)
  1. Move the command palette search icon to the top-secondary (right). The whole top-right nodes should cover the site title if it's too long.

Change History (5)

This ticket was mentioned in PR #11786 on WordPress/wordpress-develop by @fushar.


5 weeks ago
#1

  • Keywords has-patch has-unit-tests added

Trac ticket: https://core.trac.wordpress.org/ticket/65220

## Summary

We want to make the site title prominent even on mobile viewport. This helps users quickly identify which site they’re working on, even on smaller screens.

On mobile viewport width, we made the following changes:

  • To make room for the site title, hide the site/content-related "shortcut" menus (Updates, Comments, New etc) from the top level and move them under the site menu.
    • This is implemented by duplicating those shortcut menus, and showing/hiding them via CSS depending on the viewport size.
  • Move the command palette menu to the top-secondary area (right side).
    • This is also implemented by duplicating the menu as explained above.
  • Allow the main left nodes to overflow, while pinning the right-side secondary nodes using position: absolute and right: 0.
    • So, when the site title is long, it flows underneath the right nodes. To make the visual smoother, we add a subtle fade/blur effect to the left edge of the secondary nodes.
    • Note that plugins that show icons on mobile by overriding CSS could get pushed out of view. However, Core's contract is to only show its own nodes on mobile viewport:

https://github.com/WordPress/wordpress-develop/blob/556437068a54eefddff449c811ebad90bb53e968/src/wp-includes/css/admin-bar.css#L1013-L1016

## Screenshots

#### 600px < width <= 782px

Before After
https://github.com/user-attachments/assets/ea09d68b-f25d-45a5-a4fd-e6a25f60213b https://github.com/user-attachments/assets/ca357538-048f-4638-91bf-30d2386cffea
https://github.com/user-attachments/assets/18b8c394-f51d-4947-ae18-604c57d54a69

#### 400px < width <= 600px

Observe that there's a fade/blur effect that hides the right end of the site title if it's too long.

Before After
https://github.com/user-attachments/assets/8f3eb557-5593-4842-9da5-6143d5a3c318 https://github.com/user-attachments/assets/a2289cc7-4611-4cbf-8594-a12c8e7eea21

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 4.7
Used for: CSS and test suggestions.

#2 in reply to: ↑ description @westonruter
5 weeks ago

Replying to fushar:

Problem

On wp-admin pages in mobile resolution (<= 782px), when we have many sites (e.g. on a multi-site network), it's not easy to quickly identify which site we're currently working on, because the site title is only displayed in desktop viewport.

Isn't this what the browser's URL bar is for?

#3 @Joen
4 weeks ago

Appreciate the attention to the adminbar. It's gone unloved for quite a while, it's good to see some energy applied to it.

For this issue in particular, I like the general direction it's heading. It feels, paired with the other work you've done, like it's systematising the adminbar a bit; logo, site title, contextual actions, command palette, plugin actions, account/profile.

In this case, it does feel valid to me to hide many of the contextual actions on mobile to fit the site title. This is also in response to @westonruter who makes a good point about the browser URL bar. Some feedback I've seen in various support sessions over the years, where power-users had multiple WordPress installs and tabbed between them, then accidentally uploaded private information to the wrong WordPress site because there wasn't clear enough visual distinction between the tabs. It is for that reason I appreciate some attention to this.

However there are a couple of details to get right, which feel not quite right yet. Whether they need to happen as part of this issue or followups, I'll defer to more veteran core contributors. But coming to mind:

  1. Showing the site title helps, but showing a site logo would help even more. The "house" dashicon tells us nothing, and there's no reason that couldn't be the site logo instead. This would also be helpful in cases where we simply have to elide the site title in order to fit it.
  2. As a heavy WordPress user myself, I find myself not missing the plus button, or the comment button on mobile: I'd want to enter the dashboard proper in order to engage with that. But on the frontend, I might miss the Edit button. There may be a way, though spacings overall (not in this PR) to fit not only the command palette icon, but the contextual edit button, while still having both site logo and site title. This is not strongly felt, but it's the only button I might miss here. Putting it inside the submenus might also be fine in practice, so it can be a fine place to start.
  3. I'm missing the WordPress logo as a fix-point. This is almost certainly something to look at separately, but my mental appraoch to the adminbar is it's WordPress' answer to the Apple app-bar. Top of MacOS shows you the Apple logo, then contextual actions, a spacer, then the equivalent of plugins actions. Honestly the WordPress adminbar could/should be the same, and for that reason I'd not only want to retain the logo, but actually move it to the left of the burger menu. It's WordPress, it's always there, but the burger menu then collapses the contextual items, so hierarchically the menu doesn't shift around even on mobile.

What do you think?

Last edited 13 days ago by Joen (previous) (diff)

#4 @fushar
4 weeks ago

Showing the site title helps, but showing a site logo would help even more. The "house" dashicon tells us nothing, and there's no reason that couldn't be the site logo instead. This would also be helpful in cases where we simply have to elide the site title in order to fit it.

Yep! We have a separate issue for this here: https://core.trac.wordpress.org/ticket/65088

Honestly the WordPress adminbar could/should be the same, and for that reason I'd not only want to retain the logo, but actually move it to the left of the burger menu

I'm not sure I agree with this. On mobile, the hamburger menu opens/collapses the left sidebar. Wouldn't it be confusing if it's not the leftmost item that triggers the behavior?

#5 @lucasmdo
13 days ago

Showing the site title helps, but showing a site logo would help even more.

+1. The space is already there but with the home dashicon. The site icon would be way more beneficial indeed.

Putting it inside the submenus might also be fine in practice, so it can be a fine place to start.

Regarding adding the edit button, I'd start from here and check with more user data if we can move this to the front of the admin bar.

I'm missing the WordPress logo as a fix-point.

I agree with this direction. The logo should maintain the same position across the board. There are some areas where we don't have a sidebar menu available, causing the logo to shift its position (cc: @fushar).

Wouldn't it be confusing if it's not the leftmost item that triggers the behavior?

The "system" view (WordPress) and the app view (Site) will need another review in the future to clarify what belongs where. However, I wouldn’t change the behavior of the logo.

Note: See TracTickets for help on using tickets.