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

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.

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.

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.

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 💯

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.

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!

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

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.

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

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

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.

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.