Proposal: Simplify WordPress Admin Navigation

[lessbloat]

About 3 months ago ​joen shared some rough mockups in Slack for proposed changes to the left sidebar navigation in core.

My goal below (with Joen’s blessing) is to resurface those mockups a little more publicly to see if we can gather some more feedback and potentially gain a little more momentum with this project.

Summary

The current sidebar has served us well for a long time. But with a few improvements, we can improve accessibility and usability, and allow it to better scale to extensions.

Challenges with the current design

• The hover/flyout menus are difficult to make accessible, and they do not scale well to mobile interfaces.
• There are a lot of top-level menu items that are rarely if ever used, contributing to cognitive weight by still being permanently visible.
• Given the additional menu items that plugin add, people are likely to end up with many menu items, despite a large number of them perhaps not being used that often.

Mockup

Important disclaimer: this is just an initial concept, it is subject to feedback and discussion and iterations:

Props to joen for coming up with this v1 concept.

Major Changes

• Flyout menus are replaced with accordion behavior. This scales all the way from mobile to desktop, and affords better accessibility.
• Menu is made 80px wider (240px vs. 160), affording a 14px minimum font size for all items, perhaps bigger icons in the future, more relaxed spacing, enhancing usability and accessibility.
• Sidebar is grouped in major sections, “Site”, “Design”, “Tools” and “Manage”.
• “Updates” are moved to a subsection of “Manage”, making Home a single item.
• Items related to content on your site (such as “Posts” and “Pages”) are moved under “Site”.
• Clicking major menu items just opens or closes the accordion, as opposed to go directly to the first subsection. This unifies the mobile and desktop behavior. You can keep the accordion open if you use it all the time (each click will save state, so you’ll see the same open/closed sections upon page refresh).
• All “Settings” subsections are moved under “Manage”, along with “Plugins & Blocks” and “Users”.
• Separators group major categories, like “Site” and “Design” together
• Dashboard is renamed “Home”, because all of WordPress is a Dashboard, and “Home” is where you can get an overview at a glance.

Custom Post Types & Taxonomies

• Custom Post Types show up below Pages (top item) and Posts (2nd item).
• A separator cordons these off from Media & Comments, which show content from all.
• Categories & Tags, and even custom taxonomies, are accessible from each section, as opposed to having a permanent presence in the sidebar. For example if you have a taxonomy called “Ingredients” tied to “Recipes”, you first click “Recipes”, and on the archive page you can manage existing Ingredients under a tab. The argument for putting them under this page is that taxonomies are usually added in the editor itself, and only managed on the archive pages.
• When you have custom post types, an additional, short, separator shows up below the post types.

Where's the "Add New" menu item?

One idea would be to make this permanently visible in the top toolbar.

Clicking this button produces a dropdown. By moving it there, you have a single destination to create new content, and we reduce the amount of tab-stops in the navigation menu, especially for sites with a lot of custom post types.

Related

Helen opened this ticket over 4 years ago. There are a number of different ideas and threads in that ticket. If someone decides that these two tickets should be merged, that is fine.

Feedback

Please keep in mind that this is just a very early, exploratory concept. Nothing here is set in stone. The goal of this exercise would be to improve the overall usability and accessibility of the left nav.

What thoughts, concerns, questions, and feedback do you have?

[lessbloat]

Menu Mockup

[lessbloat]

Add New Button Mockup

[johnbillion]

I'd like to see some exploration of what the menu could look like for the different default user roles, and whether it could behave differently for different roles.

For example the mockup above is what an Administrator sees, but an Editor or Author will mainly only see items relating to content (the items under Site), and a Contributor or Subscriber will see even fewer menu items.

How could that affect the appearance, grouping, and behaviour of the admin menu items?

There are a few admin menu plugins out there too that should be considered, for example OrganizeWP.

[lessbloat]

@johnbillion thanks for the comment. That's an excellent point. I'll circle back once I have something to share there.

[boemedia]

I’m really looking forward to changing the wp-admin menu, since it’s very confusing to a lot of users.

I like the mockups, they appear to have a very clean interface. However, first thing I didn’t understand was ‘Site’. ‘Content’ would be more logic from my perspective. Also, I never understood Settings and Tools. Now it’s tools and manage. I don’t see an extra need for the Tools menu item, would it be an idea to merge Tools & Settings into one ‘Manage/settings’ menu item?

[mapk]

Really great work! I gravitate quickly to the open and light feeling of the proposal and wonder if it's influencing my vote for this. First, I love the grouping here and feel this is a more logical IA than our current nav.

But secondly, it might help to view this proposal on the darker background, styled similarly to how it's expected to be implemented. This would provide a more apples-to-apples comparison with our existing nav.

[nrqsnchz]

I really like these explorations. It feels more simple and structured.

Maybe a crazy idea, but I was wondering what if the functionality of the top/admin bar could be integrated into this new sidebar. I think it could take us a step further into simplifying the UI and keeping everything contained in one place. I'll be the first one to say that we risk loosing the simplicity already accomplished on this exploration by adding more stuff to the sidebar, but I think that with this new structured IA, we can find ways to make it work.

[ChiefAlchemist]

To @johnbillion's point, the biggest problem isn't the width of the column or font-size, but the fact that it's OSFA (one size fits all). That is, there's no personalization. A 10-12+ item list (often longer for admins), most of which at any given moment are irrelevant, is taxing. There's no sense of hierarchy, priority or importance. On top of that, plugins / themes get to jam themselves in anywhere.

Aesthetics are an issue, but not really the crux of the (UX) friction(s) imho.

[afercia]

Related: #47124

[afercia]

Related: #47125.

[mrahmadawais]

I just wanted to say that I love the idea of making the entire admin layout simple. It's dated at best and we already have some sort of guideline via Gutenberg's design. Love the simple mockups.

Peace! ✌️

[Bueltge]

Short: really great idea and first proposal.

The menu items have currently not different enough capabilities to show the right one for each role. I mean this proposal is much easier to release with a enhancement of capabilities and changes on the menu items, so that the users only see, what she need. I'm also the author of the Admin-Organize-Plugin 'Adminimize' and the support is hard, because the users need more flexibility to remove menu items to simplify the admin area.

This proposal should also add different mockups in each role, so that we see how is the result in each role.

It would be great if we get a plugin to work and test on this idea.

[Horttcore]

A mock-up for the network administration menu a should also be made, as this new sidebar should also reflect these changes there.

[DeFries]

Very good first attempt at cleaning up the Dashboard menu! I strongly agree with @boemedia in that Content describes much better what is found in those specific submenus.

The mockup looks very light and clean – I suppose that comes with the territory if one's username is @lessbloat 😏– but I'm not sure about the grey background color in the mockup. If this is an indication for a new color scheme in the Dashboard, I feel like we'd be going back to pre MP6 times with regards to contrast. And I think that would be a shame.

[lessbloat]

Looks like this got some coverage recently which is exciting to see. I just wanted to drop a quick update to mention a few things:

1) A huge thanks to everyone who has already weighed in with feedback. Keep the feedback coming! This is all super helpful.

2) Next steps will be to share some additional mockups based on various roles (and yes even network admin! 😉), then to come up with a proof of concept plugin.

The mockup looks very light and clean – I suppose that comes with the territory if one's username is @lessbloat 😏– but I'm not sure about the grey background color in the mockup. If this is an indication for a new color scheme in the Dashboard, I feel like we'd be going back to pre MP6 times with regards to contrast. And I think that would be a shame.

3) @DeFries thanks for bringing that up. The light color was used to simply try and convey that these are early mockups. To clarify, there are no plans to change the colors in this particular proposal. 👍

[afercia]

The hover/flyout menus are difficult to make accessible

Seems to me this statement without any additional context comes a bit out of the blue. I'd like to hear more details about the specific accessibility concerns. Is there any data? Any user testing? While the current "flyouts" can be problematic for some accessibility needs, they're perfectly OK for other users. For example, screen reader users don't even perceive the "flyouts", as the menu sub-items can be normally navigated with Tabs or arrowing and they're all correctly announced.

Instead, accordions would make the interaction less intuitive and less natural, for the simple fact they require an additional click. Not to mention accordions would bring WordPress back to 3.2 🙂

On a general note, I'd tend to think any design proposal should be based on an in-depth analysis of the current functionalities/features and have solid basement in data and user testing. Ideally, this should happen before any visual mockup.

Which of the current admin menu functionalities and features should be kept? Which ones can be removed? For example, I don't see any analysis about the four different states the menu can have:

1. fully expanded (on large screens)
2. auto-folded (automatically kicks in at intermediate viewports)
3. collapsed (triggered by the user)
4. responsive

Worth also reminding plugins can add menu sections and items and this is based on a system of "priorities": basically plugins can add menu sections almost everywhere. I don't see this taken into considerations in the visual mockups nor in the proposed menu grouping.

A few more things I'd like to see before any visual mockups:

• a complete analysis of all the pending Trac tickets related to the admin menu: I see this as an essential step, in order to have a better idea of what the pending issues are, enhancements, feature requests, etc.
• in-depth user testing of the current admin menu
• the user testing group include users with accessibility needs
• analysis of the features/functionalities for multisite
• analysis of the features/functionalities with regards to capabilities
• mobile first

[Joen]

Iteration 2

[Joen]

Thank you everyone, for the feedback, and keep it coming. I would reiterate that these are still mockups, and subject both to feedback, and hopefully if things go well, user testing once we have a proof of concept plugin.

The mockups that I've created today address a few items of feedback, but not all your feedback:

• Various user roles from subscriber to administrator
• Network administration
• Custom post types

Feedback still to be addressed includes the menu titles, and some of the intricacies of how plugins can add menu items. The lack of mockups for these does not mean we won't get to it, just that we haven't yet. Specifically around how adding menu items works, it's possibly also worth discussing that after there's some consensus on the layout of the base user role menus, as well as the menu item titles.

https://core.trac.wordpress.org/attachment/ticket/47012/Iteration%202%20feedback.png

[TimothyBlynJacobs]

Categories & Tags, and even custom taxonomies, are accessible from each section, as opposed to having a permanent presence in the sidebar.

What does this mean in practice? And how will things work for custom sites that have far more than just the categories and tags menus inside a CPT menu.

Where's the "Add New" menu item?
One idea would be to make this permanently visible in the top toolbar.

Worth noting that we do have this today in the "+ New" admin bar, though I rarely see users actually use it ( anecdata ).

---

I'm also curious what this looks like with a lot of plugins on a site. In my experience, the stock WP install's menu isn't very overwhelming, but once you get a few plugins going that add their own menu items it starts getting quite complex. Plugins do a lot ( the need for their own menus and submenus is real ). But is there a way that this could be done better?

[Joen]

What does this mean in practice? And how will things work for custom sites that have far more than just the categories and tags menus inside a CPT menu.

Good thoughts, worth clarifying. I took a quick stab at a mockup to clarify what I meant by this. Lots of feedback to still tackle, but felt this one deserved to be taken a stab at first.

If you'd like to provide me with a particularly gnarly cpt menu configuration you'd like to see "converted" to this style, feel free to send it my way and I can make a mockup. It would make a good "acid test" of the layout.

[karmatosed]

As this has design I am for now going to remove that keyword as that focuses us all on feedback at this point. The keyword can be added back should it be needed.

[Horttcore]

Not everything is a "Site" so I would go for another wording.
"Content" seems the right word for me.

The main menu feels much more natural, but you have to click a lot more to come to ie. taxonomies.
I wouldn't add them as a main menu item though.

[nrqsnchz]

On the topic of collapsible menu items (accordions), we just did a usability test for WordPress.com's Calypso UI where the participant was a user with low vision and they found the collapsible menus clear and easy to navigate.

Being able to see the firt-level options at a glance and then dig into for more details helped with their vision.

[jameskoster]

Over the last few weeks I've spent a lot of time thinking about navigation in WooCommerce core, and how we might improve it. Needless to say I'm super excited to see this issue opened, because we've (Woo) essentially outgrown the structural affordances of the existing wp-admin menu system.

For any new navigation in WordPress core to be a success I think it is critical that we consider how third parties (plugins) should interface with it, and the impact those interactions would have, right from the beginning. I would argue that is the biggest failing of the existing navigation - it simply doesn't scale. Activate a few plugins and the left-hand menu grows out of control, and navigating it becomes an absolute nightmare.

The concepts shared in this issue so far would definitely be an improvement, and simplify the stock navigation, but I worry about how they scale.

Rough concepts

As a quick experiment, I added our proposed Woo menu items to the concepts shared above. Take a look: ​https://jameskoster.files.wordpress.com/2019/08/combo.png.

Now, it's not clear whether users would be able to expand all sections simultaneously like in the screenshot - but regardless - the menu gets very, very long when the WooCommerce menu items (purple) are added. And this is just a single plugin. Add a couple of other big players like BuddyPress or bbPress into the mix and things could get totally out of hand.

How could we solve this?

One solution we explored was to add an abstracted "meta menu" affordance that would enable plugins to provide their own contextual interfaces within wp-admin. This is probably easier to explain with a picture: ​https://jameskoster.files.wordpress.com/2019/08/meta.png.

The benefit here is that users always understand the context of their current workflow. To manage products it's clear you have to switch to Woo context. To draft a blog post it's clear you have to switch to "WordPress" context. We've usability tested a similar concept with very positive results.

These layers of context also provide a visual framework and guidance for plugin authors when they're considering where to add their menu items. Building a plugin that affects comments? Settings for that would be accessed through the "WordPress" menu. Building a payment gateway plugin for Woo? Settings for that would be accessed through the WooCommerce menu.

To be clear - I'm not saying this solution is perfect, or the direction we should definitely head in. But I think it presents an interesting point for discussion: Should plugins be integrating directly with the provided navigation menu, or should they have an affordance to break out into their own contextual area when necessary? I think that answering this question as early as possible will help shape the direction we move in with regards to design.

[DeFries]

@jameskoster would this mean in the case of WooCommerce that the actual content of WooCommerce, the products, would move over to the meta menu? Because that doesn't make a lot of sense to me personally. Content should be all the content.

[jameskoster]

@DeFries yes, that would be the case with this approach. The idea being to create the expectation that anything WooCommerce-related lives in the WooCommerce meta menu - whether it's a setting, content management, or more abstract features like order management.

This also allows us to tailor the menu order accordingly. For example - when you're managing your "site", content is likely going to feature very frequently in that workflow, so it makes sense for it to be the first menu item. But with an eCommerce store, inventory management is generally secondary to other tasks like checking reports, fulfilling orders, moderating reviews, marketing the store etc, so it makes sense for those sections to have more prominence than "content management".

Pictures don't always do these things justice so I threw a very rough CodePen together for y'all to play around with: ​https://s.codepen.io/jameskoster/debug/JjPGrYq

[DeFries]

Replying to jameskoster:

But with an eCommerce store, inventory management is generally secondary to other tasks like checking reports, fulfilling orders, moderating reviews, marketing the store etc, so it makes sense for those sections to have more prominence than "content management".

As much as I love the meta menu, menus that bring together contextual navigation, I feel like we'd be going the wrong direction. If we were to say on the one hand, "hey let's group everything content together", and on the other hand were to go "but not with plugin X" (where plugin X stands for WooCommerce in this example), how are we actually solving the bring content together in the default menu if we're not, in fact, using the default.

I mean, the way I see it, plugins like WooCommerce, BuddyPress, bbPress, event managers, job managers, etc, all revolve around having two things. Content and Settings/Workflows. I'd love to see us solve that specific problem, because the way I see it now, this proposal solves the original problem very nicely, but introduces a variant of the problem somewhere else.

Don't get me wrong, I very much like the thought behind the meta menu, I think that's a winner. I just don't think we're solving everything we could be, should be solving by using the example as is.

[jameskoster]

If we were to say on the one hand, "hey let's group everything content together", and on the other hand were to go "but not with plugin X" (where plugin X stands for WooCommerce in this example), how are we actually solving the bring content together in the default menu if we're not, in fact, using the default.

Just in case it wasn't clear, WooCommerce would not be the exception. I imagine all of those kinds of plugins you mention would introduce their own menu, just as WooCommerce does in the prototype I shared.

Another way to look at it: Content Management might just be the default "app" on fresh WP installs. It and other "apps" (e.g. Woo) run on top of WordPress as an operating system. We might abstract all of the general settings and options into a dedicated "system preferences" section, so the "Content Management app" feels more like an app, rather than a kernel. Something more like this: ​https://s.codepen.io/jameskoster/debug/rNBxpwY

this proposal solves the original problem very nicely, but introduces a variant of the problem somewhere else.

Am I right in understanding that you think we should explore enabling plugins to apply context within a single core menu system? Without the separate "meta level" menu? My concern with that is that as you add more plugins the lines simply blur too much. Although I must admit it's not something I've explored in any great detail just yet.

[lessbloat]

I love seeing activity on this thread again! This is exciting. 🤗

This is me attempting to distill things, but just to make sure we're on the same page, I thought I might attempt to clarify the concerns each of you are expressing.

@DeFries, what I'm hearing you say is that you're worried about there being a situation where some plugins reside in the default WP menu, while others (perhaps the more complicated plugins) are broken out into their own sections. Is that your primary concern?

@jameskoster it sounds like one of your primary concerns is around the scalability of having to force all links within a single core menu?

Is that right, or is there more?

[Horttcore]

The bigger problem in my opinion is, that users have to know where pluginX is adding its menu entries.
We have to search all level of menu entries to find the one we are looking for.
Instead of separating entries by plugins, we should more include them.
I like the idea of the meta level, but why not combing these two ideas?

[nrqsnchz]

The bigger problem in my opinion is, that users have to know where plugin X is adding its menu entries. We have to search all level of menu entries to find the one we are looking for.

Wouldn't @jameskoster's solution fix this? By compartmentalizing each plugin's options into their own meta level menus, the user wouldn't have to go hunting a loooong list of items to find the right one.

[DeFries]

Replying to jameskoster:

Just in case it wasn't clear, WooCommerce would not be the exception. I imagine all of those kinds of plugins you mention would introduce their own menu, just as WooCommerce does in the prototype I shared.

Yes, I interpreted it that way.

Content Management might just be the default "app" on fresh WP installs. It and other "apps" (e.g. Woo) run on top of WordPress as an operating system. We might abstract all of the general settings and options into a dedicated "system preferences" section, so the "Content Management app" feels more like an app, rather than a kernel.

Yes, this makes a lot of sense.

Am I right in understanding that you think we should explore enabling plugins to apply context within a single core menu system? Without the separate "meta level" menu?-

No, that's not what I meant. I think what you've shown so far is the way to go with what we're calling a "meta-level menu" and "Content Management app". I absolutely think this is the way to go.

Replying to lessbloat:

@DeFries, what I'm hearing you say is that you're worried about there being a situation where some plugins reside in the default WP menu, while others (perhaps the more complicated plugins) are broken out into their own sections. Is that your primary concern?

I'll try and answer both your questions here @jameskoster @lessbloat.
My concern here is if our goal is to simplify the way we currently have menus, and plugins adding extra menus to it, we need to be as consistent as we can. So, when a plugin adds a content component as WooCommerce does with its products, we should recognize the fact that we'll be teaching people to understand that the Content menu and its submenus are where they should be looking for all things related to content.

Whether they want to add a new blog post, a new page, that's where they should go. And that should also imply that new content within other content creating plugins should also be found exactly there.

So, for creating their new job post, new event, or new product, the location to start that process should be the Content menu. All the time. That's being consistent. Doing that for some plugins but not others, that's inconsistent and introducing a similar problem like we're having now in this new interpretation.

[jameskoster]

@DeFries gotcha, thanks for clarifying. I agree 100% on the consistency front. Another key element of a successful navigation re-imagination will be establishing this consistency through clearly designed guidelines for plugin authors to follow - something that is lacking right now.

Regarding your specific point about content, I'd love to get a better understanding of whether users identify things like products, jobs listings, events, timelines, etc as "content". I know we do, and that is what they are, technically speaking.

But in my experience with Woo, folks don't generally put products in the same organisational bucket as posts or pages. As above, many WooCommerce users don't even maintain a blog. So while grouping them together makes sense from a technical perspective, I wonder if it holds up when you observe the workflows.

I would also add that the "Content" label doesn't have to stick. If we were to introduce app-level meta navigation we'd have more space to break out of the "Content" menu and have separate items for Posts, Pages, Comments, etc. I updated the prototype: ​https://s.codepen.io/jameskoster/debug/rNBxpwY

---

Based on some of the comments re the meta menu it seems like there's an alternative to explore - rather than plugins adding top level items, they add sub-sections inside core sections. For example: ​https://s.codepen.io/jameskoster/debug/abodxLY

I have three main gripes with this approach:

1. The menus themselves get longer and longer as you add more plugins, which feels counterintuitive.
2. The pattern breaks down when a plugin needs to add a new top level section. Example; orders in WooCommerce. They need to be top level. But as soon as plugins start adding top level items in this concept you lose all context. It's not clear what plugins added what top level items. You essentially end up with a slightly more organised version of what we have now.
3. Kind of nuanced, but with this concept the user has to maintain two separate contexts in their head. For example, to edit products they need to be in "Content" context, then "WooCommerce" context. The cognitive load is doubled.

---

I just want to reiterate that I am clearly bringing a lot of Woo bias to the table here. And I know that we're not representative of the average plugin. Would love to hear thoughts of other plugin authors.

[Horttcore]

I'm totally with @DeFries.
I don't like this WooCommerce idea by moving their stuff to their own meta menu, as other plugins will do it also and we have the same problem in another level as now.

90% of the CMS sites I build just adding custom post type which will perfectly fit into the "Content" entry.
As for Woo I think products could also live in the content "section", but Orders and this stuff clearly belongs somewhere else.

I don't want to remember which plugin puts his stuff in which menu entry or meta level. It should be where to find which menu entries. I don't care which plugin is adding custom settings as long as there life under settings instead of their own meta level.

[DeFries]

Replying to jameskoster:

in my experience with Woo, folks don't generally put products in the same organisational bucket as posts or pages. As above, many WooCommerce users don't even maintain a blog. So while grouping them together makes sense from a technical perspective, I wonder if it holds up when you observe the workflows.

My opinion is based on my experience in building sites for clients that hold multiple content components since 2010 and the feedback we've gotten over the years. Something along the lines of "Can we just simplify the menu if I just come in to create content". The proposed Content section solves exactly that.

You are right, perhaps, in that WooCommerce with its products is a bit different, though.

[jameskoster]

Orders and this stuff clearly belongs somewhere else.

I think that's what this comes down to. And it's not something that is clear to me based on the initial concepts.

I'd love for WP to provide a clear framework for plugin authors to follow so when we need to add top level items that don't fit into core sections like "content" or "settings", we do so in a way that results in a consistent and intuitive user experience.

[MikeSchinkel]

Replying to Horttcore:

Not everything is a "Site" so I would go for another wording.
"Content" seems the right word for me.

In general I like the idea of moving to a more streamlined approach. But I was going to make the exact same comment.

Also, it is not immediately obvious to me how "Tools" is differentiated from "Manage." And after 10 years working with WordPress its still unclear to me when many things will be in Tools vs Settings. So, I propose we move Tools as a submenu of Manage, and if possible find more obvious menu options instead of using the overly vague word "Tools." #jmtcw

Also, if this gets implement can be please redo the nightmarish admin menu "API" too and replace it with something more rational?!?

[MikeSchinkel]

Another thought — and if someone has already suggested this and I missed it, sorry about that — but a new menu system of this nature could potentially allow new menu options to be added by classification rather than position, with a default positioning that the plugin vendor does not control, and the ability for the user to easily reorganize and/or hide options.

So when your plugin wants to add a menu option is might look something like this:

// This would be put into content
wp_menu()->add_submenu(array(
   'label' => 'Courses'
   'post_type' => 'mysite_course',
   'callback' => '...'
));

// This would be put into content
wp_menu()->add_submenu(array(
   'label' => 'Subjects'
   'taxonomy' => 'mysite_subject',
   'callback' => '...'
));

// This would be put into manage
wp_menu()->add_submenu(array(
   'label' => 'MyPlugin Settings'
   'settings' => new WP_Settings_Page("myplugin",...),
   'callback' => '...'
));

I did not include an example for "design" as I could not think of a good one. What should a plugin put in the "design" menu?

There would be a need to give the plugin vendor the ability to put things where they want them, but maybe we should want to add a "Miscellaneous" top level option so that items that literally don't fit elsewhere can go into that menu option. And most vendors probably would not want their menu being put in a "Miscellaneous" option, so they would be less likely to pollute it.

With this constraint in place no plugins or themes should be able to pollute the top level menu. We could make is to that top level menus could only be modified by a drop-in so that people implementing a custom site could have that control, but no plugin or theme could do it automatically. (Or maybe we could allow a theme to also modify the menu?)

Anyway the above and especially the code is just meant to be a catalyst to encourage consideration of and discussion about how to ensure plugins don't destroy the simplicity and cohesiveness of this potential design as well.

[MikeSchinkel]

Craft CMS Settings

[MikeSchinkel]

One final proactive comment. For the "Manage" section it might be really nice if we took some inspiration from ​Craft CMS and had the Manage section optionally expand into a full page menu like the above screenshot for the Settings of Craft CMS.

Again, just something for discussion.

[jipmoors]

Today I mistook the WordPress sidebar for the Slack sidebar, which made me think the active admin menu item was a channel with unread notifications.

This made me think about the things that I like and use in Slack a lot; namely Starring channels or persons - marking the things that I use a lot and have them listed together.

When using my site I only have a couple of places that I visit regularly, and those don't always sit next to each other in the menu. This use-case is different for each user of the site and should be a user-configurable setting.

I'm not sure that the scope of the current concept encapsulate this kind of feature; but I would really see this as a very useful addition. I think a strong UX pattern that is used here is that you can mark a certain context as important on the page/context itself.

I would star/pin the "Add new page" - which I currently do by going to the overview and clicking "Add new" there; even though I know there are two optional methods of doing this which would only require one click (submenu and adminbar) - not even counting the widget on the dashboard.

Additional thoughts

While looking at Slack this way, I was looking at the channel/person-bar.
Such a bar, above every page could outline the type of the page, giving the option to "pin" it on the menu and providing information and (possibly) settings controls.

We currently have something that comes a bit close to this on the Block Editor pages, but this is lacking the context of which kind of page you are creating/editing. Especially with the navigation-bar closed up; you have to remember which Icon represents which post-type.

[afercia]

While the meta menu idea is interesting, looking at ​the codepen prototype there are concerns regarding the actual usability, semantics, and accessibility.

• ​icons don't have universal meaning and should always be accompanied by text labels
• plugins icons tend to represent branding rather than meaning, so they're difficult to parse especially when there's a lot of them
• icon-only controls are not operable for some users, for example speech recognition software users
• the markup would need to use an unordered list with 3 levels, which are difficult to navigate when using assistive technologies

Looking at the current admin menu, seems to me it privileges plugins needs over users needs. I'm not saying this is a deliberate choice. It just works this way for historical reasons.

Plugins are allowed to set the position they want in the menu. They can also change the menu items order via filters. Technically, they can also change the position of other plugins 😬

Some plugins use this power responsibly and add their menu items in a meaningful place. Other plugins tend to compete to get the highest position, often only for branding and marketing reasons and rarely taking usability into consideration.

Many of the ideas shared on this ticket imply the need to deprecate and retire the positioning thing and the related filters. Not sure this would be much appreciated by plugin authors if the new menu mechanism won't provide an advantage for them or, at least, no "damage".

That said, I'd tend to think that any grouping pattern, whether it's based on meta groups, functional groups, whatever, will be inevitably based on assumptions on what's best for users. One could argue that web design consists in exactly that: trying to figure out the best user experience. However, in the admin menu case I'd tend to think there are just too many different scenarios and many, many, different needs. In my experience, determining what's best for users in these cases is extremely hard. At the point that it's likely impossible to cover all the needs.

In this regard, @jipmoors's proposal seems to me a much modern approach and potentially a game changer. It's a shift from plugins needs to users needs.

Simplicity is key. Instead of trying to reinvent the menu based on some major workflows, maybe a better option would be keeping it as simple as possible. And provide users the ability to customise it on their own needs.

The ability to pin menu items would be a great start. Plugins should be happy with this, as users will likely pin the plugins items they need to use on a frequent basis.

Pinned items:

• they get moved to their own <nav> element, at the top of the page
• the <nav> element contains an unordered list with max 2 levels, as the current admin menu

Customisation could be further expanded using patterns that already exist on the web. Couple of ideas I'd like to propose to explore:

Manage menu items:
Something similar to the Gmail "Manage labels":

• in this page users can toggle the visibility of menu sections or single menu items
• hidden sections and items get moved to a "More" (better wording welcome) section, collapsed by default
• the "More" section expanded / collapsed state is saved in the user setting
• at any moment, users can un-hide items and they get moved back to their original position

[Gmail settings to hide / show the system labels, categories, and custom labels]

Most used items section:

• can be enabled / disabled via user setting
• based on frequency usage
• provides a setting to set the amount of most used items to display
• items that are already pinned should be excluded

Note: one of the requirements for this to work is that _any_ menu item must have a unique text label. For example, all the "Add New" menu items should specify the post type. Also, taxonomies should use unique text labels.

After initial setup, a menu structured this way could be as simple as:

Pinned navigation

• My first favorite item
• My second favorite item
• My third favorite item
• My fourth favorite item
• ...

Most used ▾
More ▾

[knutsp]

#49054 was marked as a duplicate.

[iandunn]

#53544 was marked as a duplicate.

[iandunn]

#53544 was marked as a duplicate.

[sabernhardt]

This has had review, so I'm moving it to Future Release.

[paaljoachim]

Because of the huge impact a redesign of the WordPress sidebar menu area has, I believe this idea should be made into a Feature plugin project. ​https://make.wordpress.org/core/handbook/about/release-cycle/features-as-plugins/

Associated:
https://core.trac.wordpress.org/ticket/50539

[joedolson]

Creating a feature plug-in is a good way to at least figure out the end goal we want to accomplish with a new menu system. I think it may be too disruptive to use the usual feature plug-in process, where we eventually just switch over to the new system - but using the feature plug-in as a way to identify gaps in support, pain points, and figure out a transition process might be highly beneficial.

[paaljoachim]

We discussed this ticket during the accessibility meeting on Slack:
​https://wordpress.slack.com/archives/C02RP4X03/p1628268078196000

This is a huge project.
It needs to be broken down into smaller identifiable pieces.

Having the end goal in sight through a plugin of some sort can be helpful.