Provide more choice when manually creating a new Navigation Menu

[getdave]

When users create a new Navigation Menu via the block (see Inspector Controls on the List View tab) they are immediately given a new Navigation Menu.

This menu is empty - which can be confusing or undesirable (although this is highly dependent on use case and the user).

I propose that in this specific scenario we provide the user with a choice about what "new" means. For example, we could show a Popover/Modal with options to include:

1. Blank menu
2. List of my Pages
3. Existing Menu.

This would provide the user with more choice and help to avoid the scenario where menus are accidentally created (something that is regularly reported as an Issue).

Please note that we would not have this behaviour on block insertion. This should remain a frictionless experience.

[getdave]

If we wish to pursue this we are lacking any Design direction. Adding relevant labels.

[getdave]

@WordPress/gutenberg-design Given that creating new menus is probably a common task for anything other than the most basic of sites, do you agree that we should pursue this proposal?

[paaljoachim]

It is a very good idea Dave @getdave
As starting out blank can often be a scary process. As one might not easily understand how to for instance add all the pages to the new navigation.

Perhaps when setting up the page structure that a menu navigation should automatically be created as a kind of default navigation. This could also be helpful for various menu plugins that need a default Nav to start out with.

[fcoveram]

I was exploring a new approach to the Menu tab for managing menus with basic features.

The core change is replacing the page arrangement with a menu list that shows published pages by default, just like the purpose of the Page List block. The menu creation happens in Inspector whereas the page arrangement in List View. The page-movement feature is expected to happen and works better in the left sidebar. I think the main UX pain points is trying to recreate this functionality in Inspector.

Here are two key flows in mockups.

Inserting the Navigation block

The default state has a toggle on for showing all published pages. This intends to avoid having empty states where creating a menu is the predominant action.

Creating a new menu

The menu creation happens in a custom section where adding a new one sets the name automatically and renaming it in a modal, similar to setting shadows in Styles.

[jasmussen]

I can see that working, especially the emphasis on synced menus, having to use the very simple toggle to "unsync" and make it custom. That's great progressive disclosure. Curious about more thoughts, CC: @WordPress/gutenberg-design

One nitpick, the ItemGroup leveraged can be a great way to show flyouts with properties for each custom menu you create, or even open a modal if need be. But usually those items are exactly 40px tall. I also wonder if we need the ellipsis for each, presumably it's there for rename, duplicate, delete, though I wonder if those actions should sit inside the flyout or modal either?

[fcoveram]

I see value in adding friction to enable an existing menu, preview it, and display editing actions. But I'm not sure which components are the best for the latter according to heuristics. Here is a quick mockup of what @jasmussen's idea might look like.

[jasmussen]

Some good instincts there. As a followup to the wonderful "Show published pages" toggle, is there a way we can improve the building aspect? There seems to be an implication from that toggle, that you can sort your menu items in active vs inactive, perhaps it'd be nice to even be able to drag and drop between those major categories. If that were the case though, should that be more prominent than choosing the active menu? Is there a design which simply shows the menu you have active, but relegates the action of choosing a different menu, or creating a different menu, in a dropdown? Without going in circles, because we've had such a dropdown in the past, the fact that you introduced the toggle which affords progressive disclosure well manages the prominence, which was the main challenge with the dropdown in the past.

[fcoveram]

Thanks for the feedback.

I was exploring an idea for the active/inactive point that surfaces the published pages and their order in a modal to add them without leaving the Editor. I want to avoid the menu item ordering interaction in the Inspector, given that it is expected and successfully solved in the ListView.

By keeping the menus visible in the block Inspector, the creation and edition flows happen in context in addition to the menu item order. Forcing users to go to the admin to switch menus seems unnecessary when other blocks also have content settings in Inspector tabs.

Here below you can see three key flows.

Inserting the Navigation blocks

Adding published pages

Creating a menu

---

What do you think?

[draganescu]

Forcing users to go to the admin to switch menus seems unnecessary when other blocks also have content settings in Inspector tabs.

👋 What is this about? We should not have this anywhere about the block experience afaik.

[draganescu]

There are many things I don't quite follow, possibly b/c I've been.a bit out of the loop re navigation lately.

The page-movement feature is expected to happen and works better in the left sidebar. I think the main UX pain points is trying to recreate this functionality in Inspector.

Where did this come from? The issue started by @getdave is about the 1st steps of menu creation avoiding.a blank state. I don't even know where was this a problem or if it's an opinion. But then later in the proces we move to do an entire revamp of the navigation building UX.

We aded the inspector view specifically to keep the context in the block. We had the list view working concurently with the inspector list view. I think I remember precisely rising the issue that "we can already do this in the list view" and getting feedback that the list view is more for power users and block context is more cognitively accessible.

So if we want to update this whole thing, we need ot provide something to support the need to change and something to allow us to decide if the followups are actually better.

[getdave]

I appreciate the energy here @fcoveram 👍

I was exploring a new approach to the Menu tab for managing menus with basic features.

@draganescu I think perhaps this is the missing context. The Issue seems to have pivoted slightly to exploring Navigation more widely. I think we should break that out into lower level goals.

I support the following:

• improving the experience of the "auto menu" (just listing pages).
• making it easier to know which menu is selected (and whether it's custom or auto).
• making it easier to add / create pages in a menu

These should be covered in the Tracking Issue which I have recently been updating.

I am highly nervous about undertaking any big revamps to the Navigation block interface. This could absorb a lot of resource and energy and I feel there are tasks which would potentially have a greater impact whilst making use of what we have today.

I'm not saying we shouldn't strive to improve, but I wanted to sound a note of caution and ask whether it's possible to translate some of the thinking here into the Issues identified in #38275 in order that we can delivery impact in a forthcoming release.

I'll look forward to continuing to work on this.

[fcoveram]

Thanks for all your thoughts

Where did this come from? The issue started by @getdave is about the 1st steps of menu creation avoiding.a blank state. I don't even know where was this a problem or if it's an opinion.

It’s an opinion that comes as a product designer and WordPress user that, from time to time, interacts with other similar services. I don’t handle user data to inform possible frictions with the current experience. However, I do see an opportunity to improve the current way of creating and editing navigation menus.

If the above is insufficient to go down that route, I’m fine to push back my ideas and address the specific point reported at the beginning of this ticket.

…feedback that the list view is more for power users and block context is more cognitively accessible.

Great input. Thanks for sharing it.

The Issue seems to have pivoted slightly to exploring Navigation more widely. I think we should break that out into lower level goals.

Yes. Absolutely

When I started tackling this issue, I connected points discussed in other issues, and as a consequence, my proposal began to involve different ideas simultaneously.

Regardless of the above, here below you can see a narrow version that only spans the menu creation part for use cases with no published pages, no navigation menu, and multiple menus. I finished this prototype a few hours ago so it misses the feedback about keeping the block-context interaction.

I acknowledge the ambitious scope proposed in the previous message, so I am more than open to taking the most relevant parts of this idea and continuing from there.

Menu.creation.-.flow.1.i2.3.mp4

The above involves the auto menu and active menu points made here. The addition/creation of pages in a menu needs to be added. And with the input shared by @draganescu, the block flow in the Inspector could remain as is, and replace the MenuGroup listing all menus with a Select control.

A key question here is what the UI should suggest/insert when toggling off the sync. If users don’t have a menu, showing all published pages without menu assignation feels like missing context. On the other hand, if users have several menus, which one becomes active? For both use cases, the idea prototype is a temporary menu that requires users to click on save to formally save the menu.

An alternative could be creating a menu immediately when toggling off the sync, and show the active icon and unsaved “changes” status for users without menus. Still, depending on how users experienced the accidental menu creation, this may introduce another problem. I'd like to know more about the user data gathered there.

This is my first design contribution to Gutenberg, so sorry for missing context and derail the issue’s core goal. I appreciate your welcoming boost @getdave

[draganescu]

Hey @fcoveram - I think your designs are quite cool (👏🏻 ) and definitely they offer a more lean UX. But I also think there is a lot to unpack in what they propose. Ideally we should make a new issue and discuss all the new stuff there as it seems there is a lot to track:

• removing the inspector tree (it seemed to perform well and we need to know why we'd remove it)
• picking pages from a modal (this is a different paradigm from the modal-less editing of blcoks where we want things to be inline)
• raising up in the UI the menu selector (it doesn't seem to be a primary concern for most users)
• the toggle to sync would mean we don't use the pages block anymore?

I think that the ensuing discussion will push the cool work to be even better. It will also allow tracking the likely many PRs to implement it.

As for the current issue, I believe we should scope our explarations to using the current UX as the basis for seeing if we can make new menu creation more intuitive. If we can't that is also fine.

[jasmussen]

the toggle to sync would mean we don't use the pages block anymore?

This is a part of the mockup work here that I personally see as very potent, and something that could be explored even outside of every other change. And I don't see it replacing/removing the Page List block at all, it's abstracting it away. It's a way to say: when this toggle is on, your menu stays in sync. It's a way to divide the navigation contents into two states: synced or unsynced, and provide UI progressively unlocking based on that. Behind the scenes, it does so using the page list block, but you don't have to know that.

Toggling this off, is the only part where things get a bit curious as to: what do we do.

1. Do we immediately create a new menu that copies over all your pages, so it's now a menu that matches, but unsynced? (Same as pressing "Edit" on a Page List).
2. Do we do the same, but not save the menu, save that menu only when you press th "Save" button in multi entity saving?

2 seems ideal, but likely requires both a mindset change as to how navigation menus are saved, and some code. Curious your thoughts.

[jasmussen]

Such a toggle might also help here:

I really just want to replace this menu with a Page List version now. So I'd flip the toggle, save, and be done.

[getdave]

Thanks for all the thinking here. It's very refreshing.

I completely support a holistic view of the experience. The current flow of moving from "auto-menu" (i.e. Page List) to "synced" Menu is very poor and needs to be improved.

I see quite a number of good ideas here and some other things I'm concerned about. I'm going to take a bit of time to consider them carefully and work out how we can best proceed from here.

Thanks again.