Navigation List View: Introduce navigation editable tree view in the inspector controls

[SaxonF]

Building a custom navigation menu is fiddly. We have in various versions explored surfacing a List View interface for managing and building the contents of your navigation. Let's surface the list view in the inspector.

When no menus exist

In this state, all pages (Page List) is shown:

A single menu exists

In this state, this one menu is loaded by default:

Multiple menus exist

In this state, the context defines which menu is loaded by default. If the navigation block is inside the Header template part, "Header navigation" is loaded by default, even if "Navigation" and "Navigation 2" also exist.

To facilitate discoverability of this inspector interface, we should try to enable the click overlay on the navigation block, just like it is for template parts in the site editor. That way the first click on your navigation will always select the full block, and surface the inspector interface.

See also #40204 for an adjacent effort to divide the inspector into tabs, which will be useful for 30+ items in a navigation block.

---

This issue was updated Sep. 28.

See initial proposal

What problem does this address?

Many users, both new and existing, have found the navigation block difficult to use. For new WordPress users, there are certain UI quirks that get in the way and jumping from parent to child blocks is challenging. For existing WordPress users who are new to FSE, there is a unique mix of directly editing the nav block (which is a new paradigm) and editing menus globally using the navigation sidebar.

What is your proposed solution?

inspector.mp4

Id like to propose that we simplify by leaning more heavily into editing menus locally/on canvas via the navigation block and emphasise template parts / re-usable blocks / synced patterns as the primary way of editing site elements globally.

A quick way of moving in this direction is simply moving the menu management experience into the navigation block settings sidebar, and removing the existing global navigation sidebar. We'd also enable adding navigation menu items from this management experience which removes the need to jump in and out of child blocks. Adding menu items makes use of the existing add menu item dialog. Menu editing can still be done directly on canvas, in this case I think the redundancy is fine.

The video shown here makes use of some of the ideas found here, namely surfacing child layers within patterns (e.g. header) which may be a more accessible way of selecting the navigation block for low tech users.

On top of the above change, a few other optimisations to make:

• The add menu item dialog removes the ability to transform from the menu item selection stage and instead adds a back button
• As seen in the screenshot above, the navigation toolbar can block menu selection when in an empty state
• It also partially covers up the new block button as shown below

• This may just be a me issue but I've found the current state very buggy. Selecting the navigation block sometimes puts the editor into an unusable state, preventing me from selecting any other layer. Video attached.

broken-nav.mp4

I realise this contradicts from this issue somewhat but if we introduce the idea of browsing/searching content in the sidebar then a dedicated UI for editing menu's becomes less important. We could still provide a way for managing menus outside the editor if there is value beyond just not having to enter the editor.

[mtias]

Modified the title so that there's no confusion with the site structure work — this one should be about adding a way to edit the navigation block as a list in the block inspector.

[javierarce]

Sorry, I deleted my previous comment which was:

What I would probably add in that dialog is the possibility to filter by content type and a way to insert several links at once using checkboxes, which would give us the bulk inserting feature we missed from wp-admin (#31667)

PS: I'm closing #42626 because I think it shares the same goals as this issue.

What I missed was the option to create custom links, which the filter interface of the search bar I designed would make confusing.

I think we can probably keep using the current Link Control UI (minus the transform section), so users can also add other types of content as they do now.

[draganescu]

The problem with clicking the list view item to edit is that it immediately replaces the inspector with the inspector of the newly selected block hiding the list view in the process. A slow drag and drop will also get this. Hence the idea to use an explicit action for edit in this case.

[talldan]

The problem with clicking the list view item to edit is that it immediately replaces the inspector with the inspector of the newly selected block hiding the list view in the process.

My idea is to replace the primary action of the item. Show the inspector controls for the block when clicking the item. There would be no way to select a block.

A slow drag and drop will also get this.

😕 What's a slow drag and drop? This sounds like a bug that should be fixed.

[draganescu]

A slow drag and drop is when the drag comes a bit too late after the mouse down, like... a batter name would be a failed drag and drop. And if you want to drag and fail and that causes the context to change is too jarring.

BUT I like the idea to replace the action from canvas block selection to navigation. It could work and definitely should be tested. I think if this works it is better than cluttering that tiny space with yet another icon. 👏🏻

[draganescu]

@SaxonF @mtias @javierarce are we set on that "edit menu" button in the navigation block's toolbar? I ask because:

• that action is replicating More menu > Show more settings
• the action does not do what it says (no editing is happening)
• did we decide the menu is read only in the canvas? If no, why would we have an edit menu button?
• it's a poor fit for the block toolbar in this shape, because it resembles "edit template part" which has a completely different effect.

As #45772 started to implement this I'd like to be sure this is really an intention and wasn't merely an exploration.

[draganescu]

@jasmussen @SaxonF given the progress in #45785 do we want the manage menus thing to move out of the advanced area and into the menu selector? I ask because:

• I believe the goal was to de-prioritize that action, as it really is an advanced situation
• The manage menus action was in the menu selector when the selector was in the block toolbar and we intentionally moved it out when repositioning the navigation selector in the block's inspector.

[jasmussen]

I left some feedback on the "manage menus" in #45785 (comment), but also noted that it's not a strong opinion. Exactly for the reason you mention, the feature should not have prominence, they key bit here not being a blue link in the main panel.

[priethor]

@draganescu @getdave @scruffian, is there any remaining follow-up left before considering a v1 of this feature ready and closing this issue?

[getdave]

Yes I think the v1 is ready. It's just landed in the Plugin as non-experimental as well.

I think a final review by @WordPress/gutenberg-design would be useful. But otherwise we've paused work on any new features for the v1 of this effort and are now focused on bugs.

[paaljoachim]

Is there a specific PR (multiple PRs?) that I should take for a spin?

[scruffian]

@paaljoachim you should be able to see it in trunk now.