Gutenberg: Navigation menu block: Adding menu items

[sarahmonster]

_This is intended to splinter conversation from #13690 and allow us to focus the conversation on one part of the problem at a time. We'll loop back to the tracking issue when we've determined a path forward. For this issue, we're focussing on adding stuff to your menu:_

How do I add a menu item to my navigation menu?

This issue assumes that you already have an existing menu on your page. How do you add more menu items to it?

We have a lot of prior art exploring this, which should provide a good view of the paths we've already gone down.

With these prior explorations in mind, here are some assumptions based on some initial research and conversations with Happiness Engineers at Automattic:

• Most people want to add pages to their menus.
• Some people, especially bloggers, want to add categories.
• Many beginners do not understand the differences between different page types. For example, someone might want to include a category to their menu — so they create a new page for that category, and then don't understand why their blog posts aren't showing up on that page.
• Similarly, beginner users expect there to be a correlation between creating pages, and having them show up in their primary menu.
• People want to create a menu for their social networks, but often struggle with setting them up. (Related: #13725, and overlaps with #13786)
• Adding tags, posts, and post types are significantly less common than pages, categories, and links.

Do these assumptions sound correct? Is there anything additional we can do to validate them?

[melchoyce]

Updated the issue description — have some concepts coming later.

[melchoyce]

This set of concepts explores two ideas: Search, and Search & Browse.

These designs are built under the principle of _the primary interface for a block is the content area of the block_. Adding and removing pages are a key task in menu management, and as such, the interface for them should be inside the block itself. This is why I'm not presenting an option that includes a sidebar or modal.

Search

This is a remix of @sarahmonster's previous concept, but the idea is pretty much the same — paste in a link, or search for existing content. If the thing you're searching for doesn't exist, you can create a new page directly from the block.

Pros

• All content is treated the same way, minimizing cognitive load.
• Theoretically would be easy to quickly add items, once you get the hang of it.

Cons

• You need to know — or remember — what you're searching for. Could be easy to suddenly forget what you wanted to add.
• You can only add one item at a time.

Search & Browse

A combination of the above, plus a browsing component. Browsing would act a bit like the current lists in both menus.php and the Customizer, where your content is grouped into sections. Searching for an item shows the results still divided by section. (You'd also be able to create a page from this interface, it just didn't make it into the mockup.) Instead of needing to manually click a button to add the items, selecting a checkbox would add the item to your menu, and the popover would remain open. Deselecting the item would then remove it (and you would also be able to remove items from the menu without opening this popover). Checkboxes might not be the best UI for this — let's chat about it.

Pros

• Benefits of searching, while still able to browse if you don't remember what you're looking for.
• Can add multiple pages at once.

Cons

• Likely wouldn't scale well.
• Since your content is grouped by its page type, you'd still need to understand the difference between them.

What do you think?

1. Are there alternate approaches we should explore?
2. Which of these approaches feel most user-friendly?
3. Are there considerations we haven't considered yet?
4. Do any of the previous explorations seem more promising?

[mapk]

Awesome concepts here, @melchoyce! Adding items this way feels natural.

Search

If the thing you're searching for doesn't exist, you can create a new page directly from the block.

I love the ease at which this happens, however, would existing users struggle with the indication that they're only adding "pages" to the nav block, or could we imagine this as a way to help shift paradigms that "everything" is a "page"?

• You need to know — or remember — what you're searching for.

I think if it's a good search experience, this shouldn't be too bad. If anything I'd remember some sort of keyword with which to begin.

Search & Browse

The Popover looks great when tied to the "Add page" CTA, but in the last little mockup, I noticed the popover no longer does that after "Services" has been added. Should the popover still follow the "Add page" CTA? If not, maybe we should consider another way to show the triangle notch that doesn't leave it hanging.

• Can add multiple pages at once.

I love this option!

• Likely wouldn't scale well.

How so? Just b/c of all the things that could potentially be listed? A lot to sort through, I would agree. But with the option of a "search" feature, I think it's still acceptable.

Response to your questions

1. By keeping everything IN the block, I think you've explored the best ways to handle that information.
2. I feel more comfortable with the "Search & Browse" b/c it gives me a few more options I'd like, like already seeing suggestions of things to add, and having the ability to add more than one thing at a time.
3. I'm curious to see how the "Add Page" fits in with the "Search & Browse" mockup. Would I have to scroll to the bottom of the list to see that option? Hopefully not. 😉
4. I'm totally digging these approaches shared here!

[melchoyce]

I love the ease at which this happens, however, would existing users struggle with the indication that they're only adding "pages" to the nav block, or could we imagine this as a way to help shift paradigms that "everything" is a "page"?

I think most folks already think this way — something that came up consistently in my chats with Happiness Engineers is that people don't really know the difference between page types in the first place.

The Popover looks great when tied to the "Add page" CTA, but in the last little mockup, I noticed the popover no longer does that after "Services" has been added. Should the popover still follow the "Add page" CTA? If not, maybe we should consider another way to show the triangle notch that doesn't leave it hanging.

Yeah, I just forgot to reposition the arrow. Good catch 👍

How so? Just b/c of all the things that could potentially be listed? A lot to sort through, I would agree. But with the option of a "search" feature, I think it's still acceptable.

Yeah, worried about space and sites that have several dozen pages. I guess it's not much worse than how nav-menus.php currently works, though.

3. I'm curious to see how the "Add Page" fits in with the "Search & Browse" mockup. Would I have to scroll to the bottom of the list to see that option? Hopefully not. 😉

I can explore that next!

[sarahmonster]

I'm leaning toward the "Search" over the "Search and Browse", primarily because it feels less intimidating—there's less stuff to look at and I feel less paradox of choice. I suspect for new users, this would be a more pleasant solution that won't require them to unpack WordPress' different content types.

That said, there may be a way to allow users to browse for content if they can't find what they want. Could we offer a "Search or Browse" switch at the top to toggle between the two mechanisms? Or perhaps return a "Browse for content" option if the search yields no results, or few results?

A few notes for accessibility considerations:

• Let's shift the placeholder text into a label so it's always present and readable for screen readers.
• Do we need a "apply" button of some kind? I'm thinking about the link insertion pattern we currently have and that is forever tripping me up, because I expect the link to apply itself immediately.

Some additional commentary here: https://www.a11ymatters.com/pattern/accessible-search/, but it would be great to get the accessibility team's input before we get too deep into the weeds here. (@LukePettway perhaps?)

Given that this pattern is so similar to the patterns used for adding inline links and linking a button, this is a great opportunity to unify all these interfaces into a robust universal component that could then be reused across WordPress (and potentially to clean up the many different search interfaces). This could be an opportunity to unify these experience across the entirety of the product whilst also making a teensy accessibility win.

[melchoyce]

3. I'm curious to see how the "Add Page" fits in with the "Search & Browse" mockup. Would I have to scroll to the bottom of the list to see that option? Hopefully not. 😉

Ah, I actually did mock this up. It appears when you search for a page that doesn't exist:

Let's shift the placeholder text into a label so it's always present and readable for screen readers.

Yeah we need to do this, and it also needs to be updated in the existing component.

This could be an opportunity to unify these experience across the entirety of the product whilst also making a teensy accessibility win.

Would love this!

[LukePettway]

@sarahmonster the article you linked is an excellent reference for how a search like this should work.

Another good example is the one detailed here: https://haltersweb.github.io/Accessibility/autocomplete.html

It outlines some of the more technical and content approaches to consider.

I really appreciate the thought into having a fully visible label, especially since placeholder text should never serve as the label.

As far as buttons, how would these component function? When you type in the search field, I assume a keyboard or AT user would press enter on the item they wish to add to the list. I feel like a button would only be necessary if you could select one or more than one option at a time but that seems like it might be more confusing.

Content wise the results would need to have some assistive text to infer the type of content a result belongs to: post/page/etc.

There are some considerations around the Create page button:

1. If this is a separate control which doesn't exist within the results dropdown, then blind users might not know it exists at all since they might not anticipate this control having additional features inside of it

2. If it is part of the results dropdown then is it included in the count of returned results? If I search for "my page" and nothing comes up, ideally the component should announce "0 Results Found" or something like that. However, that wouldn't be the case because there is technically one. Announcing one result would be misleading too because the one thing returned is not an expected result.

How often do users find themselves create a page in this menu? It might not be a bad idea to only display that if no results are found. (No Results Found for "_search term_", Create "_search term_" Page), you get the idea.

[melchoyce]

All good points, thanks @LukePettway.

As far as buttons, how would these component function? When you type in the search field, I assume a keyboard or AT user would press enter on the item they wish to add to the list. I feel like a button would only be necessary if you could select one or more than one option at a time but that seems like it might be more confusing.

In the "search" example, you'd just pick one at a time. When you select it using any of input method (mouse, keyboard, etc.), the popover would close, and the menu item you selected is added.

In the "search and browse" example, I was thinking that when you toggle a checkbox, you'd see the menu item you toggled added to the menu in realtime, and the popover would remain open until you click or esc out of it.

re: Create Page button:

At some point in another round of ideation, I tried this:

But I think your ideas to hook into "No results found" works quite well — I'll give that a try.

[scruffian]

Drive-by comment, feel free to ignore:

When I see a UI like the search & browse one, my eye is drawn to the browse area as it's bigger and I forget that search is usually better. What do you think about hiding the browse option and only revealing it when a user clicks "browse for a page" or something similar? That way users would be prompted to search first but could still browse if they wanted to...

[kjellr]

One thing that I didn't see mentioned explicitly above is that the "Search & Browse" direction is basically a variation of the Block Library:

It's got the search bar on top and panels of options below that. The main difference is that the items inside are displayed in a list instead (which makes more sense in this context). I really like the familiarity there. 👏

Checkboxes might not be the best UI for this — let's chat about it.

I'm not _100%_ sure that checkboxes are the best UI element for that either — if we're following the pattern of the block library, we'd expect the popover to close after something's been added. I do see the clear benefit to allowing for multiple selections here though.

I wonder if we can set it up so that tapping/clicking on different areas performs slightly different actions. Similar to how tapping on different areas of the Spotify queue does different things:

_(Tap on the left to perform actions on multiple songs, tap on the right to play that specific song)_

For our purposes, that could be: check a checkbox to select multiple items, or just tap the name to add to the list and exit. This could end up being super-weird, but we may be able to make it make sense visually.

Alternatively, we could maybe have some sort of "select multiple items" mode that you can toggle into somehow? (Or, we could just keep the checkboxes. 😄)

[jwold]

Search vs Search & Browse:

I'm torn here. Search & browse feels more useful, but search is simpler. My sense is that I would be unlikely to remember everything I've created, so Search & Browse would likely aid discoverability.

In the cons of Search & Browse, I wonder if you could expand on why you believe it wouldn't scale, and why different content types could add confusion? Feel there's more there that I'm not quite grasping.

A few things @melchoyce shared:

These designs are built under the principle of _the primary interface for a block is the content area of the block_.

Completely agree.

You'd also be able to create a page from this interface, it just didn't make it into the mockup.

Love this!

[sarahmonster]

In the interest of restricting in-block interactions to only the core interactions, and moving more advanced options to the block inspector, an approach to explore here might be moving the "browse" part of the interaction into the inspector, and keeping only "search" in the block itself (with a link to easily jump to the advanced "browse" controls.

Something along these lines:

[sarahmonster]

Since design explorations have largely concluded here, I'm closing this ticket as non-actionable, and we can loop back to #13690 or new issues for any further conversation that comes up as development work progresses.

Thanks everyone for all the feedback! 🙌