Option to bulk add entities of any type in Nav Editor screen

[getdave]

What problem does this address?

In the current Menus screen it's possible to add multiple entities at once pretty quickly (eg: Pages).

In the new Navigation Editor screen doing this is somewhat laborious and cumbersome involving repeated clicks and waiting for the link suggestions to pop up. Moreover, you can't immediately see all the entities available to you in a single view (basically we're missing the View all option from the existing screen).

I see this type of bulk creation interaction as being fairly important for folks who know how they want their menu to look and want to built it out quickly. Having to jump through the current interface's hoops seems over the top for them.

What is your proposed solution?

It should be possible to bulk add entities of any type. This will probably require some upfront UX and Design thought. One idea is to do this via a Modal. We'd need to consider how we'd handle nested contexts.

[javierarce]

Instead of using a modal for this… would it make sense to support some sort of bulk actions from the current URL component?

I imagine something like a toggle that users activate which add checkboxes next to each result. Then, instead of selecting a single URL, they can tick some checkboxes from the result list or refine their initial search.

[javierarce]

Here's a quick design & prototype for the idea I mentioned earlier:

Screen.Recording.2021-05-11.at.16.19.43.mov

• As the video shows, users search and check links. To see what they've selected, they empty the search field.
• In my quick example, the user doesn't have many pages that match the search term, but if that were the case, we could add a link at the end of the list to load more.
• "Clear selection" would remove all selected links, not just the visible ones.

Figma prototype

[annezazu]

@javierarce I love this exploration! Very intuitive to use. I'm curious how you imagine this would look in a situation where someone doesn't use the search first and if there's a way to lessen the number of steps. Right now, there are by my estimate the following steps to get this done:

• Add the nav block
• Select setup option > start empty
• Select add block
• Select page link block
• Turn on Bulk Search (this is likely going to be hard to remember in the same way searching for page link block is hard to remember).
• Search and select pages one by one (this could be a lot of steps alone)
• Add links

On the flip side, the previous menu was fairly basic:

• Create new menu
• Under "Add Menu Items" > Pages, switch to "View All"
• Select whatever pages you want
• Add to menu

I'm also a bit worried about having "open in a new tab" and "bulk selection" having the same appearance when one impacts the link being added and the other option impacts how the block works (very different actions).

In case it helps too, this feedback came in from the FSE Outreach Program's sixth call for testing:

Choosing the pages in the nav was strange. The search is essential of course but it feels it could have a scroll to show all the pages (lazyload if many?)

[javierarce]

I'm also a bit worried about having "open in a new tab" and "bulk selection" having the same appearance when one impacts the link being added and the other option impacts how the block works (very different actions).

I agree with you @annezazu. Those actions in the footer do very different things and shouldn't have the same importance or look so similar.

And I also agree with your previous point about the simplicity and speed of use of the current interface. That's a good argument to support the use of a modal.

[javierarce]

I've been working on a couple of different new proposals for the UI of this feature. Here's a first idea based on a modal window:

Like in the original editor, users can use the dropdown to insert pages, posts, categories, tags, and formats. I haven't included "Custom Links" because we could let users add them through the inserter.

Another thing I haven't ported from the original interface is the option to select all the items on the list at once. I might be wrong, but my guess is that it is not an option that many people would use.

There are a couple of options to invoke this modal:

• From the toolbar.
• From the inserter.

In my opinion, the last one is better because it will allow users to insert the items on a specific point instead of just appending them at the bottom of the list.

In the Menu Figma file I've also included a different exploration: using a sidebar.

The sidebar could be toggled from a button in the header/top bar, but unlike the modal window (which could also be used in the Site Editor), this is probably a less reusable solution.

[getdave]

Love this @javierarce - thanks for developing it.

This is going to be a completely custom piece of UI and I'm not sure we can (easily) reuse the <LinkControl> so it's likely we'll need to develop from scratch. I know @youknowriad added a SearchControl components recently so hopefully that can be a starting point?

In my opinion, the last one is better because it will allow users to insert the items on a specific point instead of just appending them at the bottom of the list.

I think that's great thinking and an important feature. How are you seeing that work UI-wise though? I guess we can explore as we go along?

In the Menu Figma file I've also included a different exploration: using a sidebar....this is probably a less reusable solution.

I like the sidebar, but yes perhaps less portable to other contexts. Luckily the core of the UI you've designed translates nicely to either context so we can begin development and then decide on a final location in due course.

[talldan]

In the Menu Figma file I've also included a different exploration: using a sidebar....this is probably a less reusable solution.

Another option (that granted would be less reusable) would be making it a tab in the block library, which is something that possibly will need to be implemented in the editor as part of nav block changes - #34041.

[getdave]

@javierarce I really like the idea of using a sidebar as it's more consistent with existing editor UI patterns. I see you've explored this in Figma. Am I 👍 to proceed with that route in code?

[javierarce]

@getdave I need to update those designs and see how that option would integrate with the global inserter.

Let me refresh the designs and share them here so we can also have more feedback.

[javierarce]

Here's a proposal for the bulk inserter inside the sidebar:

I think the image is self-explanatory, but here are the main ideas:

• The inserter allows adding: Blocks, Posts, Pages, and Categories
• Since we have a short number of blocks to add, we don't need to show the search field on the top of the inserter
• The dropdown allows showing the full list of items or just the most recent ones (this could be the default option)
• If the list contains lots of items, we'll show a scrollbar

[getdave]

Nice 😍

Blocks, Posts, Pages, and Categories

Just noting that we'll need to support all of the options currently available in the existing Menus screen. If you register a CPT then you'll have an option per CPT. So this tab UI will need to be able to accommodate those.

[javierarce]

So this tab UI will need to be able to accommodate those.

Oh, you are totally right… here are a couple of ideas:

1. We could group Categories and the rest of the Custom Post Types inside an 'Other' item while maintaining the same interface (but losing the option to sort items)

2. We could assume that users are generally more interested in adding recent items and give them the option to load all the items through a toggle at the bottom of the page. This also makes the interfaces for Posts/Pages and Other behave in a similar way.

[javierarce]

I'm now wondering if the "Show all" toggle next to the "Select all" options could be confusing for the users 🤔

[getdave]

1. We could assume that users are generally more interested in adding recent items and give them the option to load all the items through a toggle at the bottom of the page

This is one of my pet peeves with this existing screen. 9 times out of 10 I just want to see everything by default.

I was wondering if we could have a 3 dots menu in place of the last tab (far right) which when clicked reveals more CPT options in a dropdown (if available). That way it can expand indefinitely but we still retain the essential utility of adding Posts and Pages as the primary UX.

We should also have an All tab to allow you to view and search across all items. In this case we'd need some kind of identifier next to each search result (similar to how the existing Link UI works) to designate the "type" (eg: Post, Pages, Tag...etc).

[talldan]

We should also have an All tab to allow you to view and search across all items. In this case we'd need some kind of identifier next to each search result (similar to how the existing Link UI works) to designate the "type" (eg: Post, Pages, Tag...etc).

I'm feeling a bit skeptical about how usable a tab per type will be. I wonder if it might be worth trying only a single tab that defaults to 'all', but can additionally be filtered by the type using a dropdown (like in the designs above). It might be nice if a user can retain selections across 'types', so a post, page, category could all be added in one go.

I'm not sure what the tab title would be be though 😄

[javierarce]

I'm not sure what the tab title would be be though 😄

I would call it "Content".

It might be nice if a user can retain selections across 'types', so a post, page, category could all be added in one go.

That is a good idea. If we do this, I think the 'Select all' button will be less useful than an option to remove the current selection. The add button could also indicate how many items have been selected.

I was wondering if we could have a 3 dots menu in place of the last tab (far right) which when clicked reveals more CPT options in a dropdown (if available). That way it can expand indefinitely but we still retain the essential utility of adding Posts and Pages as the primary UX.

The nice thing about that idea is that the basic content types (Pages, Posts) are immediately accessible. We could also add 'Categories' to the tab bar, but in that case we would need to increase the width of the whole component.

Another cleaner option could be to have just two tabs, the default one being 'All', and then allow users to filter using a dropdown.

My only concern with the "All" element is that it could be very chaotic and therefore not very helpful, especially for complex sites with lots of content. Also, from a purely technical perspective, wouldn't that query be very intensive?

Another idea. Same UI as the previous one, but the search button appears inside the tab bar and allows searching the content below. That option could also appear when looking at Blocks.

[karmatosed]

Looking at this, I much prefer the bulk adding from the sidebar and strongly prefer the latest mocks so great work @javierarce.

My only concern with the "All" element is that it could be very chaotic and therefore not very helpful, especially for complex sites with lots of content. Also, from a purely technical perspective, wouldn't that query be very intensive?

I think there’s probably an expectation for that power control here, though, from those using menus. It’s a feature that existed before, and I think whilst it can be problematic, it’s something I’d consider some might want still.

I prefer the latest mocks as they seem to avoid the search and dropdown interface pattern that I think was a little confusing. I prefer the closed search input. Where you show tags in the hidden menu area, would format and custom post types also go there?

One last point on the sidebar itself. Where a short amount is shown, could the action buttons of ‘remove’ and ‘add’ be brought up to be closer to the selections? I can see; otherwise, they could be pretty disconnected from experience.

I took it upon myself to remove the needs design as I think what we have is totally shippable as a MVP to get going on. Whilst that is a presumption, it feels like there's a lot here to get started with and perhaps some details but a solid foundation.

[talldan]

I think these mock-ups look really good. It's great to see the iteration happen. Thanks for being so receptive to feedback @javierarce.

My only concern with the "All" element is that it could be very chaotic and therefore not very helpful, especially for complex sites with lots of content. Also, from a purely technical perspective, wouldn't that query be very intensive?

My instinct here is that a lot of users will have a good amount of content and prefer using the search box, typing a few letters to get to the item they want. But then again I also expect users will mostly want to add pages. These are assumptions, it'd be a really interesting to have actual evidence 😄.

The dropdown filter could also remember its last value between sessions, it might be frustrating if it always resets to 'All'.

Searching all items by default could be a little bit technically intensive, but I think we should work backwards from the best user experience, and then see how we can solve any technical issues.

[getdave]

Love this iteration and team work.

My only concern is that to me at least the search bar is less prominent than the filter dropdown. In fact for a while I assumed the dropdown was the free text search bar. I wonder if we can reverse the visual emphasis somehow?

Also will the panel be triggered from the global inserter toggle button?

Assuming there aren't going to be a major changes of direction at this point, let's start iterating in code.

[javierarce]

Thanks all for your comments and great feedback!

Let me show you the latest iteration (also accessible here) and then I'll address some of your comments:

After thinking for a while about how to better integrate the "Select all" option, I think that the best placement for it could be inside the search view. Users will only be able to select many items after a search (which is probably more useful than adding every item from the "All" type). The downside is that, for example, adding the 10 most recent posts will require 10 clicks (but hopefully that's not so common).

@getdave: My only concern is that to me at least the search bar is less prominent than the filter dropdown. In fact for a while I assumed the dropdown was the free text search bar. I wonder if we can reverse the visual emphasis somehow?

I think we could add it back to the list. Tammie was worried that it could be confusing, but since we have fewer items on the tab bar now, maybe that won't be the case anymore (what do you think, @karmatosed?)

@karmatosed: One last point on the sidebar itself. Where a short amount is shown, could the action buttons of ‘remove’ and ‘add’ be brought up to be closer to the selections? I can see; otherwise, they could be pretty disconnected from experience.

I thought about this, but I think that having a list with a variable height would mean that the "Add to menu" and "Remove" buttons below would move up and down depending on the number items, and that could be very distracting.

@talldan: The dropdown filter could also remember its last value between sessions, it might be frustrating if it always resets to 'All'.

That's a good idea.

@talldan: Searching all items by default could be a little bit technically intensive, but I think we should work backwards from the best user experience, and then see how we can solve any technical issues.

+1

[getdave]

@javierarce Here's an example of how many tabs we could end up with by default if we were to enable Patterns and Reusable blocks in this editor in the future.

[karmatosed]

Thanks for iterating @javierarce. My biggest concern is that I’m unsure we have a pattern for ‘all’ being under the more dots in other places. Whilst it is used for showing options, this reads a little more like a filter. I know that’s not the easiest, though.

I don’t know an easier way of doing this, but I tend to go back to the rather clunky ‘select all’ being exposed. I am sure that’s not the only way, but I am not sure about placing it inside the search view as throughout WP, that tends to be surfaced more, and this screen rests on some legacy experiences.

In wp-admin this tends to be the 'all' select:

I share this to add the context of what people are coming from as a learnt pattern and how I think this might confuse.

[Thelmachido]

Closing this issue due to the Navigation Screen project is being moved to an inactive status on the feature projects page in coordination with the project leads.

If this work is picked back up, issues can be revisited and reopened as needed. Thanks for testing this early feature and giving feedback so the wider WordPress project could benefit from the lessons learned!