Utilise dataviews to improve Navigation Menu management in the Editor

[jameskoster]

In WordPress 6.6 managing pages, templates, and patterns in the site editor transitioned from ad hoc implementations to utilise the new Data Views component. This issue explores how the Navigation section in the site editor might work if it followed this path.

Menu list

• Navigation menu item takes the user to a list of existing menus.
• By default this would utilise Data Views List layout to include a preview.
• Clicking a menu selects it and updates the preview frame.
• Users can switch to Table layout for performing bulk actions.
• Page header includes 'Add menu' action.
• Ellipsis menu includes actions, for example; rename, delete, duplicate.
• Clicking the pencil icon drills down to an edit interface for the menu...

Editing a menu

• Header contains:
  • Back button,
  • Primary action: Add menu item,
  • Additional actions (same as the previous ellipsis menu; rename, delete, duplicate, etc.).
• In the content area each menu item is listed. Potentially using an ItemGroup.
• Menu items can be dragged/dropped to re-order.
• Ellipsis menu contains actions relating to menu items, for example: move up/down, add submenu, delete.
• Clicking the pencil icon drills down to an edit interface for the menu item...

Editing a menu item

• Largely reuses the existing menu item edit interface from the site editor.
• Menu item being edited is spotlighted in the preview.

Would this be an improvement on what is currently shipping? Are there alternative approaches to elevate the menu management experience in the site editor?

[dhanson-wp]

This approach is like you read my mind! Since managing menus in the site editor, I've missed the abstraction of the classic menu editing experience. It feels awkward jumping around so many places to edit menus and almost redundant to do a bulk of the editing in the right hand panel when the left hand panel could handle the experience in one location.

I also think removing the step to go into the editor canvas and edit blocks is a much better experience. When I want to edit menus, I want to edit just the architecture of the menus. This abstracted approach makes a lot more sense.

[jasmussen]

The breadcrumb appearance for drilldowns here is the only aspect of this mockup that's unclear to me. Can the concept work as-is, but with the existing drill-down flow instead?

[jameskoster]

Absolutely :)

[jasmussen]

Do we need to update the mockups, or can we move this to "Needs dev" with the above text-clarification? I think this one is ready!

[jameskoster]

I updated the mockups.

The missing piece for me (before marking this as ready for dev) is how we render menu items in the 'Edit menu' panel. Does that use and updated ItemGroup, or do we need to create a new component (perhaps based on List View in the site editor)?

[jasmussen]

It does seem dependant on an updated ItemGroup, yes, though absent better status indicators, I'll shuffle the labels still! Thank you for updating.

[getdave]

Related #50580

[getdave]

Menu item being edited is spotlighted in the preview.

This bit is probably where this will come unstuck in development.

What specifically are we previewing in the editor preview area? As more than one Navigation block can use a given Navigation Menu, there's no canonical way to display the menu.

This is the same issue we ran into with the Focused Navigation Editor and that's why it's been removed from the Editor.

Also several folks were very much against the existing Navigation Menu editor because they felt it caused a slot of confusion. Specifically I recall @draganescu felt strongly that it wasnt helpful.

Therefore I would suggest that we split this work into two stages:

• implement the dataviews changes for Menus but leave the "preview" area showing the entire site (as per 6.7)
• consider if/how we can utilise the preview area

I believe if we attempt both together then we will struggle whereas I felt the dataviews changes have merit in their own right.

[getdave]

I'd also advocate that we update the name of this Issue to be "Utilise dataviews to improve Navigation Menu management in the Editor"

[jameskoster]

The missing piece for me (before marking this as ready for dev) is how we render menu items in the 'Edit menu' panel.

Revisiting this question; maybe we just re-use the treegrid (list view) component, like we do in the Inspector.

cc @fcoveram as I think you've been looking at this a bit recently.

[fcoveram]

Thanks for the ping @jameskoster. I'm working on an idea based on the image you attached.

[getdave]

Thanks both 👍

You may already be aware, but if we are going down this route let's not forget that we already have an interface on the Navigation block itself which mirrors this pretty closely.

We should be careful to ensure parity between these experiences so as to avoid users having to learn another new interface.

[dhanson-wp]

Revisiting this question; maybe we just re-use the treegrid (list view) component, like we do in the Inspector.

The location of this editing experience in the left panel feels much more natural. Jumping over to the right inspector panel feels cumbersome. Also, the treegrid really helps visualize the hierarchy.

Something I keep observing is that the site editor uses the term Navigation while every user creating a new navigation menu will title it Menu or Main Menu or Primary Menu etc.

Classic WordPress used the term Menus, and I wonder if it should switch back to that. Menus feels simpler and more intuitive.

[getdave]

Appreciate the feedback.

The location of this editing experience in the left panel feels much more natural.

That's good to hear 👍 The editable tree in the right hand side was added to support the main in-editor editing experience before the left hand sidebar existed. In time it may become obsolete but we should also consider block editors used outside of WordPress context which might want to utilise a Navigation block but which don't benefit from the WordPress Editor "chrome" such as the left hand sidebar.

Something I keep observing is that the site editor uses the term Navigation

This was a discussion point early in the development of the Navigation block. We decided on Navigation for the block and Navigation Menus for the data (the items). Partly this is to disambiguate from other types "menu" such as those used in restaruants.

At this point I can't see us changing this.

[fcoveram]

I tried two ideas that involved moving menu items up, down, inside, and outside; but none landed on solid proposals. Instead, they introduce more complex patterns that expand the issue's scope.

That said, I think the current Navigation menu editing flow in the inspector has more room for improvement as the UI relies on existing components, and the current interaction feels detached from similar UX flows.

I suggest lowering the priority of this issue and shifting the design efforts to #65699. What do you think?

[getdave]

I tried two ideas that involved moving menu items up, down, inside, and outside; but none landed on solid proposals.

Would it be possible for you to share those explorations here for others to contribute?

Instead, they introduce more complex patterns that expand the issue's scope.

In what way? What were the specific issues you encountered?

[jasmussen]

Instead, they introduce more complex patterns that expand the issue's scope.

I can speak a bit to this, I happen to agree with Francisco.

Consider that we have this:

This interface is both management and menu editing. The proposal here is to replace that screen with something that's DataViews powered, however to the best of my understanding because they are designed to be visual representations of data in a silo. I.e. it would be a perfect tool to show you a list of all the menus you have saved on your site, with a link to edit them. Because:

• DataViews is unlikely to support drag and drop, possibly ever, because for example reordering pages would mean updating the page order for each page, which would break a server that has thousands of pages: it would have to update the order of each. I believe this is why custom menus exist in the first place.
• Tree-view in DataViews is, for the moment, very limited insofar as it shows indentation for sub-pages, even a label, "Child of [page]". This is also because when you search for an item, you can see that item without its parent.
• We know with absolutely certainty that the block editor experience of building and editing navigation menus needs to be improved. It's in a poor place.
• Since both tree-view and drag and drop would need to be a custom implementation that isn't data-views powered, what we'd build would essentially be a re-implementation of what's already shipping. It would look better, but it would be unlikely to substantially improve menu editing to what's actually shipping, so the value of investing in this is unclear.

In that vein, I agree that we should update the Navigation section of the site editor to be DataViews powered, but in a pure management way. It would use the existing implementation to simply surface every saved Navigation CPT, just like the Pages section surfaces navigation menus. You'd be able to delete, rename, QuickEdit its properties and attributes. And you'd be able to click a link to edit in the full editor, but not edit it in site view, because data-views doesn't support that.

Given we also want to improve the editing experience in the full editor, the combination could work well. But the latter would be the most impactful thing to work on, arguably.

None of this necessarily prevent us from coming back to this at a later time, and implementing a separate tree-view with drag and drop component that would allow the editing in site view, as already exists. But because the existing implementation hasn't set the world on fire, it's unlikely to be as high impact as improving the full editor experience first. What do you think?

[fcoveram]

In what way? What were the specific issues you encountered?

Joen's comment put what I encountered in a better way. Specifically bullets 1 and 4 where the interactions in ListView need to exist in DataView. That blend creates a blurry line between both views as the "where I need to do what I want" is not clear given that both views do the same.

The experience in Editor feels less polished because the block order of a menu exist in both ListView and Inspector, where the latter is in a poor place.

Would it be possible for you to share those explorations here for others to contribute?

Despite the above, here below are the mockups I kept on hold.

With drill down

Without drill down

[getdave]

That's great context which makes it easier to understand how we're proposing using Dataviews for menus.

In general I agree that the priorities should be:

• improving usability of in-canvas editing for the block - principally streamlining the most common flows and removing common pain points as opposed to sweeping rewrites of the experience.
• iterating on the UX of the List View in the inspector controls for the block.
• updating the Site View Navigation area to be purely about data editing - this means removing the tree grid thereby drawing a clean line between editing menus and "managing" them which is necessary due to the sync'd nature of menus. It will also help because at the moment certain properties of Navigation Menus are impossible to access via the UI which can cause certain advanced flows to be difficult.

If we agree, shall I update this Issue to reflect the object set above?

[jameskoster]

I feel the need to clarify a detail from the original design that may have been mis-understood. The only part consuming the DataViews component is the first mockup; the one listing the menus. The views listing and editing menu items would be separate 'pages' accessed from the data view.

In any case, @getdave please feel free to update the issue to concentrate purely on the first part (listing menus using DataViews to provide access to better management tools). This part seems much more achievable in the short term and would have a big positive impact on this section of the admin.

We should also discuss the DataViews config; which layouts are available, appearance options, fields, filters, sorting, etc. Maybe @fcoveram has some ideas?

[fcoveram]

I see value in the mockup listing the menus. The edit action can perfectly take users to the Editor, unless I'm missing something in between that interrupts this flow.

I shared here (#56245) an idea that seems consistent with DataViews in Navigation.

Regarding DataViews config, I can only think of the following:

• View properties
  • Author
  • Date
• Actions
  • Edit
  • View (as Template part)
  • Rename
  • Duplicate
  • Move to trash

I was considering a property to see in which patterns is being used, but I'm unaware if that is an on-going idea.

[jameskoster]

I was considering a property to see in which patterns is being used

This one would be useful for other synced entities like template parts and patterns, even templates. But it's a big technical hurdle I think. To connect the dot there's an issue here: #60205