NAV: Horizontal Exploration

Building on the 6-up exercise I did recently, I spent some time building my first HTML prototype as a proof of concept for one possible way to update the WP core and navigation. Below I will share a preview of this prototype. I’ll share a link to it so you can poke around with it yourself. I’ll then do my best to grade this direction based on the constraints I laid out at the beginning of this exploration.


  • My goal in doing these explorations is not to lobby for any specific direction. My goal is simply to explore and see if anything valuable can be learned in the process.
  • I’m intentionally pushing to the edges with my explorations.
  • This horizontal nav would be quite the departure from the existing top + left nav in WP core. There is zero chance that we’d be able to swap out the existing WP nav for this nav. This is obviously something we’d have to iterate towards over the course of multiple public iterations.
  • My focus with this prototype was to get a few major things functional (plugin handling, responsive handling, roles, color schemes, translations, and how well it works with both Core and I intentionally left out most polish.
  • The code should mostly work, but it’s admittedly a bit hacky.


Here’s a quick GIF preview of what I’ve coded up. I’ll post a thorough video walkthrough below as well if you’re interested in the details:

Video Walkthrough

Take it for a spin

Feel free to take this prototype for a test drive:


Similar to my grading of the existing nav, I’ve gone through and graded this navigation based on the constraints I originally outlined. Here’s how I graded this nav:

Remaining issues

There are still be a few rough edges and things to figure out:

  • When you click the back arrow from the plugin menu, it often triggers the fly out menu for the WP logo. This isn’t ideal. I suspect there is a way around this if we introduced a timeout.
  • Some of the breadcrumb sections are not actually links. We could come up with actual pages for sections like “Publish”, but I’m not sure it’s worth it.
  • The “+” next to Posts, Pages, etc… Is not super intuitive. Would could change this to read “Add new”, but that would probably feel excessive. There is likely a solution that would work somewhere in the middle of the two. Maybe just the word “Add”.
  • Timing on the mega menu transitions isn’t perfect yet. I suspect we could fine tune this even more.
  • The search UI could pop out like it does on GitHub and allow you to jump to any deep link.

Next up

Next, I plan on exploring another entirely different approach to overhauling the WP nav.


If you have thoughts, questions, feedback, criticism, or concerns I’d love to hear them in the comments below.

4 responses to “NAV: Horizontal Exploration”

  1. This looks really good! Like REALLY good! Nice work 👏

    Some ideas for your remaining issues –

    – With the breadcrumbs, especially on post types, I think it’d be nice to go from “New” or “Edit” back to all posts (or whatever post type it is). So instead of “Dashboard -> Publish -> Editor”, maybe it says “Dashboard -> Posts -> Edit” or “Dashboard -> Posts -> Add New”. I think one benefit of this approach is that we can use the existing post type labels.

    – Agree that the “+” has some drawbacks, but it looks terrific. I think making it more of a button could help distinguish it from being an element that opens a submenu. Also think it would be good to incorporate the existing post type labels as much as possible throughout the UI.

  2. Just shared this around with our editors and devs. Looking really good, the one comment that kept coming up from the prototype is it’d be better if it was click to activate not hover, I think that may more have to do with the length of the css animations than anything else, but take that as you will.

  3. Lukasz Teranet Avatar
    Lukasz Teranet

    Wow saw this from a twitter post, this is excellent, so clean, minimal, easy to use, please share this in the collaboration phase WP is currently working on!

  4. I think you know I’ve advocated for a UX redesign like this for a LONG time. I think this looks REALLY good. TY so much for the hard work on this.

    I especially like the idea of “workflow/context-specific” menus, including for plugins, like you show for WooCommerce. Anything to get rid of the 3-mile-long vertical kitchen sink!

    I had envisioned what you show in the “mega menu” all appearing vertically where the current vertical sidebar is, but I like the horizontal too. I especially like the “breadcrumbs”. Super obvious UX for anyone to follow.

    I agree that your demo looks very extensible [and in a usable way] which is the more important thing.

    I do wonder about a couple things:
    1) In the WooC example does “Products” show up under both “Publish” and the Plugins/WooCommerce menus? (I think it should. All content/post types under Publish. The odd thing is I’d probably pull Media into it’s own top level menu, not under Publish. In my experience users don’t think as media as something they publish (even though it’s a post type). They think of it as something they manage like files on a disk.

    2) Let’s assume I have 100 plugins, what does the plugin menu look like at that point? Are folks going to be able to actually find anything or are plugin authors going to go back to saying “no one can find my settings so I’m adding a primary/top level menus that users can’t miss it”.

    It’s nearly impossible to enforce this sort of thing, but what I really want to prevent plugins from adding new sub-menu items under “Manage”. That sub-menu should remain ONLY for core sub-menu items. All plugins settings should be regulated to the plugins menu.

    If a plugin wanted to extend the individual settings page, like adding setting to disable comments to the “Discussion Settings” page they still could, or additional thumbnail sizes on the “Media Settings” page, but they shouldn’t and couldn’t add a menu item under manage for it the way most do.

    The main vertical sidebar today is a usability problem, but so is the “Settings” sub-menu. Both these things need guard rails so that the overall WP UX stays usable, Ex.

    PS. I miss JP Omnisearch… I know they broke it into it’s own plugin, but damn I found that useful. When JP pulled it you Sam Hotchkiss was in charge of JP and said I was literally the only person that complained about it’s removal… to me it was 90% of the reason to install JP, lol… I really like what a few folks have done (Beaver Builder folks, Elementor Folks, etc..) adding “quick search” that is kind of like Alfred/Spotlight search. Really needs to be a core feature.

Leave a Reply