Navigation menu block: Refine how users add new menu items

[sarahmonster]

From #16821

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.

Prior art

When we originally started working on this block, @melchoyce and I explored a number of different potential approaches to adding a link inside your navigation menu. See #13789 for mockups, ideas, and discussion.

The solution that we landed on was a search (or type-your-URL) interface—basically a beefed-up version of the inline link mechanism, with more affordances built in for accessibility and more flexible finding-of-your-content:

We figured that search would be the primary, and most natural, way for users to find their content, without having to worry about what type of content that might be (a distinction that isn't clear for many users). This search interface is similar to how tools like Notion work.

The label was directly editable, and the link was editable using an option in the dropdown menu. We also included browse as a backup option, for users who don't know what they're looking for exactly:

Revisiting the issue

I'm a little unclear on the parameters here, so I'd like to gain a little more clarity prior to revisiting explorations for this so I can direct my efforts better. cc @mtias @mapk

1. What's the primary user problem we're trying to solve?
2. What makes search a suboptimal pattern to use here? What makes us think that search shouldn't be the primary interaction?
3. When we say "add block icon + should add an inner block with one click", what's the rationale for that measure, given that users will need to then click a second time to create the link or find their content?
4. Do we already have an idea of what we're looking for here, or are we looking to brainstorm more divergent solutions again?

[mtias]

Thanks for the exploration and thoughts.

We figured that search would be the primary, and most natural, way for users to find their content, without having to worry about what type of content that might be (a distinction that isn't clear for many users).

What is this assumption based on? I think there are valid use-cases for search, but it's not necessarily the unique most intuitive interaction pattern for every user. I think we should and can have both — the same way a certain user might rely on searching for finding apps on their phone, while others would always browse their screens of apps. This is also how the block inserter works — you can search but you can also just browse.

My point is we should not do one at the expense of the other and that we can combine and optimize both use cases. For example, if the user doesn't type anything in the search box, we can show a few of the top-level pages. Something like this:

Also, for complex site structures, searching just the title won't be enough. If I maintain a multi-lingual site and I search for a page titled "Mary Shelley", I wouldn't be able to tell if it's my Spanish or English version unless we also show part of the hierarchy tree in the result.

[sarahmonster]

There's more discussion as to why we decided to prioritise search as the primary pattern here (with an easy switch over to browse) on #13789, but it essentially boils down to:

• Keeping the interface simpler & less complex, confronting the user with fewer choices up front.
• Mirroring more closely how adding a link behaves in other contexts (buttons, inline links) for consistency.
• If we've already populated their menu with their top-level pages as per Navigation menu block: Revisit placeholder/default state #17096, adding new menu items is more likely to be a direct hunt for specific pages, and adding top-level pages to the search interface wouldn't make sense here, because they'd already be added to the menu.

Is it technically feasable for us to add "smart" suggestions like this whilst avoiding suggesting a page that's already present in their menu? I'd love it if we could provide more contextually relevant and helpful suggestions for users, but want to be sure we don't accidentally wind up promoting pages here that the user doesn't want or need.

If I maintain a multi-lingual site and I search for a page titled "Mary Shelley", I wouldn't be able to tell if it's my Spanish or English version unless we also show part of the hierarchy tree in the result.

This is an interesting problem—how do we handle this situation with the current link-search paradigm? I'm not sure that showing the hierarchy tree for all search results would be helpful (because it could potentially introduce a lot of noise), but this is a case where switching to "full browse" mode (where the full page tree is visible as per above mockups) would be more useful than searching. We could also explore ways of contextually showing more information in cases where the search results show multiple entries with the same title. (See also: #8573, #13641, #16534)

Once we have clarity on the direction and what we're looking for here, (see "revisiting the issue" questions above!), I'll work on some more explorations here, but I want to be sure we're on the same page before diving into ideas that don't meet our needs.

[mapk]

Okay, let's work through this a bit.

1. What's the primary user problem we're trying to solve?

As a user, I want to add an item to my Nav block. This item could be a page/post/category/tag... whatever. I'm not always sure what can be added and/or the linked item may not even be created yet.

2. What makes search a suboptimal pattern to use here? What makes us think that search shouldn't be the primary interaction?

Search relies on the fact that you know what you're searching for (I know that sounds ridiculous, but there needs to be some level of exploration afforded to the user). Search also may not search all content (ie. media, if someone wanted to link to a specific PDF file or something). In this way, Search feels like it demands too much from me. I'd like to be "guided" through this in an intuitive way that drills down to the exact piece I need, or provides really great suggestions. @jasmussen's mockup below, while simplified, really felt natural for me.

However, I can see this getting overly complex with lots of items. The names of these items could also be unwieldy causing clutter below each icon. @karmatosed's mockups of a list view help this.

But I still want to visualize this as a block. This leads me back to this particular mockup created by you or Mel.

But what happens after I select the Page block? Maybe we can combine forces into one tool to break them all?

I realize at this point I'm starting to break the Inserter panel's purpose, but I thought to give it a go anyways. I'm also adding more interaction into a smaller place which can get convoluted. But with the addition of that panel, and some more refinement, I really think it feels pretty good!

3. When we say "add block icon + should add an inner block with one click", what's the rationale for that measure, given that users will need to then click a second time to create the link or find their content?

I'm not sure on this one myself. @mtias, can you help fill in the idea behind this flow?

4. Do we already have an idea of what we're looking for here, or are we looking to brainstorm more divergent solutions again?

Number 3 feels like there might be an idea brewing, but I'm equally unclear.

[sarahmonster]

Two small things to consider here: we already know that users often struggle with the distinction between posts, pages, and other types of content—it might be good to pursue a direction that doesn't confront them with this choice straight away.

Another thing to keep in mind is accessibility—let's try to avoid putting help text in the placeholder, and instead use labels and help text to guide users. We'll also want to be sure that the selection mechanism is accessible for keyboard users, which is something we iterated on when we originally explored here.

That said, we have lots of different mockups and explorations, both here and in the original issue. To move forward, we'll probably want to select a direction and then iterate in a coded prototype.

[jasmussen]

However, I can see this getting overly complex with lots of items. The names of these items could also be unwieldy causing clutter below each icon. @karmatosed's mockups of a list view help this.

But what happens after I select the Page block? Maybe we can combine forces into one tool to break them all?

Great thoughts. I struggled with this issue a little bit myself when I made this mockup:

However I still figured that it was best to show ALLL PAGES AND ALL POSTS in that same interface. For a couple of reasons:

1. You only have one button, one search field.
2. It is optimized for most sites which don't have thousands of posts and pages.
3. It is not any worse for complex sites with thousands of posts and pages where you'd likely want to search anyway.
4. It embraces the complexity up front and shows everything, every individual page and item, right upfront.

This is in contrast to the following mockup, which otherwise looks great:

This is less complex up front, but it shifts that complexity down the chain. It's perhaps easier to have an overview immediately when opening the block library, you can easily scan what types of items you can insert. But it then shifts the choice of which item you want to insert to each individual child block, requiring additional UI.

Additionally, it isn't actually that different from the current UI, which is this:

So yeah, if we want to show EVERY ITEM in the block library, we have the benefit of a single unified UI and no additional UI for each child block. But we have the downside that we need to add pagination.

[melchoyce]

Are we still planning on letting people turn off the side panel?

[sarahmonster]

@mtias Since there's a wee bit of a time crunch here, it would be helpful to get your feedback here. We may want to start by narrowing down on an approach (the block library pattern vs a search/browse interface) and then iterate as needed.

[karmatosed]

Are we still planning on letting people turn off the side panel?

Yes, although this could be seen as a 'seperate' version of that. It gets tricker as a visual but possible. @jasmussen if that was set to off do you think it's expected to be off here?

[jasmussen]

Yes, although this could be seen as a 'seperate' version of that. It gets tricker as a visual but possible. @jasmussen if that was set to off do you think it's expected to be off here?

Speaking about this image:

The flow is this:

• You insert nav block
• You press the appender plus at the end of the list of menu items, so there's valuable context for what you are about to insert
• You see the block library and accordions showing what you can insert: categories, pages, links, posts. You can search to narrow it down.

Given this flow, in my old noodle and without actually testing it, this feels sufficient even if you turn off the helpful preview panel. It most definitely feels sufficient for a version 1.

CC: @shaunandrews I would love your thoughts on this also.

[mtias]

The block library pattern is interesting and worth exploring further. That said, a simple combination of the current URL auto-completer with the page structure browser could also be a good start.

Looking at all the concepts, it seems there's a few things that are common regardless of presentation:

• A way to search for an item. (Prior art: URL auto-completer.)
• Page / Category selection.
• Custom link.

Can we make sure at least the ingredients are covering the needs even if there's still some room to see how they can be combined for the best experience?

[noisysocks]

Let's iterate on the existing URLInput component for v1 of the Navigation block. #17557 tracks this work.