Don't navigate to navigation post type #59340
Conversation
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
draganescu
added
[Type] Enhancement
|
Size Change: +4 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
|
@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. |
…o a navigation in the site editor
draganescu
force-pushed
the
remove/navigation-standalone-editor-site-editor
branch
from
4f5bb92 to
00a3f72
Compare
|
I agree with @fabiankaegy. As I mentioned in #59372
I think that, while the intent of this PR is good, it actually cures the symptom rather than the disease. To me:
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 |
Those isolated elements of a site are 1:1 to the element; not a representation of some sort.
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 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 effortOne 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 This would make the initial click through to the 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 effortAnother option might be to simply remove the ability to access the "Navigation Editor" view from the |
|
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.
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.
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:
(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:
From analysing multiple UX sessions and videos, I believe users expect to see a top level menu item in the left hand sidebar labelled 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.
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:
The idea should be that this is an advanced view which can only be entered if you know about it. |
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. |
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 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.
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? |
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. |
Agreed. I'd prefer to see the ability to edit Navigations from the sidebar area anyway.
Yes it was an experimental Plugin which I need to revivie. |
|
I agree with @getdave that:
Who can help me:
|
|
What about "Edit" here?
|
|
Closed in favor of #61275 |
What?
In the site editor when using the sidebar to go to Navigation>[Single navigation] the frame would show the contents of the
wp_navigationpost type. This PR keeps the frame showing the homepage.Why?
The original intent was to allow a sort of zoomed in editing for the navigation. This has not amounted to much and now it's a confusing screen which does more harm than good.
How?
Update the route for single navigation in the site editor to not include a post type so that the editor in the frame does not try to edit it. Updates the path of navigations in the list of navigations in the site editor sidebar Navigation section.
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast
frame-shows-home.mp4