It would be an understatement to say the navigation block has been one of the most challenging parts of phase 2. It has been a vehicle for countless improvements to the block framework, bringing substantial enhancements to the APIs, the block list view, inner blocks, variations, and so on.

So far we have deconstructed the problem of navigation through a suite of blocks and functionalities that range from simple links to mega-menus combining many different block types at once. This setup has allowed us to stretch the current capabilities to their very limit and has the potential to address most of the problems current menus have in WordPress (for example, being trivial to add a "WooCommerce Cart" block to a site's navigation). This is a great foundation.

However, an evaluation of the current state of the navigation block would highlight how it has mostly all the pieces needed to accommodate a wide range of navigation expressions while still falling short from a user experience perspective for the most basic kinds of menus. In other words, right now the block steers a bit too much towards optimizing for complex navigation and customization while being too convoluted for the most common flows (just a few pages with one or two nested menus). This needs a mild course correction.

Default Experience

We have all the tools virtually ready (see #27593), so let's optimize them now for the 80%.

• Contextuality. The [+] inserter right now allows choosing among multiple blocks. Instead, let's try making it insert a Page Item by default. If the navigation container only has page items, the [+] should always be inserting page items. If there is another block contained within — like social links, or search, or a spacer — we'll open the quick inserter to choose from.
  • The top level header inserter, instead, should always open with all available blocks for the nested area.
• Let's highlight the default block better in the quick inserter. It should always come in first. A user should not have to think when they open a quick inserter if they are not looking for a specific block.

Making the insertion experience more contextual can help tailor the behaviour to what should be most optimal for each use case.

Transforms

Transforms are one of the hidden powers of the block editor. It's crucial we use them well to switch between block types in the navigation context.

• Transforming an empty "page item" should expose the most relevant alternative blocks for a navigation block (search, social icon, pages list, home link, etc).
• Let's consider supporting / on empty menu labels similar to how empty paragraphs allow both direct writing or switching to a more specific block type.
• Shortcuts. Let's also take a look at adding blocks as toolbar/inspector actions. For example, if we consider a search to be a common pattern, we can have a button in the inspector that says "add search block". This is akin to the flow we have on images to add overlay text (it converts to Cover but is exposed outside the regular transforms menu). The same might apply to adding social icons. This could exist in the toolbar as "Add Search", etc.

Patterns

It's time to start allowing initial states for navigation to be pattern-driven. A pattern should be able to express whatever layout they need while making it easy to be replaced by user content. This ranges from using "page list" for cases that are more straightforward, to using individual page items for composition that require careful placement of items. A user should be able to choose what page is assigned to a page item placeholder.

List View

The list view can be a very ergonomic way of interacting with menus, especially when it comes to nested submenus. How can we give more prominence to this editing flow?

cc @jasmussen @javierarce