The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: draganescu <andraganescu@git.wordpress.org>
Co-authored-by: getdave <get_dave@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
Co-authored-by: afercia <afercia@git.wordpress.org>
Co-authored-by: richtabor <richtabor@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +4 B (0%)

Total Size: 1.71 MB

_{compressed-size-action}

@draganescu I in theory like this because the sidebar editing is much simpler than the experience when the single navigation is loaded in the editor. However this currently doesn't support a bunch of interactions like adding new menu items, converting something to a submenu etc.

Because of that I don't think we can get rid of the current experience just yet. Not until there is feature parity in the sidebar experience.

@fabiankaegy i do think the sidebar navigation menu handling should be improved but I am convinced the current situation does more harm than good.

The editor is working with the menu data directly, users can't style and it's extremely unclear what is actually being done. Plus the UI is so unpolished that the whole editor seems broken.

I don't think we should wait for parity - on the contrary removing this stop gap will accelerate the need for figuring out the navigation menu handling in the site editor sidebar.

I agree with @fabiankaegy. As I mentioned in #59372

I'm not sure the navigation panel should be a place where items can be edited 'in place' in the panel itself in the first place. Additionally, there are other actions that can only be performed in edit mode. For example, renaming a link, adding new links and possibly other actions.

I think that, while the intent of this PR is good, it actually cures the symptom rather than the disease. To me:

• The navigation panel should never, ever, evolve to an editing UI. That's not the plate to edit. While some minor actions like move up/down, delete, rename, can be added to the navigation panel, a full editing experience can only be provided within the editor canvas.
• The editor already allows to edit some objects 'in isolation', for example patterns. It makes perfectly sense to reenforce this concpet and allow other objects to be edited in isolation. Consistency is key. As a useer, when I click a pattern I expect to get the edit view. When I click a menu, I expect to get the edit view.
• I tested this PR and, to me, the experiences just feels not right. When I navigate to a menu, I still see a page in the editor canvas. It feels like the editor is broken, in a way. A dead end where I can only move/remove menu items. At this point, what's the entire purpose of navigating to a menu?

Overall, I think the editor should go in the opposite direction. Keep navigation to the menu edit 'isolated' view. Make it nices and easier to use.

I lean towards removing this route as well.

I've not been a fan of the single-navigation view as it was introduced. It's not any more helpful than the navigation as it appears on the site, but more confusing because it does not look like the navigation on your site—even though it's visually presented as such.

I think if we eventually do something like the WP Admin menu view (more of an actual UI around an isolated menu editing experience), then it'd be a more viable solution. But even then, I'm not certain it's the right direction.

+1

The editor already allows to edit some objects 'in isolation', for example patterns. It makes perfectly sense to reenforce this concpet and allow other objects to be edited in isolation. Consistency is key. As a useer, when I click a pattern I expect to get the edit view. When I click a menu, I expect to get the edit view.

Those isolated elements of a site are 1:1 to the element; not a representation of some sort.

At this point, what's the entire purpose of navigating to a menu?

I question its purpose as well, but the current experience does not warrant enough of a purpose. It could be more like the style book, where when you select a navigation, it opens up in the editor with the Inspector ready to go, but even then that's tricky, as the menu may not be on the current page.

I am currently working on an interesting use case that I haven't found a way to accomplish without the navigation editor screen here.

This site has multiple different header menus that get curated manually by editors.

On the frontend the site header navigation then pulls in the appropriate navigation for the current user based on a few conditions.

Essentially this is a personalization feature for the navigation.

But because the different menus are not actually used on any template / template part, there is no way to edit them without this single view.

In this case we even exposed the wp-admin/edit.php?post_type=wp_navigation page as a menu item under the Appearance menu to allow easier creation / direct links to the various navigations.

I'm saying all this not because I like the single navigation editor as it works today. In fact I really dislike it and find it very hard to use.

Instead I'm saying that currently you are forced to use it because there are no real alternatives.

What I would love to see here is something similar to what WooCommerce did with their Product editor experience. An abstracted representation of the menu where you can easily manage the structure without really having to think of the menu items as blocks.

Thank you for the use case @fabiankaegy I think that does raise a need to not remove this for now, maybe move it?

I'm not arguing that what we have today is a great experience - far from it. However, I am sounding a note of caution that we should consider not removing things without ensuring the use cases it served are covered elsewhere in the experience.

In this case @fabiankaegy makes the critical point about the ability to manage Navigations which are not currently in use in any template.

Whilst this is no doubt an advanced use case it is one that is valid and thus I think completely dropping the ability to access the editor would be a mistake.

Stretch goal effort

One way I could see this happening is if we lean into the new Data views "List" layout for Navigation. We're already doing this for Pages and other data types and I think Navigation could fit well here.

This would make the initial click through to the Navigation section more about managing your menus (rename/delete...etc).

The next step could be to introduce the editable list view (which we have in the Nav block's sidebar) into the "Content area" frame as a further click through. The functionality is all there and users have repeatedly requested the ability to manage menu items from this frame.

Navigation block editable list view

Overview of Data Views "frames"

Once this is in place we could remove the "Navigation Editor" as it is today.

Alternative simpler effort

Another option might be to simply remove the ability to access the "Navigation Editor" view from the Navigation section. We could still retain the ability to access this view in some other way, but this way we would deprioritise it the UI thus avoiding confusion.

I continue to wonder whether the management of multiple synced Navigation menus is over-emphasised in the site editor. Typically sites have one or two menus, and most of the time they live inside template parts which are already synced anyway.

For users, what should simply be a matter of editing the site header (including the menu) is over-complicated by additional touchpoints and interactions that add a lot of weight to the user experience.

maybe move it?

One way I could see this happening is if we lean into the new Data Views "List" layout for navigation

We have a place to manage synced entities – the Patterns page. The overlap between synced patterns and template parts has resulted in new efforts to align these concepts.

As a provocation, what if we did the same with synced navigation menus? Could there be a world where Navigation block contents are unsynced by default, and when you need to sync you just create a (synced) pattern? Advanced use cases as discussed are still catered to, but using familiar concepts and only as required rather than as the default. I think there could be potential for this to allow for more advanced expression, and at the same time simplify the experience for those majority use cases.

Thanks for thinking about this in the larger scope of WordPress.

It's really important we try and align concepts. I am however concerned that we don't add more confusion by obfuscating concepts such as "Navigation" and "Menu" which are universally understood.

For users, what should simply be a matter of editing the site header (including the menu) is over-complicated by additional touchpoints and interactions that add a lot of weight to the user experience.

Watching recent videos and listening to user feedback I would agree that what we have now is too complex.

That said, I'm curious to understand more about what you see as the "additional touchpoints". I assume one of those is the the Navigation focused editor that this PR seeks to remove?

If you want to edit your header Navigation you either:

• click on the Navigation block in the header within the editor canvas and edit
• click on the Navigation section in the sidebar, select the menu in question (assuming multiple menus present) and edit in the Navigation focused editor.

(Aside: if there is a single menu then we don't go to the isolated editor. It only happens if there are multiple menus - a more advanced use case)

Perhaps you mean that there are multiple ways to perform edits to your menu? These are:

• in canvas - required as per the block paradigm.
• editable list view (within inspector controls) - specific required to improve the UX around editing complex nested menus and, given the inherent complexity of the in-canvas block editing experience, is also a much better experience for users of assistive tech.
• focused navigation editor - we all agree that in its current form this leaves much to be desired.

We have a place to manage synced entities – the Patterns page. The overlap between synced patterns and template parts has resulted in new efforts to align these concepts.

From analysing multiple UX sessions and videos, I believe users expect to see a top level menu item in the left hand sidebar labelled Navigation. It's universally understood in the web paradigm and one of the key elements of any serious website.

As a result there is an argument that we should be careful to retain this and avoid any temptation to obfuscate menu management behind other less concrete concepts such as patterns or templates.

As a provocation, what if we did the same with synced navigation menus? Could there be a world where Navigation block contents are unsynced by default, and when you need to sync you just create a (synced) pattern?

I appreciate the provocation here to think outside the box 👍 . However, it seems to me that by making Navigation unsynced by default we could be exposing users to unwanted complexity. The need to understand synced vs unsynced is just about fine for more complex items such as Patterns but not for something as basic as a menu which should "just work".

Having now worked within this area for several release cycles I am more and more convinced that in order to improve Navigation Menu management in WordPress we need to visualise some of the many possible UX directions we could take. These visualisation should obviously be taken "in the round" of the wider concepts under development such as data views and synced pattern overrides.

From here we could start to bring together a vision of where Navigation needs to be to be truly usable and intuitive in WordPress which would involve interactive prototypes backed up by an analysis of technical feasibility much the same as was done for the Link Editing UI.

I (and I'm sure other contributors) would be happy to work alongside a designer to do this.

For the purposes of this PR I think we should:

• retain some means to access the focused Navigation editor
• make it harder to accidentally end up in this screen from the default Editor experience when navigating to Navigation -> My Menu

The idea should be that this is an advanced view which can only be entered if you know about it.

That said, I'm curious to understand more about what you see as the "additional touchpoints"

I'm basically referring to all the complexity that gets added by having to entertain menus as a post type all the time. Naming, deleting, switching, creating... all the different edit interfaces (like you mentioned), the little notices that appear when you edit a default menu (Pages List block), and so on. I appreciate we've attempted to give adequate prominence to these things but it still feels a bit overwhelming when compared to managing patterns which feels fairly streamlined by comparison. The biggest differentiator there is that syncing (a fairly advanced concept) is a user choice rather than a platform choice.

I know this is a very surface-level take, and agree it would be good to visualise a path forward.

One way I could see this happening is if we #59659 (comment). We're already doing this for Pages and other data types and I think Navigation could fit well here.

I'm not so concerned about getting to the menu, but rather the experience of editing it in isolation. It seems we're trying to emulate the functionality of this view, without building the corresponding editing experience as seen on the right:

I'm not so concerned about getting to the menu,

...I think it's causing confusion to most users and only a small subset are likely making use of it. The rationale is therefore to deprioritise the ability to reach what is currently a confusing screen for most users.

...but rather the experience of editing it in isolation. It seems we're trying to emulate the functionality of this view, without building the corresponding editing experience as seen on the right:

As you may/may not be aware Gutenberg contributors previously explored creating such an interface as part of the "Navigation Editor" project. It was ultimately mothballed and then removed from the codebase as something we didn't want to pursue. Instead we chose to double down on improving the block and introduce alternative menu editing interfaces such as the editable List View.

Are you advocating pivoting the current navigation focus mode into an experience more akin to the Classic Menus screen?

Are you advocating pivoting the current navigation focus mode into an experience more akin to the Classic Menus screen?

Not necessarily, but we're sitting in the middle now with this view—where it does neither well enough. I do recall you experimented with a modal editor for navigation items as well, it could be similar to that perhaps? I don't think we should invest heavily in this though.

I don't think we should invest heavily in this though.

Agreed. I'd prefer to see the ability to edit Navigations from the sidebar area anyway.

I do recall you experimented with a modal editor for navigation items as well,

Yes it was an experimental Plugin which I need to revivie.

I agree with @getdave that:

For the purposes of this PR I think we should:

• retain some means to access the focused Navigation editor
• make it harder to accidentally end up in this screen from the default Editor experience when navigating to Navigation -> My Menu
  The idea should be that this is an advanced view which can only be entered if you know about it.

Who can help me:

• move the access to this focused editor somewhere else :)

What about "Edit" here?

Closed in favor of #61275