Proposal: Navigation menu block design

After collecting feedback and discussing areas of the problem individually, @melchoyce and I have circled back to a proposed combined direction for the navigation menu block.

What problem are we trying to solve?

Building navigation menus for a website is a fragmented process that’s difficult to understand and visualise. It relies on a pre-existing understanding of the model WordPress uses to organise menus and doesn’t map to users’ understanding of how navigation menus should work. There are multiple different ways to create a menu (Customizer, Appearance > Menus, widgets) that all offer slightly different experiences, increasing confusion. Creating a link to certain parts of the site often requires manual work.

Principles

The core principles followed here:

  1. Any interactions that are required by a majority (over 50%) of users exist in the block interface itself.
  2. Advanced controls are moved to the block inspector in order to progressively reveal complexity.
  3. Switching between advanced and basic interactions is made simpler by links.
  4. The editing state of the block itself should mimic as closely as possible the front-end output.
  5. Use technology and data to make smart decisions for the user so as to limit the number of decisions they need to make.
  6. Users should be able to create pages from the menu interface if these pages don’t already exist on their site.

There’s a great deal of complexity that goes into a navigation menu (multiple levels of nesting, mega menus, social links, etc), but the majority of users require a very simple menu—a collection of links to the main sections of their site.

After a productive discussion in the #design meeting of 13 February, Mel and I decided to create slightly different experiences for core interactions and advanced interactions. For the majority of users, everything they’ll need to build a simple menu will be available in the block interface itself. Smart defaults help users get up and running as quickly as possible, so they may only need to make a few small adjustments to the out-of-the-box configuration of the block. For advanced users who want fine-grained control of complicated menus, a suite of advanced tools is available in the Inspector.

You can see how these interactions are classified in this diagram:

Diagram of core and advanced interactions.
Core interactions are blue, advanced interactions are pink.

Proposed Solution

The core (in-block) UX flow.
The core (in-block) UX flow.

When you first add the navigation menu block, Gutenberg will use some underlying code-magic to try to automatically generate a menu for you, based on a number of different factors including any pre-existing saved menus, where you’re inserting the menu on your site, and what content you already have set up. 

What your default menu might look like.

Once you’ve created a menu, you can delete items quickly using the delete on your keyboard, or you can delete them using the traditional block settings ellipsis menu.

To rearrange elements in your menu, select the menu item you’d like to move and either use the drag handle or the “move left” and “move right” buttons to shift it. Advanced options and hierarchy management exists in the inspector. 

Navigation item settings.

One level of hierarchy is visible in the block itself. By default, sub-menus are hidden in the block interface, but they can be toggled on and off using the drop-down icon. For more complex hierarchical structures, an inspector panel opens and allows for legacy-style reordering and nesting of navigation items. 

A sub-menu displayed.

To add an item to your menu, start typing or use the “+” button. The placement of the “+” button shifts depending on which item is currently selected, so you don’t need to add new items at the end and then move them up.

Adding a new item to a navigation menu.

Adding a new menu item pulls up a search interface, similar to adding an inline link or a button. The search returns all relevant content across your site, regardless of what content type it may be. Icons are used to provide additional context as to what type of content is being returned. From here, you can also opt to create a new page or enter the advanced mode to browse your content and bulk-add items.

If you’d like to dive more deeply into the finer points of discussion, there are a series of Github issues for discussing different parts of the interaction:

There’s also a Figma prototype that you can play with or leave comments on directly. Note that it’s under construction, so not everything works perfectly yet.

Get involved

At this stage, broad feedback would be extremely useful. 

  1. Overall, does this feel like a sensible direction? 
  2. Is there another approach that might work better?
  3. What’s the most elegant way to handle nested menus?
  4. How can advanced reordering be made as simple and user-friendly as possible?

If you have feedback on a specific element or interaction, it’s best to leave that in Github or Figma. If you’d like to remix or improve this work, please feel free to create a new page in Figma, or duplicate the whole document itself, and share here in the comments.

Next steps

These designs are a work in progress and will be iterated on based on your feedback as well as usability testing results. 

@lukepettaway and I will be meeting up later this week to do a walkthrough of the proposal and identify any potential accessibility problems in this design.

Mel and I will be working on a plan for usability testing of this prototype. If you’d like to be involved or sit in, please join us in #research at 18:00 UTC tomorrow, Tuesday 26 February for a text chat. More details will be posted here once those details have been hammered out. If you’re interested in helping with usability testing, there will be lots of opportunities to get involved!

#gutenberg, #menus