A Lighter Navigation Block Experience

[mtias]

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

[talldan]

@mtias Agree with most of this—I definitely think the experience should be optimized for adding links. There's a similar discussion on #33867 which is one of the places the busy quick inserter has been discussed.

The top level header inserter, instead, should always open with all available blocks for the nested area.

I have concerns that not having a quick inserter at all will make the other blocks hard to discover, but worth testing it.

I think the block library has previously been considered an optional piece of UI in a block editor, and the nav editor currently doesn't have one, so that would have to be implemented.

[jasmussen]

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.

With this in mind, I took a stab at a reduced flow for inserting items:

• Click the plus to immediately insert a page item.
• Just as today, when the page item is selected, the URL picker is opened, but it's optimized for surfacing pages on your site, showing their hierarchy
• If you have more than n pages on your site, we show the most recent pages, and search behaves as it does today.

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.

As an exploration, here's what it might look like if the URL dialog was able to surface immediate block transforms as part of the interface:

It's unclear whether that's necessary given the additional weight it adds. It may be better to spend the effort on improving the transforms interface itself, which we could theoretically then leverage right here:

There's an added simplicity and generic quality to this one which might allow it to scale better to additional contexts. Let me know your thoughts.

[priethor]

I really like the idea of still allowing to add blocks from the quick inserter but less prominently, @jasmussen, and I'm equally unsure about the extra height it adds. The second approach looks less overwhelming to me if we consider there would usually be more blocks and/or blocks should be searchable.

Going one step further, how do you feel about a tabbed approach for the quick inserter, with the default tab to add links and a second tab to add blocks? It would still offer the current functionality but would also reduce the friction to quickly insert links.

[jasmussen]

Going one step further, how do you feel about a tabbed approach for the quick inserter, with the default tab to add links and a second tab to add blocks? It would still offer the current functionality but would also reduce the friction to quickly insert links.

I actually tried that as my first instinct, but for a few reasons I ultimately ended up abandoning that exploration:

• In the flow outlined, the block has already been inserted, so this is more like an expansion of the Link URL dialog than the inserter. In that vein, the choosing of a block is more like a transform.
• Making it tabbed added more complexity to the interface than I had expected.

As part of a separate exploration (#30170), I did try integrating the transforms into the block type itself, as a dropdown:

That might still make sense, but inspired by the comments on improving transforms for 5.9 (the tracking issue mostly mentions patterns, but UI improvements will likely benefit/address both), I did worry that adding yet another way to transform blocks that differed too much from the existing interface, we'd end up just diluting both. That's also one of the reasons I personally like the third option: it's squarely optimized for inserting pages, but there's a "transform" escape hatch that will benefit from any improvements we make to transforms overall.

[priethor]

In the flow outlined, the block has already been inserted, so this is more like an expansion of the Link URL dialog than the inserter. In that vein, the choosing of a block is more like a transform.

This factor is key and favors leveraging transforms as proposed in the opening post and your third option 💯

[jasmussen]

Based on the above discussion, I thought it helpful to fill out blank spots in the flow on transforms. The basic menu building remains the same: just click the plus to insert the default block type, a Page Link.

The following principles are important for switching context from basic to more advanced menu building:

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.
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.

So, starting from a basic menu, the flow for for advanced menu building becomes:

1. Click the plus to insert a Page Link
2. Click "Transform" in the dialog that opens.
3. The Transform mode of the dialog lets you pick from a curated list of other types.
4. Once you've chosen a block to transform to, from now on the plus opens the quick inserter (which is curated).

Let me know your thoughts.

[tellthemachines]

Hey folks, I just did rough draft of using the appender to add Nav links by default in #34899 . Feel free to have a play and let me know what you think!

[karmatosed]

@jasmussen I like this iteration because it focuses on single tasks and takes me through the flow a lot more than previous versions of navigation. I think that might have been one of the roots of past navigation mistakes, trying to surface too much.

One concern I do have is knowledge of the term transform, but I think that might be negated with some expectations around the flow. I would probably recommend prototyping as soon as possible as low-fi this up into actual code because honestly, navigation needs to be felt - this has, in theory, worked and felt wrong in the application a few times now. I think this has a strong chance, though, of removing some of the past issues.

[jasmussen]

The flow outlined here is definitely weighted towards the simpler flow, with unlocking the more advanced flow intentionally reduced in prominence. The reason I went with "transform" for now, and I sense part of why it was suggested in the ticket, is that this is an interface that deserves improvement across all blocks. Even the basic flow of transforming a paragraph to a heading could use a little love, and I sense future efforts in that spot as well due to the mention of transformations of patterns in the preliminary road to 5.9 post.

And so the idea is that if the interface for transforming blocks is improved and simplified, that separate effort will benefit the navigation block as well. And in the mean time, the lighter navigation effort can focus on the most important part of the basic flow.

Within those two efforts together, there are rich opportunities for improving the visuals, the phrasing, and the flow.

[gwwar]

Transforming an empty "page item" should expose the most relevant alternative blocks for a navigation block (search, social icon, pages list, home link, etc).

I'll investigate some additional transforms for the navigation link

Added #34978

[gwwar]

Here's a draft of what the inserter looks like if we move the link variations to block scope. (I wouldn't recommend landing this until we have an alternate way of filtering link types.)

#35056

[talldan]

One drawback of this new experience is that there's now no convenient way to insert anything other than a link into an empty navigation block.

Using the main block library is also a little tricky as the user needs to have a sibling selected, they can't select the nav block itself and insert blocks into it, though this is what I instinctively tried first.

edit: I suppose drag and drop is still an option, that didn't occur to me straight way.

[jasmussen]

One drawback of this new experience is that there's now no convenient way to insert anything other than a link into an empty navigation block.

This is definitely leaning in the 80% direction, heavily so. Though I would also note, we've solved one half of the effort: the simpler menu building. The second half is to make the transforms more obvious. I shared some additional mockups in this comment, but will copy them here for visibility, and the hopes that they might help inspire some ideas.

---

What might we do beyond the transform button in the link control? Would it make sense to use toolbar buttons (either on Link or on the Navigation itself) to call attention to some of the other possibilities, like Search or Social?

I think it valuable to approach this from a generic viewpoint, seeking a solution that could work for any container block beyond Navigation. I don't think "Buttons" will be able to contain other child blocks any time soon, but if in the future these container blocks start to converge (we already have a Row block that's like the Buttons block but for any child), a solution we find here would benefit both.

That's what informed the initial exploration, which embraces the transforms interface:

Keeping in mind that as soon as the navigation container has more than one type of block, we revert back to the full quick inserter, all we need is an "escape hatch" block to enable that. So we could look at giving more prominence to a curated list of child blocks:

Another option is to put a toggle in the inspector, which when untoggled simply allows additional blocks. This toggle might even be able to exist in addition to the "transform" options illustrated above:

Note that the labels and phrasing in the above would need work.

[tellthemachines]

👋 Is any work currently in progress on including transforms inside the link popup, or adding a control to the Nav sidebar to show more blocks? If not, do we have an idea of which of these options we'd rather explore? I'm happy to work on a POC but don't want to be duplicating efforts if anyone is already on it.

[jasmussen]

Is any work currently in progress on including transforms inside the link popup, or adding a control to the Nav sidebar to show more blocks

Not that I'm aware of, of have seen PRs of, no, and I think it'd be great to take a stab at it. Happy to help in any way I can.

If not, do we have an idea of which of these options we'd rather explore

Of the suggestions mocked up above, my instinct would be that surfacing a few key transforms right in the URL picker might be the most potent, as it's right there when you'r building:

It also seems okay to curate the three items in that list, though I'd probably replace the spacer with a Site Logo instead.

Edit: Note that the above mockup also shows a tree-view scrollable list of pages on your site to pick from, which feels like a valuable improvement over showing the 3 recent published items — but still seems like a separate exploration from just the transforms.

[getdave]

Is any work currently in progress on including transforms inside the link popup, or adding a control to the Nav sidebar to show more blocks

@tellthemachines @jasmussen The work to achieve this is likely to be quite involved. I've looked into:

1. Trying to render a hierarchical list of Pages in the <LinkControl>.
2. Rendering a transform UI within the <LinkControl>.

#1 will require a number of major modifications to the to allow it to retrieve and render data different when we are looking forPages`. The current Search endpoint doesn't return hierarchical data (it doesn't really make sense in that context so I don't see that changing) and the rendering is heavily biased towards the currently visual implementation.

#2 will require building new UI and controls into <LinkControl> which only are only valuable in a limited set of circumstances (ie: within the Nav block - unless I'm mistaken 🤷 ).

Therefore I think we should at least explore utilising a completely custom control for the Nav block when it is searching for Pages. When we're looking for other types of entities or adding custom links then we can continue to use <LinkControl> but the experience designed here is sufficiently unique that I believe it will be difficult to achieve without some seriously "hackey" shoehorning in the (already complex) <LinkControl> codebase.

Appreciate that's a dissenting opinion, so I'd be happy to discuss further before anyone dives into implementation.

[jasmussen]

To clarify, the transform UI could be a separate effort to the hierarchical page list.

I'm not fully qualified to speak to this, so forgive me if the question here lacks nuance: could the "show 3 recent items" be extracted as a component consumed by most link interfaces, and just replaced with a "show pages" item? Or how integrated does the suggestion component have to be in order to function? Asking because longer term it would be nice to let that piece work in even mor contexts:

[getdave]

Asking because longer term it would be nice to let that piece work in even mor contexts:

If we're going to make these UI changes universal across all instances of Link UI then that makes it somewhat easier. Were you envisaging these UI updates landing for WP 5.9?

[jasmussen]

Were you envisaging these UI updates landing for WP 5.9?

Through rose colored glasses I had hopes, but I recognize it's probably not that realistic with a week or so to go for the freeze. That's also why I suggested that the transforms interface at the bottom could be, potentially, a small first step.

[tellthemachines]

Therefore I think we should at least explore utilising a completely custom control for the Nav block when it is searching for Pages.

Thanks for sharing this @getdave ! I wasn't thinking of tackling the hierarchical page list though, just the part where we showcase a few transforms to make it easier to jump from basic, link-only nav to a more complex one.

I just did a very rough POC of adding a few transforms to the bottom of the link control: #35857

It'll need some styling if we want to go with this approach, but I thought I'd try it out in code first. It works, and it doesn't add any complexity to link control, so could be worse 😄

Feedback appreciated!

Question: would we want these transforms to appear even if the Navigation already has other types of blocks and quick inserter is available?

[tellthemachines]

Is there anything left to address here? I've marked it done in the Navigation tracking issue because for 5.9 purposes all the high priority features have been implemented.

[mtias]

I think this is mostly covered. There are a few lingering things we can treat separately (name of menus, using the heuristic of only-link-items to determine whether a post type is created, etc).

Thanks for all the work here!