Navigation block: Menu item enhancements

[noisysocks]

• A block toolbar should be shown when a Menu Item block is selected.
• The block toolbar should contain a Link button which opens a URLInput for adjusting where the menu item links to.
• The menu item's label should be editable using direct manipulation.
• The dropdown menu (containing 'Edit label text', 'Move to start', etc.) should be removed.
• Needs design mockup: A user should be able to click through to the page that a menu item links to.

[tellthemachines]

The menu item icon in the above design isn't a dashicon is it? Are we moving away from those, and if so, where can I find a suitable SVG asset to replace it with?

[noisysocks]

The menu item icon in the above design isn't a dashicon is it? Are we moving away from those, and if so, where can I find a suitable SVG asset to replace it with?

cc. @jasmussen @mapk

[jasmussen]

It's this one: https://material.io/resources/icons/?search=naviga&icon=navigation&style=outline

You can inline it. Here's an optimized SVG:

<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24"><path d="M12 7.27l4.28 10.43-3.47-1.53-.81-.36-.81.36-3.47 1.53L12 7.27M12 2L4.5 20.29l.71.71L12 18l6.79 3 .71-.71L12 2z" /></svg>

[tellthemachines]

Thanks @jasmussen!

[draganescu]

About the interaction of linking the menu items

Part 1: change the inserter or add a block directly

The point here is that we don't want the inserter to behave differently depending on the block invoking it.

If we start modifying the inserter in one block, then we'll have to add a hook by which the contents of the inserter can be changed. If there is such a hook anyone could make the inserter be anything so we loose cohesion in one of the most foundational aspects of working with Gutenberg.

The inserter should always show a list of blocks. However, the new exploration in the nav block work is that for a list containing just one item, we shouldn't show a list, but insert the item directly. It makes for an improvement, shortening the number of steps by removing a really useless one.

So we should not block this upgrade to the way the inserter behaves simply because we're uncertain about the default state of the menu item. Instead imagine a columns block that for every column the only allowed block is an image. There would be no problem there that when we click on the appender we get an image directly, and there is no problem because the default state of the image block is very explanatory and doesn't look empty.

Part 2: link or label first

I think that the reason for the whole debate is that we think of a menu as a collection of menu items, when in fact the menu is a collection of links.

In creating a link the steps are:

1. Write the text you want linked
2. Select the text you want linked
3. Link it

That is because the most basic thing one needs for a link is the label, the clickable thing. Only after that the destination is important, hence the link is added later.

In case of the menu we can argue the same: first we need a label and after we have a label we decide what the link is.

Yet, because we are in a menu item which is all but a collection of links, we know that everything is linkable in the context of an item, therefore we remove one step from the general way of creating links, the selection:

1. Write the text you want linked
2. Link it

This approach nevertheless has the disatvantage that the default state of the menu item looks empty.

When people write hyper text they are composing so the links are part of the form of the composition. When creating a collection people are not composing anymore, we are more strongly oriented on the functional liason that holds the collection as a concept. In the case of menu, the functional liason is the link.

That means the basic first step we all think of is "I will add a new link to the menu". Because we start with the functional idea of link, we shluld expect that adding the link is the fist thing the UI presents to me.

Because of the two things above I would present the URLInput as the first thing the menu item component shows, the initial state. After a link is chosen, the menu item defaults to a label editor and the link button in the toolbar will be used to access URLInput as a popover for link editing.

In the mockup on the left: adding a menu item results in directly being able to search in the URLInput and have suggestions show up. Default suggestions are from recent/top pages/posts. Pasting or writing a link would change suggestion to crawled title of link.

In the mockup on the right: adding a menu item results in a placeholder which has the URLInputPopover on top. This seems to be easier to implement as the left mockup requires a disconnect between the URLInput which is bounded by the MenuItem and the Popover with suggestions.

[shaunandrews]

The point here is that we don't want the inserter to behave differently depending on the block invoking it.

I agree with this, but then the rest of your comment seems to contradict this point.

If we take a look at how the + icon works, we can see the following flow:

1. You click on the + icon.
2. A popover appears with things you can add.
3. You select one, and its added to the document.

The flow you propose actually changes this significantly:

1. You click on the + icon and a block is added to the document.

It is less steps, but it changes the behavior of the inserter. The inserter never directly adds a block without first letting you choose. Adding the block immediately is going to lead to confusion as people won't expect it based on their experience with the rest of the editor.

It will also lead to users often having to delete these immediately added blocks, as they might have just been exploring the UI.

If we start modifying the inserter in one block, then we'll have to add a hook by which the contents of the inserter can be changed.

Why would we have to add a hook? Is there another way to let the Navigation block define the contents of the inserter and/or extend the inserter to optionally show the Link UI?

If there is such a hook anyone could make the inserter be anything so we loose cohesion in one of the most foundational aspects of working with Gutenberg.

I'm of two opinions here; The inserter is somewhat sacred and shouldn't be allowed to be changed by a plugin. The ability to change the UI of WordPress is a pretty big opportunity for developers to build amazing things.

I lean slightly towards allowing developers to customize the contents of the inserter.

The inserter should always show a list of blocks.

If we consider a Link a block, then the Link UI is still showing a list of blocks.

It makes for an improvement, shortening the number of steps by removing a really useless one.

I actually think this creates more problems than it solves — and that removing steps in a flow isn't always an improvement.

--

That is because the most basic thing one needs for a link is the label, the clickable thing. Only after that the destination is important, hence the link is added later.

I think this might be the wrong way to think about it. For paragraphs and other text-focused blocks, the text is the primary focus; Adding a link is a secondary function.

However, for the Navigation block the primary focus is adding a link. Writing the label first, and only then choosing a link is a confusing flow. It also requires you to type a label even if you then choose a page/post that has a title — this is going to annoy and confuse people.

[draganescu]

It also requires you to type a label even if you then choose a page/post that has a title — this is going to annoy and confuse people.

Both of my proposed solutions specifically avoid this.

The inserter is somewhat sacred and shouldn't be allowed to be changed by a plugin. The ability to change the UI of WordPress is a pretty big opportunity for developers to build amazing things.

I do not mean anything is sacred :) I do not want it to be sacred. I was making an argument on why the behaviour of the inserter will change if we allow it to change.

Why would we have to add a hook? Is there another way to let the Navigation block define the contents of the inserter and/or extend the inserter to optionally show the Link UI?

Of course there are other ways. I was simply thinking on how to not make the navigation block a bespoke solution, but something to makes heavy use of the things we have.

[getdave]

I see the logic behind both of these arguments. Thanks for articulating them so clearly.

With a situation like this where there are two opposite views, I can't help but feel like interactive prototypes showing both of these approaches would be a great way to test this without the large upfront investment required to actually go through the process of developing them in code.

We could then throw these prototypes over to the community and ask for user testing. What works for users and feels best is the goal right?

As mentioned noting is sacred and developer hours are costly in terms of time vs a throwaway prototype.

Have we ever used such an approach before?

Would we be in favour of exploring this as a way of coming to a conclusion?

Do we have any community members who can function as testers?

[noisysocks]

Have we ever used such an approach before?

I totally agree however that testing this with real users is how we'll get to a decision. I don't think that we've ever built out two alternate approaches before. Typically our approach is to keep development costs low, encourage experimentation, and discourage sacred cows. For example, the interface for inserting a block went through several drastic iterations in 2018. In other words: I'd suggest we put one of these approaches into master and see how it works 🙂

[mtias]

Thanks for the discussion everyone. There are some good points being shared already, though I think we are conflating a few things. Choosing a menu item is the primary interaction of this block, and should be optimized for that (the label is subordinate); at the same time, the navigation block currently only supports a single block and should work as any other parent-child block set (no custom inserter).

The (+) should indicate "here you can insert blocks", the only operative difference is if there's only one block to be added, in which case we'd insert it directly. This is orthogonal to this issue specifically, as it's going to be a standard behaviour for blocks that only support a single type of child.

It's very important to separate inserting a block from choosing a link property (page, post, category, custom link) because that's how we end up with ad hoc interfaces. In the future we might also support more blocks within navigation menu — like "social icons", "search", and so on. The actual pages, posts, etc, are not blocks, they are the content of a block called "Menu Item" or "Link".

Making the "choose a link" the primary interaction compared to customizing the label is totally fine, and we should explore how that UI looks once the block is inserted — could be opened and focused by default, the actual label could read "Choose a Link" or similar in placeholder state.

[noisysocks]

Closing this one out as #17986 implemented the bulk of the functionality.

Needs design mockup: A user should be able to click through to the page that a menu item links to.

@mtias: Is this something that we still want? If so I'll create a new issue.