Add block: Navigation menu

[sarahmonster]

Since creating a block for navigation menus is one of the priorities for 2019, @melchoyce and I have been spending some time working on some ideas for a navigation menu block.

Lots of great work toward exploring a navigation block has already happened in #1466. In the interests of refocussing the conversation, I'm opening a new issue for this as we attempt to reach a solution.

First, let's establish a framework for understanding and evaluating the proposed solutions.

1. What’s the problem we’re 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 your site often requires manual work.

2. What existing research do we have?

Menus came up a few times in our sitebuilding research. Relevant takeaways: some people model the structure of their menus on the structure of their sitemap (or vice-versa).

Competitive analysis: http://simp.ly/publish/fTQTQB

Mel reviewed existing explorations to compile the discussion and ideas that have emerged around navigation blocks over the years.

Functionalities to consider:

• sticky menu
• horizontal or vertical menus
• nested menus
• social menu
• mega menu: image, description, button, etc

3. What are our guiding principles?

After discussion with developers, accessibilities, and other designers, we've decided that in order to support the problem:

• building a menu should be as WYSIWYG as possible
• menus should be as flexible as possible
• there should only be a single experience for building and editing a menu, even if that experience is duplicated in different parts of the UI
• the menu-building experience should be consistent with existing Gutenberg design patterns
• the solution should allow for all functionalities identified in “existing research” section
• should allow for adding pages and defining page/sitemap structure

4. How do we choose a successful solution?

Using prototypes, we’ll test and time the creation of a simple menu and a complex menu. We’ll also ask users to rate their experience from a scale of 1-5.

This quantitative data (experience rating and time to creation) will be used alongside the qualitative data (user feedback, your feedback!) to determine which solution is the most effective and should be pursued. @melchoyce will be responsible for this selection. We'll then iterate on the solution until we hit on what we think is the best approach.

[sarahmonster]

In exploring solutions, @melchoyce and I narrowed down to two paths.

These particular prototypes focus on creating a new menu from scratch. Not every state or setting has a mockup — the focus right now is to go broad, not deep, in this exploration. We'll test these two approaches and then narrow down in iterations, based on your feedback as well as user feedback.

Concept: Going all-in on child blocks

Desktop: https://www.figma.com/proto/PtDJhniObeJ2Po6TZAMiHCKv/Gutenberg-Navigation-Menu-Block-Child-Blocks?node-id=0%3A1&scaling=min-zoom

Mobile: https://www.figma.com/proto/PtDJhniObeJ2Po6TZAMiHCKv/Gutenberg-Navigation-Menu-Block-Child-Blocks?node-id=2%3A13829&scaling=min-zoom

This approach takes advantage of some smart patterns introduced by the Jetpack contact form block and WooCommerce products blocks. Each page type is its own child block. We focused on two things: using as many established Gutenberg patterns as possible for consistency, and retaining existing navigation menu features so the block can be a direct port for backwards-compatibility purposes.

Questions:

1. We’ve introduced a “hide menu” setting, which is to tackle the issue of some themes providing default menus, some setting fallbacks, etc., which means there’s no consistent way to get rid of a menu. In the future when we have full site editing, this could come in handy for themes or sites that don’t allow you to delete global blocks. For now, it’s a bit superfluous and we might remove it.
2. The navigation menu should include a “Login” and “Logout” item, as well as an RSS feed link menu item — should these be their own menu types, or listed in “Pages?” Maybe they should be in a “Meta” page type?
3. We’ve included menu descriptions inline, but we're wondering if, since not a lot of themes currently support them, if they should live in the sidebar?
4. Should we deprecate any menu features, like XFN, from the block?
5. Should any other menu options live in “Advanced Settings?”
6. Anything missing?

Concept: Menus are just links

Desktop prototype: https://www.figma.com/proto/2boguPnkQ8r2aCeovzBHwY/Menus-are-just-links?node-id=83%3A15896&viewport=402%2C418%2C0.5&scaling=min-zoom

Mobile prototype: https://www.figma.com/proto/2boguPnkQ8r2aCeovzBHwY/Menus-are-just-links?node-id=83%3A15896&viewport=402%2C418%2C0.5&scaling=min-zoom

Inspired by Material Design’s chips, this option aims to present the menu as closely as possible to the way it looks on your live site.

This uses the some interface as adding links elsewhere (when creating an inline link, or when adding a button) so there’s consistency any time users add a link. (Note that this only works if users think of navigation in the same way they think of inline links, which may not be the case.) This is a good opportunity to refine and unify how this interface works (#6392) as well as evaluating other search interfaces. We can unify these experiences across the entirety of the product whilst also making a teensy accessibility win.

It tries to make as many smart default guesses as possible for the user: it allows for converting menus if you already have some saved, but if you don’t, it defaults to a small menu based on existing pages. Finding items to add to the menu is primarily based around a smart search that searches across all types of content on your site, as well as including pages for archives and recognising and adjusting for social media links. Pasting a link will work as expected, so the interaction will be immediately accessible in as few inputs as possible.

Questions:

1. Does the chip approach work here to add clarity and usability, or does it feel too divorced from existing Gutenberg patterns? Is there a better way to clearly communicate a link in a navigation menu while it's being edited? (See alternate style ideas.)
2. This approach avoids putting settings in the sidebar as much as possible but doesn't include many fine-grained controls (beyond a horizontal/vertical option and alignment for the menu, and a few options for individual menu items). Are there other settings that should be included here?
3. How can we improve on the existing "add link" interface to make it more accessible, usable, and flexible? (For instance, the ability to upload a file directly here would go over like gangbusters; see also #8322.)
4. This isn't included in the prototype yet, but we'll want to include some options for adding new content here as well: maybe just a "Create new page" option below search results? Are there other types of content we should allow for dynamically creating from this menu?
5. Sub-menus haven't been fully explored here yet either, and they open lots of questions. Should we allow for unlimited layers of sub-menus, or restrict the number of children? Should sub-menus be expanded by default, or should there be a way of expanding and collapsing them? Can you select a sub-menu individually? Would the toolbar be specific to the parent menu, or to the sub-menu? Is there such a thing as sub-menu settings, or are those settings owned by the parent menu and applied across all sub-menus?
6. What happens when a user has a lot of items in their menu? How can we make it as easy as possible to navigate through those items across a range of devices?

What do you think?

At this point, we'd especially appreciate overall feedback about:

• Technically feasability: Can we do all this? Are there ideas here that are too wishful thinking?
• Accessibility: Are there things we could improve here? Does anything in particular raise a red flag? What can we do to ensure these approaches are as accessible as possible?
• Experience: Do these feel like natural approaches? Are there any parts of the flow that feel awkward?
• Settings & functionalities: What functionalities and settings are critical to meet the needs of the majority of users? Are there settings we can drop, or that we should be sure to include?

Leaving comments directly in Figma would be great, and you can also comment here. We'll work on refining these prototypes and running some lightweight usability testing to get a sense of how natural the interactions are.

[deckerweb]

Login, Logout, RSS etc. should be a "Meta" type, NOT "Page"

XFN should be kept, since it must be possible to optionally set these meta params for ANY menu item link:

• nofollow / dofollow (for SEO purposes)
• noopener and noreferrer (both for security purposes)

[melchoyce]

XFN should be kept, since it must be possible to optionally set these meta params for ANY menu item link:

• nofollow / dofollow (for SEO purposes)

Can this be applied to the entire menu, or does it have to be on a menu-item-by-menu-item basis?

• noopener and noreferrer (both for security purposes)

Is this something WordPress should handle by default, rather than leaving it up to the menu creator?

[deckerweb]

Can this be applied to the entire menu, or does it have to be on a menu-item-by-menu-item basis?

Yes, that was what I meant. I often times have a few menu items which I explicitely set to nofollow - for example an external link to a donation service or the internal link to the privacy page (because I don't need both to be indexed in Google...). I know lots of other devs and users doing this similar.

Is this something WordPress should handle by default, rather than leaving it up to the menu creator?

In my opinion yes, for all links that open in a new tab/window (_blank target).

Also, the option to set an optional link target (to open in new tab/window) must be kept - at it is currently. This is an essential user option.

[sarahmonster]

"Meta" may not have any meaning to the majority of non-technical end users, but you're right that log in, log out, and RSS links aren't the same as static pages. What's a way to communicate this clearly to users? Maybe the login and logout could be classified as "action" links? Perhaps the RSS feed is a special "feed" type, or maybe it acts the same way as a social media link (basically as a special type of link.)

XFN is pretty user-hostile as it currently stands, but it's helpful to get a sense of how that feature might be being used. It's actually intended to show a personal relationship and used to be more explicit when Blogrolls were still a Thing. I wonder if exposing those options directly (nofollow, dofollow, noopener and noreferrer) in the Inspector (since these are rather advanced settings, but we could include them in the link interface if we think they're important to all users) might be the way to approach this.

[melchoyce]

I wonder if exposing those options directly (nofollow, dofollow, noopener and noreferrer) in the Inspector (since these are rather advanced settings, but we could include them in the link interface if we think they're important to all users) might be the way to approach this.

That would also allow for some inline explanations, which would definitely help.

[getdave]

Thank you so much for this. Great to see this moving along. Some thoughts...

Concept: Going all-in on child blocks

Technically feasability

Everything I see looks doable.

Experience

• What would re-ordering items in the menu look like?
• Veritcally displaying the Menu whilst editing is good when constructing a Menu that maps to a Sitemap in the user's mind. However visually I feel the preview will need to better reflect the reality on the frontend (ie: most menus are't vertical). However will the change between the two states be too jarring?
• Visually the items don't feel like "menu items" they just feel like links. I appreciate this is fundementally what they are but a Menu item implies much more. If each item were more of a contained "unit" then you could give them their own controls. Perhaps more closely aligned to the existing WordPress menus?
• Once added there isn't a way to visually see the type of the menu item (eg: Page, Post, Category...etc) without interacting.
• How do I remove a Menu item once added? Nothing visually shows up? Also an a11y concern.

Concept: Menus are just links

Technically feasability

Everything I see looks doable.

Experience

• I like the "chips"
  • make it easy to remove an item
  • the inline auto complete is a nice touch*
• I believe adding Social to this is a step too far. See notes below.
• It's not immediately clear to me as a user how I crate hierarchies
• Can we stress test the design a bit with the horiztonal layout? It's fine with 3 items but what happens when you have 10? You can't easily wrap as that could be confused with a hierarchy. How will this scale? (see comments above re: vertical layout when in editing mode)
• I preferred the explicit choices (Page, Post, Link...etc) in the "child blocks" prototype. It was clear what you were adding to the menu and the search was a nice extra. Could we merge the two?
• How do I reorder items?

General: Settings & functionalities

• Login/out and RSS should be separated under Meta as suggested
• Gut feeling is that Description is rarely used. Put that in sidebar. Prioritise the UI space elsewhere.
• I'm fairly against muddying the concept of creating a Menu with the concept of adding new Pages. The act of creating a Page feels like it needs to be explicit and not part of creating a Menu Block.
• I'd say remove as many "rarely used" (TBC) features as possible. Keep the UI nice and focused wherever possible. We can always add more settings later if user demand dictates it.

Relationship to "Social Links"

There is an existing Issue for Social Links. I (and others) don't believe the Menu Block precludes the need for a dedicated Social Links block.

Most users won't cognatively assiociate "Menu" with "Social Logos". When searching Blocks they'll expect "Social Icons/Logo/Links" not "Menu".

I appreciate at a deep level Social Links and Menu Items are similar in concept but to me they feel like distinct Blocks. I fear that if we get too "meta" on our Blocks and try and require overconfiguring them then UX may suffer.

I'm very interested in hearing your thoughts on this as I am (was going to be) taking on the Social Links Issue...

Again, thanks for moving this conversation forward.

[Luciaisacomputer]

Some of the accessibility concerns that come to mind would be:

Keeping control of user focus throughout the flow

When clicking the Add a Menu Item button, a dropdown appears which then provides a search input as well as several sections to locate a page or pages to add to the navigation. Once a page or pages have been added to the menu, the dialog closes and returns the user back to the block. That is a lot of moving around between different components on the page.

The most important thing here is to make sure that we are updating the focus and placing it in the next logical spot. I also wonder to what extent focus might need to be trapped within these elements because it might be really easy to escape the component before the workflow of adding a page has been completed.

Providing Additional Context to Assistive Technology

When selecting any number of menu items, having some way to inform assistive devices about their current selection state is crucial. This could be notifying them that the number of selected items changed from 3 to 5 for example.

Another area of consideration is the approach to nested page structures. To a user who is not blind, it is easy to infer the hierarchy of content when adding a category and pages under that category for example. This might become an issue for those using assistive technology. Am I adding these pages inline?, how do I know that the pages I am adding will be children of the parent they are currently under. This is especially the case if selecting the parent could potentially also select the children (solved again by announcing the selection to the assistive device).

I'll spend some more time thinking about this experience and please let me know if you have any questions about my comments. Thank you for all of this!

[alexislloyd]

My hypothesis is that there are three primary types of user intent when inserting a nav menu:

1. I’m a business owner who wants a menu linking to all the top-level pages
2. I’m a blogger who wants a menu linking to all the top-level categories
3. I want to make something custom from scratch

I also suspect number 1 is the most common, and that users who are in the number 1 category have the highest likelihood of not being experts.

I was originally thinking that we could give users a choice between 1, 2, and 3, like option A in the sketch below.

However, it occurred to me that instead of confronting the user with a choice, number 1 could just be the smart default, and you could make it easy to infinitely customize from there. I imagine most “custom” menus are actually just variations on one of the first two, so having that populate as a default and then be able to take out a link here, add a link there, add a social button, etc. is likely easier than starting from scratch anyway.

So, in option B below, the user inserts a menu and it defaults to a menu of all the top-level pages, with an easy toggle to switch to categories. Each menu item is selectable, editable, movable. You can add new items. And the sidebar could support lots of more advanced options like adding additional levels to the navigation.

[sarahmonster]

Thanks for the feedback! We're going to keep collecting more feedback and then iterate on these designs based on feedback and testing. A few quick-ish notes:

@getdave We've definitely seen some evidence that indicates users tend to think of adding pages (building their site structure) and building a menu as an intertwined process, and they can often become confused when pages they've created don't automatically appear in their menu. The social links is just a hunch, though, and it might be based on the existing pattern of themes registering social menu areas, so it's worth evaluating if that's how users see things.

I'm going to see if I can test these hypotheses a bit when we usability test these designs. If you have any insights on users' thought processes around these components, it'd be super useful to incorporate those!

@LukePettway Thank you so much for the accessibility feedback! For the focus consideration, do you think either of these methods of adding a menu item (the child block interface vs the link interface) presents fewer hurdles?

Your point about nested page structures is especially helpful, since nested structures are a bit tricky to design for. Thinking about how to non-visually indicate this hierarchy to users of assistive technology may actually be key to unlocking some good ideas here—I'm adding to the list of "things to explore more".

@alexislloyd it sounds as though what you're suggesting here is similar to the "auto-populate" option presented in the "Menus are just links" option, where users who haven't already created menus are given a menu populated from their pages, rather than an empty menu, and users with existing menus are shown those menu.

The idea here is that we'd try to make smart guesses for what they'd want in their menu, but immediately allow for customisation of those items, which I suspect most people would immediately want to do.

I think we could possibly take this a step or two further and try to add other helpful, smart defaults, so rather than just including top-level pages, leverage certain common naming patterns to determine order, or which pages to include or exclude. My suspicion, based on a cursory evaluation of common menu patterns across blogs, is that #2 is actually a less likely scenario than we might think, and that most blogger sites use a combination of categories and pages in their menu.

Rather than asking users to reckon with the choice between pages and categories, we can skip this step altogether and provide them with a ready-to-go menu that includes pages as well as categories (perhaps above a certain threshold), along with other suggested links based on common patterns and their existing site structure. I have a few thoughts for how this might work, but I'm going to look for some data to back them up and explore a few alternate ideas. This should also allow us to test if our smart defaults will actually feel smart for the majority of people.

[scruffian]

Following on from @alexislloyd's point, something I have seen in usability tests and research, time and again, is that users conflate their navigation with their site structure. If they add a page they expect it to appear in the navigation. If they add an item to their navigation, they expect a page to be created.

I wonder if we should consider creating two different blocks. One very simple "page navigation" block, which maps 1:1 to a user's pages - when they add an item to the navigation a new page is created; when they add a page to the site, its added to the navigation.

Then we can add a second "custom navigation" block which will allow for all of the complexity that many users need.

[alexislloyd]

@scruffian you make a very good point about the conflation of navigation and site structure. That might be a secondary problem to try and solve once the fundamental insertion of the block is nailed down.

As to insertion, I still think we could do it with one block — I think the ideal experience would be one where someone doesn't have to stop and think "Do I want a page navigation block or a custom navigation block?" Ideally, we can remove any friction that makes someone stop and wonder if they understand the choices. If we provide something relatively smart but make it incredibly easy to modify, it seems like it would be able to satisfy everyone's needs, whether simple or custom, without having to create any friction or potential confusion for the user up front.

@sarahmonster I like how you're going even further with the smart defaults idea — the approach you're suggesting also really supports users who don't know the difference between pages and categories (and shouldn't have to!).

[sarahmonster]

Thanks for all the helpful feedback here! In the interests of maintaining focus and ensuring that we've fully explored all parts of the problem before moving toward a solution, we're going to break the problem into smaller parts to explore individually:

1. What happens when I add a menu? (smart defaults, onboarding)
2. How do I add an item to my menu? (child blocks, link interface, types of content to include)
3. How do I edit that menu item? (renaming, settings)
4. How do I rearrange items in my menu? (ordering, hierarchy, sub-menus)
5. How are menus and menu items presented visually? (focussed state, horizontal/vertical styling)

We’re going to discuss each of these problem areas individually in more detail, then return here with the resolution once we’ve reached a consensus. (Links coming as new issues are created!)

We’re also going to do some additional research to inform these explorations:

• digging up insights from support forums
• collecting common menu patterns from a range of different sites

If anyone would be interested in helping with any of these tasks, we'd definitely appreciate the help!

[melchoyce]

@deckerweb Circling back around to menu item settings for a second — would something like this make more sense for handling nofollow?

[deckerweb]

@melchoyce Thank you, this is perfectly fine in my opinion and an improvement over the current nav menus.

It has clear user guidance with the labels/wording, and the setting toggles are faster and easier. I hope this will go in the final version in future. Thanks for this great work!

[melchoyce]

Awesome, thanks!

[jwold]

Amazing work here! I'm going to comment individually, but just wanted to say that the progress here is wonderful. :)

[melchoyce]

Wanted to give an update here.

Last week, a group of designers conducted seven usability test on a prototype @sarahmonster put together. We've spent this week going through notes and pulling out insights.

Next up, we're going to publish our results to make/design, revise the prototype based on the results of these usability tests, and then hand off the designs here to @jorgefilipecosta, who will be working on the block.

[jorgefilipecosta]

Let's do some additional technical discussion regarding the navigation block.

We can divide the navigation block work into two main parts: the editor block, and the backend logic.

The editor block

Handles all the interactions of the block in the editor and communicates with the server. This part contains all the UI and UX related work. Ideally, we would provide extensibility mechanisms to the UI the navigation block, a mechanism to allow plugins to add their custom menu items, etc... One way we would be able to offer extensibility would be representing the Menu Block as a parent block with each menu item as a child block. Currently, our InnerBlocks follow the same structure and wrap each block with the same markup, (side menu, drag handle, block movers, toolbar, etc.), it may not be possible to achieve the design using the default look of InnerBlocks. One way that would allow us to use nested blocks for the menu and respect the design that is proposed would be by adding a mechanism to InnerBlocks that allows blocks to customize the BlockEditor functionality, e.g., customize the wrapping markup of each block edit inside the InnerBlocks area. This API would let us have custom menu item movers, custom menu draggers, custom inserter, etc. I guess plugins would benefit from being able to customize the BlockEditor inside an InnerBlocks area, and the customization implemented for the Menu block would be exposed so plugins would be able to use it in their blocks. We will only try this option if using the current InnerBlocks look and options we can not get the required design/UX.

The backend logic

Receives the information from the editor block and persists this information into a database structure that can be queried. Queries the database structure and outputs HTML in the frontend of the website. Menus are displayed on every page of a website, and sometimes websites have more than one menu per page, so it is essential that the chosen structure allows very efficient querying.

Before going into options first let's have a general overview of how the menus are currently stored.

Current database structure

Each menu is stored in the wp_terms table:

The wp_terms_taxonomy table associates the menus (terms) to taxonomy nav_menu:

Each item of the menu is stored in the wp_posts table:

And is associated with the menu (term) via the wp_term_relationship table:

The options of a menu (auto_add pages) are stored as in wp_options under nav_menu_options:

Array
(
    [auto_add] => Array
        (
            [0] => 263
            [1] => 262
        )

)

The association of a theme menu location to a specific menu is also stored in wp_options under theme_mods_THEMEKEY option:

e.g.:

Array
(
    [0] => 
    [nav_menu_locations] => Array
        (
            [menu-1] => 262 (id of a wp_terms_entry).
            [footer] => 263
        )

    [custom_css_post_id] => -1
...
)

This raises some questions: Should we use the same store mechanism that we have now or should we migrate it to a new one more in line with the blocks paradigm?

If we don't migrate to a blocks structure, blocks are essentially a temporary structure used on the editor and during the save they would converted to the current structure.

I guess we should migrate to the blocks paradigm to have a uniform development and user experience and to make sure the block API's/hooks work. We have two options for the new structure:

• Save the menu block markup in a post (with a special CPT or taxonomy) and reference that post id from theme_mods_THEMEKEY under a key different from nav_menu_locations, ( e.g., block_menu_locations) to differentiate new and "legacy" menus.

  theme_mods_twentynineteen
  Array
  (
  [0] => 
  [block_menu_locations] => Array
      (
          [menu-1] => 26234
          [footer] => 263343
      )
  )

To render the menu we simply render the blocks rendered on that post id. Regarding the performance, all menus and items are saved in the wp_posts, even if we have the auto_add option enable. I guess we can build a single query to retrieve the menu "posts" and auto added entries, the query will be complicated but will not involve joins as we require now.

• We still save the menu in wp_terms; the theme option stays the same; we use the same logic/storing structure. The menu block is stored in wp_posts as the current menu items are, and we have to check if a menu item post contains blocks it means that we are using the "new" menus and we render that block. The advantage is that it is more similar to the current approach, and it is probably easier to be back-compatible with this approach, on the other side the performance seems lower as we have joins in the tables and we have to perform some checks to see if a menu item contains blocks or is a "legacy" menu.

What option seems best in your perspective?

Hight level tasks

So currently these are the separated we will need to perform:

• Add API that Allows customizing the wrapping markup around each block edit in an InnerBlocks/Editor area. (If with the current markup/design we can not get the required design/UX).
• Implement the menu block UI (using the new API referred on the previous point or the current API).
• Implement some functionality that exposes the "legacy" menus to the editor so they can be migrated/updated. This functionality can be something on the server, e.g., a new endpoint, or maybe we can do something on the client, e.g., query the terms, query the posts, etc. using the current endpoints we have.
• Implement functionality that stores and retrieves the "new" menus, if it is a post we can use the current endpoints. But we will probably need a new endpoint to associate the menu to a theme area.
• Implement filters that hook into the current menu API's and render the new menu on the frontend.

Feel free to share your thoughts around this and to correct me if wrongly assumed/analyzed something. Every thought is welcome!

The first focus is related to the block UI and will involve creating an experimental block that follows the proposed design and saves blocks in the post content as we do for other blocks.

[youknowriad]

Thanks for the thoughts @jorgefilipecosta

One way that would allow us to use nested blocks for the menu and respect the design that is proposed would be by adding a mechanism to InnerBlocks that allows blocks to customize the BlockEditor functionality, e.g., customize the wrapping markup of each block edit inside the InnerBlocks area. This API would let us have custom menu item movers, custom menu draggers, custom inserter, etc.

I think we should definitely use the innerBlocks API and not something specifically built for the menu block. Ideally the customization are limited as much as we can. Can't we just see this as improvements for the current behavior as this would benefit all the blocks using InnerBlocks.

Should we use the same store mechanism that we have now or should we migrate it to a new one more in line with the blocks paradigm?

I think we should focus on the best storage mechanism for the block first regardless of the existing storage mechanism and this means a composition of attributes, child blocks and dynamic rendering.

Once we have the block in place, we could start thinking about the menu screen and how we can address the migration. Let's not make tradeoffs to the menu block because of this.

[sarahmonster]

Since there’s a lot of complexity here, @melchoyce and I have aimed to pare the proposal down and present the most critical touchpoints of the interaction. To explore our current ideas, have a click around the prototype or have a read through the (rather lengthy) description below! Since it's going to be impossible to cover every use case as possibility here without some sort of War and Peace-style diatribe, we're going to start with an overview, and then dive into more details in later comments and/or by answering questions.

Adding a menu

When the user selects the “navigation menu” block, a few things happen behind the scenes in an attempt to help them start with as smart a default as possible.

First, the menu is contextual depending on where the user is adding it to their site.

• Site header → defaults to a horizontal menu with a selection of their top- and second-level pages
• Site footer → orientation is vertical, same content
• Post or page → menu is acts as a table of contents, linking to the headings in the page.

We then try to build out a menu for the user, following this logic:

1. If the user already has a legacy menu on their site, we build them out a menu automatically from the existing menu and show a notification.
2. If the user has multiple legacy menus, we ask them which they’d like to use.
3. If the user doesn’t have any legacy menus but has > 5 top-level pages on their site, we build them a menu automatically from the top-level pages (maybe also second-level?) We use a notification to let the user know we’ve built them out a menu automatically, and the “add new pages automatically” setting is checked by default.
4. If we don’t have enough information to build a smart menu, we present the user with a short wizard to get up and running more quickly.

Mockups for all of the above options will be provided in more detail once we’re ready to start on this, but since smart menu generation isn’t critical to a v1 experience, we don’t recommend focussing on this too granularly right now.

Adding a menu item

Menu items are sub-blocks, presented in a simpler manner. To add a menu item, you use the + icon, which then prompts a popover with a search and browse interface.

Searching is the primary action, and so we optimise for this first. This is where we should focus for the v1 of the block.

Search results are ordered, as much as possible, by relevance, so that users get the results they’re looking for quickly. Exact matches should be first, followed by closest matches, and finally, alphabetical ordering. Unless two results have the exact same name, no distinction is made between posts, pages, or other types of content.

Focus styling would include a button to add the page to the menu, so the behaviour is clearer for users of assistive technology.

The search box also doubles as a “type a link here” box, much like the inline link and button interfaces. When a user types a URL, the options adjust to allow for direct entry/editing of the title. There’s also a possibility to allow for “special” types of content here, like search boxes, log in/log out links, and social media accounts. Mockups will be provided for these interfaces once we’ve reached this stage of development.

The “browse” tab allows a user to bulk-add items from their site using a checkbox interface:

Since these are all advanced options, we’d recommend exploring them in more detail after we have the basics nailed down.

Editing a menu item

A menu item’s label can be changed in one of two ways: directly typing when the label is selected, or by choosing “change label” from the menu item dropdown.

The menu item dropdown exposes all controls for the item. There’s some redundancy built in, both for accessibility purposes and since some non-native Gutenberg users we tested with immediately looked here when asked to move an item. There are advanced controls here that allow for quicker reordering of menu items without the need for drag-and-drop.

Users can also use the block mover arrows and drag controls to move their menu items around rapidly.

How hierarchy works

Manipulating hierarchy presents a number of interesting challenges. The prototype demonstrates a simplified version of how this might work, following the principle of having the editor view mimic as closely as possible the possible frontend output:

Items within a drop-down menu are manipulated in more or less the exact same way as top-level items. When reaching the top of the drop-down menu, if the arrow key is once more used, the menu item shifts to the same level as its parent:

Hierarchy will be presented in more detail once we’ve reached this stage of the protototype.

Keyboard navigation

With @lukepettway’s help, we did some thinking about how keyboard navigation might work. Here’s where we ended up:

Advanced menu and menu item options

Some recommendations for advanced settings:

Recommendations for a v1

There’s a lot of nuance in this proposal, so here’s what we think is needed for a v1:

• add a menu block
• rename a menu item
• move a menu item
• delete a menu item

Additional features could be added as iterations:

• v2 → hierarchy manipulation and orientation changes
• v3 → smart menu content generation
• v4 → advanced menu item add options (browse, action links, external links, etc) → v4
• v5 → advanced sidebar settings for menus and menu items

At each stage, usability testing could be used to evaluate progress and find any areas of confusion. Once a v3 is ready would be an especially helpful time to run usability testing, since a lot of core functionality would be complete at that stage.

Context recommendations

One of the things we struggled with here was not having a good sense of the context in which users would be adding the block, since this defines a lot of how they’ll visualise and interact with it. To that end, we opted to test with some context built-in:

Usability test results showed that people responded positively to the direct manipulation nature of this.

Our intial recommendation is to ship the block under a feature flag until we’re able to expose content areas like this, so that the new method of building menus will make sense to users, but if usability testing indicates the block providing a real improvement over the existing paradigm(s) prior to that, that recommendation will change.

Your thoughts!

There's a whole lot going on here, so we expect there will be lots of questions! Please do share them here, and we'll use those as a starting point for ongoing conversations. 🙌

[sarahmonster]

Note: revisions between the original proposal and the solution presented here are a result of discussions and iterations based on both ongoing accessibility feedback and usability testing.

• Usability test results
• Accessibility walkthrough

Our proposal here takes into account this feedback—in addition to community feedback collected in Github, Slack, and make/design posts—and attempts to find the best solution to balance all those different needs. We expect that there will be ongoing iteration as we move into code and can test and explore further!

[kaktux]

hi there,

beeing quite new to wordpress - and gutenberg - i have stumbled over the comparison of page builders and gutenberg. If i get it right one day gutenberg might/will be a page builder itself. So as i was searching for a block to create a menu i found this discussion - and my question is if i understand one thing right: the navigation menu will make it possible to create main menu, footer menu etc.? So something like the nav menu for the page builder elmentor?

To add my opinion - several "effects" are what i look for in a menu - like e.g. transparency, underlined when hovered, fullscreen, sticky etc. As orientation what the block can "replace" in terms of result and function the mentioned builder element or popular menu plugins like megamenu or responive menu may be suitable.

sorry if this is posted at the wrong place.

[idea--list]

Perhaps it is the most complex task to implement a proper navigation block type because:

• there are horizontal and vertical menus
• there shall be a plain structural and even a graphical representation
• adding/removing/rearranging/changing text of items must be easy
• if it goes to block level, people will tend to also want menus that are specific just for some subpages (not just site-wide menus like the main or footer menus)
• in case one changes the permalink settings, all the urls must also get updated automatically in all the navigation blocks
• Users will need detailed control about the looks (colors, font families, font sizes, paddings, text alignment, background images, etc. all these might be different for the active menu item, IMHO flexbox should be prefered), they also might want to override general looks in case of some special menu items...
• Editors need control how the menu shows up on a desktop/tablet/phone
• Menus need to be user type aware (there might be menus/menu items that plain visitors are not intended to find)
• Many users prefer to have icons next to the text
• a decent menu has at least some minor animations nowadays
• proper usage of aria tags is also a must +1: personally i can imagine the navigation block type only as a reusable block (otherwise it might be a complete disaster if you have a site with 100+ pages and you just decide to alter the menu)

This is only i can think of in some minutes and sounds like a big challenge for me to implement all these as a block type

[idea--list]

The more i think about it, the less chance i see to implement it in a single view. I mean there are so many options to set that there is simply not enough room for all that on a single screen. Instead of proposing design prototypes let me just show a logical flow where i tried to break up the process in smaller steps. That way it might be easier to squeeze all the UI of each step on the screen.

Further thoughts:

• maybe i would just remove the option of creating a new page from the bottom of the box as that would just break out of the menu creation workflow leading to a mess of half-ready menus
• the browse tab looks great with only some options, but what if a site has 20-30 pages/posts or even more?
• Under iterations v1-v5 do you understand prototyping phases or consecutive WP releases?

[javierlorente]

I like it!

[klihelp]

+1

[draganescu]

@idea--list thank you for the great analysis of the challenge for implementing a menu.

It is indeed a complex feat and that is why we'll go from simple to complex in iterative steps. I believe by the iterations @sarahmonster meant prototyping phases.

[idea--list]

@draganescu I wanted to make sure all the challenges will taken into account before writing any line of code ;-) Just because i read about the several tiny phases. I mean in most cases you begin with multiple phases if it is still not crystal clear what will you end up with. And we all know the feeling when you recognize in phase 5 that you should have coded something completely differently in phase 1... :-)

[draganescu]

Hi, while working on implementing the block itself I found it quite challenging to figure out how nesting should work. Thinking about it I have explored simple linear interaction that would allow both nesting and menu item creation and arrived at this sketch:

The advantages of this approach to the creation flow would be:

• easy to implement using only standard Gutenbeg inner block mechanics and components
• visually clear nesting interaction
• easy to switch from vertical to horizontal menu creation

This is JUST A SKETCH not an actual design :) of course.

Thanks and let me know any thoughts you might have on it.

@sarahmonster @mapk

[mtias]

This is JUST A SKETCH not an actual design :) of course.

This is interesting. I think a mode that represented the menu as a tree will be needed (might open it in a modal instead of inline, but we'll see) and using the "block navigator" makes a lot of sense, as we'll get interactions for free. Particularly once we allow dragging elements in the navigator to reorder blocks.

[mapk]

After a discussion between @sarahmonster, @melchoyce, @karmatosed, @mtias and myself, we've decided to make a few design pivots on this block. I'll outline them here with the goal of closing this particular issue. A new issue https://github.com/WordPress/gutenberg/issues/16821 has been created to track these changes.

Native block patterns

• Use existing block patterns whenever possible (ie. the block toolbar).

Refinements

• Refine the horizontally aligned inner blocks.
  • Explore how this pattern can extend to other blocks like button, columns, etc.
• Improve how child blocks perform in narrow spaces.

Adding a new block & Block Library

• The add block icon + should add an inner block with one click.
  • The inner block can then be defined as to whether it's a category, page, post, etc.
• Explore how the Nav block works when added to the page.
  • Does it default to the primary menu?
  • Does it offer an empty state for creating new Navs?
    • Are there helper messages?
    • Tips?
    • Place holders?

Nesting blocks

• Moving into/out of nested areas.
• Data tree structure: https://github.com/WordPress/gutenberg/issues/16812
• (idea) Possible drag and drop interactions similar to https://github.com/WordPress/gutenberg/issues/11408
• (idea) Possible document outline repositioning? https://github.com/WordPress/gutenberg/issues/9628#issuecomment-512830706

URL and permalink structure

• First iteration should offer a link in sidebar to the permalink page.
• Any changes in the settings should reflect in the Nav block.

Customize options

• Backgrounds (possible Group block)
• Link colors
• Font sizes
• Background colors/gradients for dropdowns
• Current menu item color/background options

Backward compatibility

• When editing a Nav block that was created from existing wp-admin menu screen, should this action create a new menu?
  • Allow for manual conversion.

[WayneAnderson]

Would it be possible to accelerate the feature with an interim deployment of a part which simply deploys/displays an existing menu sourced from the WP menus functionality?

[scottsawyer]

@WayneAnderson I am totally onboard with this, and was completely baffled not being able to select the native WP menu that I already spent 10 minutes making.

It seems a lot of effort going into recreating an existing, battle tested WordPress pattern. Native WordPress menus already solve so many of these challenges. While they don't provide much in the way of styling, they handle all of the questions about structure, custom links, categories, automatically adding of pages, attributes, etc.

In my opinion, the Nav block should focus on providing styling options, which is actually the hard part of WordPress menus in this context.

If adding the current page to a menu while in the edit context is a priority, I feel like that is more of a WordPress core issue, as pages already have the ability to select parents in the sidebar, thereby affecting site structure, so I think it makes sense to be able to add the current page to a menu in the same context.

A use-case that I commonly encounter is a "Section Sub-menu", that is, a page that is the parent for several child pages, where a menu is needed for the child pages, rather than an entire site structure.

The site I am working on right now has "Services", with several child pages, each with their own child pages, so 3 levels, a total of 12 pages so far and more to come.

• Services
  • Service 1
  • Service 1.a
  • Service 1.b
  • Service 2
  • Service 2.a
  • Service 2.b
  • Service 3
  • Service 3.a
  • Service 3.b

What we want is a menu of this particular tree, which is very easy to build using existing WordPress menus, however, its more than a little painful to create in the current Nav block.

For starters, the search auto complete does not distinguish page hierarchy at all, so it's trial and error to ensure you are selecting the correct page level for similarly named pages. We have two pages titled "Buyers", but they are under different services. Impossible to tell which is which in the autocomplete as they have the same top level parent.

Secondarily, the Nav block does not allow for leveraging the existing ecosystem of WordPress menu enhancing plugins, such as ones that allow for setting classes, adding icons, etc.

Third, we now have two completely unrelated and incompatible methods of creating menus. This is very confusing and frustrating.

I understand the desire for creating a navigation in the page context, but I strongly recommend the Nav block at least support rendering a native WordPress menu.

[javierlorente]

Will it soon be possible to add native wordpress menus as a block in a post or even in the post and category editor?

[mapk]

Yes, there's a PR in the works, @javierlorente! 😄 https://github.com/WordPress/gutenberg/pull/18869

[collimarco]

I would like to add an existing menu as a block inside a page...

Any updates on this?

I can't find any "Navigation menu" block :(

[draganescu]

Howdy @collimarco The Navigation block is still considered experimental and it exists only when using the Gutenberg plugin. Right now the new block is on track for WordPress 5.9 to be released out of experimental and available as a core block in standard WordPress installations.