search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.5k stars 4.2k forks source link

Navigation on Browse Mode #50396

Closed mtias closed 1 year ago

mtias commented 1 year ago

Trying to capture here the approach for the "Navigation" section of the "design" subgroup, which was pulled out from 6.2 late in the cycle due to user experience shortcomings.

The overall goal of this panel is to allow users and site maintainers to be able to access, navigate, and modify their navigations without having to find them in a specific template in the site editor.

The challenges are — as per usual with navigations — that the spectrum of complexity goes from simple sites where a navigation is a 1:1 map to the user's pages all the way to large sites with multiple navigations or mega-navigations where data and presentation are more intertwined.

So here's an outline of the basic use cases to address:

Meta actions

Should be possible to delete, duplicate, add a navigation from the ellipsis button next to the drill down state, just like templates, pages, and parts.

If only one navigation and the navigation is simple:

Only one menu, and the menu is pages only

Only one menu, and there are some non-standard blocks in it

Only one menu, and the menu is mostly pages but has one or two non page items

If more than one navigation:

Multiple menus

If navigation is complex, do not allow direct edit but instead open focused template part mode.

Multiple menus, and the menu is complex

All navigations are displayed by default as a list and don't try to do a "main navigation" outside of maybe grouping things differently. (A label for "main nav" and then "other navigations".) Each navigation can afford a drilldown level which goes back to the "only one navigation" items.

Conceptually the view for each navigation in focus mode is similar to the Style book, in that it shows the generic blocks as they exist. It still has value for the cases where you have multiple menus:

Tasks

jasmussen commented 1 year ago

Here's a first stab at this one. Let's unstick this one.

Only one menu, and the menu is pages only:

Only one menu, and the menu is pages only

Only one menu, and the menu is mostly pages but has one or two non page items:

Only one menu, and the menu is mostly pages but has one or two non page items

Multiple menus:

Multiple menus

Multiple menus, and the menu is complex:

Multiple menus, and the menu is complex

CC: @WordPress/gutenberg-design

scruffian commented 1 year ago

I have some questions about this:

  1. What counts as a complex navigation? Does does a nested navigation count as complex?
  2. If a navigation has nested submenus, should I be able to expand it and edit the children?
  3. Should drag and drop work within this view?
  4. If a link is not a page on the site, should it just be disabled as with the search block example above?
  5. The view of the focussed navigation shows it within the context of a template part - is that deliberate? What should happen if a navigation isn't used in a template? It might be hard for us to know which navigation is used in which template.
richtabor commented 1 year ago

When the menu has complex blocks (anything outside of a limited allow-list), we require you to edit the menu in focused mode, just like template parts

@jasmussen Do you have to have multiple navigations (with "complex" blocks), to then open in focus mode? So for sites with one navigation, you won't ever get to the focus mode, the "complex" blocks are just disabled, yea?

The view of the focussed navigation shows it within the context of a template part - is that deliberate? What should happen if a navigation isn't used in a template? It might be hard for us to know which navigation is used in which template.

I had this same thought. I think the intent is not to focus on the template part, but just the navigation. It may be difficult to surface the surrounding template part.

I get that focusing on the menu is helpful to figure out what navigation element you're editing, but it does add complexity to the flow/diverging expectations (editing nav items in sidebar v. not). I wonder if the added lift is worth it — or is just disabling "complex" blocks and not focusing on the menu fine?

What counts as a complex navigation? Does does a nested navigation count as complex?

If the Navigation has any blocks other than link-based (Spacer, Logo, Search, Social, etc). I would think sub-menus would not classify the navigation as complex.

If a navigation has nested submenus, should I be able to expand it and edit the children?

Yes

Should drag and drop work within this view?

Yes

If a link is not a page on the site, should it just be disabled as with the search block example above?

Should be editable via the LinkUI (if possible), same as we have today.

richtabor commented 1 year ago

What does the edit icon do? Focus mode on the navigation block? Or managing/naming?

CleanShot 2023-05-08 at 13 00 03
jasmussen commented 1 year ago

All good questions, let me take a stab.

What counts as a complex navigation? Does does a nested navigation count as complex?

We should decide this heuristic together, but as a starting point, any of these, I'd say could count as complex:

Related from Rich:

If the Navigation has any blocks other than link-based (Spacer, Logo, Search, Social, etc). I would think sub-menus would not classify the navigation as complex.

I think we can include logo, spacer and social as basic blocks, but I could also go either way on that one. Notably social links are still pretty clunky to build. In any case, we'd need to probably disable them in this view, just allow them draggable but not really editing otherwise. The key is to capture truly simple menus and have those shown right there. We can then fall back to requiring editing in the edit view otherwise.

If a navigation has nested submenus, should I be able to expand it and edit the children?

I wouldn't mind requiring edit view for that.

Should drag and drop work within this view?

Ideally.

If a link is not a page on the site, should it just be disabled as with the search block example above?

That was my instinct when making this. You can perhaps still drag it around, maybe move it. I think we can limit interactions if need be, since you'll always be able to press the Edit button and go in detail.

The view of the focussed navigation shows it within the context of a template part - is that deliberate? What should happen if a navigation isn't used in a template? It might be hard for us to know which navigation is used in which template.

and related

What does the edit icon do? Focus mode on the navigation block? Or managing/naming?

The edit button, just like when you are visiting a template part, takes you to the edit view for that particular menu.

So if we're looking at this one, I created that picturing it showing just the navigation block CPT, nothing else. We imply the background color from global styles, I guess.

To be clear, I would love for you to be able to edit the navigation block in context of its container template part. But I also know this is a bit of a technical challenge, and I'd personally be okay with just linking the navigation block in isolation as a starting point. Would love to hear from @mtias on this one.

richtabor commented 1 year ago

@scruffian If we're using List View instead of the OffCanvas, would we get drag and drop/expanding children etc for free?

SaxonF commented 1 year ago

A few more questions to consider:

jameskoster commented 1 year ago

We should mockup the isolated edit view as well.

Given settings and styles are governed by the container, I don't suppose we'll be able to include them in that view. Which raises the question: which settings and styles should be applied, and how do we help the user understand that to change these details (things like justification & orientation which seem crucial to navigation editing), they need to go and edit the containing template/template part?

draganescu commented 1 year ago

If we're using List View instead of the OffCanvas, would we get drag and drop/expanding children etc for free?

@richtabor OffCanvas is a ListView so nothing would be lost. List view also has drag and drop but we don't support expanding the tree on hover while dragging (which is what I assume "expanding children" means).

@jasmussen do the conditionals in your comment apply to the whole website, or to the navigation present on the homepage? I assume the default content in the preview will be the homepage hence the question.

annezazu commented 1 year ago

Wanted to pass along some related feedback from the FSE Outreach Program for this experience of having more than on menu and how folks are wanting to be able to select what's shown/manipulated there:

The site already had a Navigation section and I wanted to rearrange the one I just created. But the Navigation section in the sidebar did not let me select which of the menus I wanted to adjust. It just took one of the oldest ones I had. I expected that somewhere perhaps on the bottom that I would be able to switch menus and even select which is primary and as well as other selections in how a specific menu is to be used.

This echos what's already being thought of with multiple menus :)

jameskoster commented 1 year ago

Only one menu, and the menu is pages only

@jasmussen just to clarify this scenario, is it a Navigation that contains only a Page List block? Or a custom Navigation that contains only Page Link blocks? I think we need to consider both, and they may have slightly different affordances.

With a custom menu, the + would allow you to draft new pages, or add any other navigation child (page link, custom link, search, etc). A custom menu would also support revisions.

But Page List is less flexible, and may need to restrict you to drafting new pages only. Revisions probably don't make sense in this scenario either since Page List is synced automatically. Alternatively, it may offer the option to add things like custom links, search, etc., on the proviso that the navigation is converted to a custom menu first. At that point revisions come into play.

jasmussen commented 1 year ago

@jasmussen do the conditionals in your https://github.com/WordPress/gutenberg/issues/50396#issuecomment-1538327864 apply to the whole website, or to the navigation present on the homepage? I assume the default content in the preview will be the homepage hence the question.

Apologies, I'm not sure I'm understanding your question correctly. The conditionals you refer to are they the ones deciding whether a navigation block is complex or not? If yes, then I would say those conditionals apply to any menu, doesn't matter. And if the menu is deemed complex, we link to it. If the menu is deemed simple (mostly pages), we show the menu right in the inspector.

The content in the preview is a good question. I would say:

@jasmussen just to clarify this scenario, is it a Navigation that contains only a Page List block? Or a custom Navigation that contains only Page Link blocks? I think we need to consider both, and they may have slightly different affordances.

Primarily, it's a simple counter: "how many menus exist". If the answer is 1 (whether page list or custom), then we show it right there.

But you make a good point, you cannot really edit a page list menu. But I'm assuming that the modal that appears ("Do you want to convert to a custom menu?") would still appear if you attempted a drag action in this interface. What do you think?

With a custom menu, the + would allow you to draft new pages, or add any other navigation child (page link, custom link, search, etc). A custom menu would also support revisions.

The plus behavior is still not clear to me here, it would be good to visualize this more. It seems roundabout to me to have to insert a page link first (and there's even some discussion around that in #50432), then choose "Add new page" from that URL dialog, only to get the modal then. So we really need to stress the limits of #48456 to figure that out, since iteration 1 notes:

Can be triggered from nav menu, buttons, command center, etc.

What does the "triggered from nav menu" look like, if it doesn't open the modal directly?

To me, the simplest answer is this flow:

Adding pages flow

The context is clear, you're in the navigation section. Can we not just assume the new page modal will automatically add to the menu if you are invoking it from here? The nav menu can contain draft page links, after all.

jameskoster commented 1 year ago

But you make a good point, you cannot really edit a page list menu. But I'm assuming that the modal that appears ("Do you want to convert to a custom menu?") would still appear if you attempted a drag action in this interface. What do you think?

That seems good to me. It's a shame the sync is lost, but that's a separate issue.

draganescu commented 1 year ago

The overall goal of this panel is to allow users and site maintainers to be able to access, navigate, and modify their navigations without having to find them in a specific template in the site editor.

This is important to me - as for a long time I thought the goal of the panel was to allow people to browse through their website and preview their pages and sections, helping in a way to find the place you want to edit. I guess this is still true but it is not the goal it's a side effect.

With this goal a lot of what the navigation block does will be duplicated into the navigation screen of the site editor sidebar. I wonder if we should explore the idea of using blocks outside of their normal block list home? Just a though - I am not sure much will be gained by avoiding the duplication. I also don't think we have a good solution to share this functionality today because of how packages try to remain independent.

draganescu commented 1 year ago

@SaxonF some possible answers 👍🏻

What if a menu contains blocks but isn't yet part of a navigation block? How does it look on canvas/in editor?

This is not something that exists or will exist. All menus are wp_navigation CPTs which contain a restricted list of potential blocks (seel ALLOWED_BLOCKS of the navigation block edit component).

If you are editing a menu in the editor, do we allow styling of menu items?

I assume you mean if you open a navigation in isolation? Yes why wouldn't we allow styling? Ideally it should be similar to opening a template part in isolation.

When hitting +, what happens? Do we trigger https://github.com/WordPress/gutenberg/issues/49091?

@jasmussen the way I understand in Matias' origina post is the plus on the top right is to add a new navigation. "Should be possible to delete, duplicate, add a navigation from the ellipsis button next to the drill down state, just like templates, pages, and parts." - so that means in these mockups we need a way to add navigation elements via some other plus? @SaxonF that other plus should open something like the LinkUI yes - but potentially better than that popover madness.

When removing an item from a navigation, does it the remove the page itself or just the menu item? Since on menu item click it drills down to the page itself we need to make sure this is very clear.

Today it only removes the menu item. If we want to remove whole pages from this screen we need some more UI work to inform this is the consequence. But given the goal this screen has it should never be the case that we edit anything other than menus (data in the currently shown wp_navigation CPT, not the pages it links to)

What happens if a menu is part of multiple navigation blocks?

This cannot happen. We explicitly disable recursion in a navigation block. Maybe you mean something else?

What happens if you remove a menu that a navigation block is currently using?

Currently you get a notification in the canvas. @jasmussen and I found there are two paths to consider:

  1. User deletes the navigation they see - then the block falls back to a sort of best possible option - this is the case here where say you have a menu and you use the dot menu to remove it then the navigation sidebar of the site editor will render the next best thing - say you only had one menu then it will render your list of pages.
  2. User or plugin deletes the navigation from somewhere else - in this case the navigation screen in the sidebar should never display it in the 1st place. The blong OTOH will fall back to a best possible option but also show a message that something happened.
getdave commented 1 year ago

What if a menu contains blocks but isn't yet part of a navigation block? How does it look on canvas/in editor?

This is not something that exists or will exist. All menus are wp_navigation CPTs which contain a restricted list of potential blocks (seel ALLOWED_BLOCKS of the navigation block edit component).

I think Saxon means what if a menu exists but that menu is not assigned to a Navigation block instance.

The answer that as far as I can see it would be fine. The menu would be rendered into the sidebar and you could interact with it however you'd like. If later you choose to assign to a particular Nav block instance then that's also fine.

If you are editing a menu in the editor, do we allow styling of menu items?

I assume you mean if you open a navigation in isolation? Yes why wouldn't we allow styling? Ideally it should be similar to opening a template part in isolation.

One reason is that editing a menu in the sidebar makes it devoid of any particular design context. Let's say you create a menu in your header using the Nav block and then you add styling to the menu items. Then later that menu ends up being shown in the Browse Mode sidebar and you click through to "isolated" view. Then you start making visual changes. Then doesn't that risk you breaking the design of the Navigation in it's original location?

For me, it's always been important that we put all the styling on the parent Navigation block and allow it to cascade down to menu items. If we do this then the items themselves remain as largely "data" and the parent is the supplier of context specific styling.

getdave commented 1 year ago

Also here is a reminder that I explored Isolated/Focus mode for Navigation Menus here.

jasmussen commented 1 year ago

Good thoughts all around. Just zeroing in on this one:

User deletes the navigation they see - then the block falls back to a sort of best possible option - this is the case here where say you have a menu and you use the dot menu to remove it then the navigation sidebar of the site editor will render the next best thing - say you only had one menu then it will render your list of pages. User or plugin deletes the navigation from somewhere else - in this case the navigation screen in the sidebar should never display it in the 1st place. The blong OTOH will fall back to a best possible option but also show a message that something happened.

Here are two quick sketches I created to highlight those. Deleting menus in the editor while looking at it:

Deleting menus, basic fallback behavior i2

Coming back to a template where the menu was deleted elsewhere:

Coming to a template with a deleted menu i2

The deletion flow is rather tricky. You delete something that potentially a bunch of templates or template parts are referencing, what happens to those? The above flows "repair" them when you go and edit them, requiring you to confirm the change in the saving flow, rather than letting the block sit in an inactionable state.

Question: is there a way to list every template or template part that might be referencing a deleted menu?

scruffian commented 1 year ago

Question: is there a way to list every template or template part that might be referencing a deleted menu?

Not right now, and it's not easy to do.

The above flows "repair" them when you go and edit them, requiring you to confirm the change in the saving flow, rather than letting the block sit in an inactionable state.

The above makes this very difficult to achieve.

scruffian commented 1 year ago

I had a go at breaking this into discreet tasks so we can start working on them:

  1. Navigation on Browse Mode: List all navigations When users have more than one navigation, show a list of them in the sidebar. If they only have one, just show that one directly. They will use the names that navigation CPTs already have, which won't be editable (yet).

  2. Navigation on Browse Mode: Make navigations in the list selectable. When users select a navigation from the list, update the navigation list view in the global sidebar to show the selected navigation, and show only that navigation menu in the preview. Also update the URL so that each navigation has its own direct URL and users can navigate the UI with URL history. This is unnecessary in the case where users have only one navigation.

  3. Navigation on Browse Mode: Add pages When users have a navigation selected (or if they have only one), add a [+] next the the "Navigation" title in the Navigation panel. This [+] will trigger the add new page modal. When the new page has been created it should be added to the selected navigation. We will need to determine whether the navigation already contains a page list block. If it does then we don't need to add the page, if not then we do.

  4. Navigation on Browse Mode: Add edit button When users have a navigation selected (or if they have only one), add an edit button next the the "Navigation" title in the Navigation panel. This edit button will open the canvas preview to display the selected navigation in focus mode.

  5. Navigation on Browse Mode: Add ellipsis menu When users have a navigation selected (or if they have only one), add an an ellipsis menu next to the "Navigation" title in the Navigation panel, which offers options to delete (and if simple to do duplicate) each navigation.

  6. Navigation on Browse Mode: Back button Once a single navigation is selected, the back button should take users back to the list of navigations.

draganescu commented 1 year ago

@jasmussen the second flow:

Coming back to a template where the menu was deleted elsewhere:

Is extremely confusing. I think we still need to tie the message to the block. The notification is just not right, particularly if you open a tempalte with multiple navigation blocks. Let's try to use the inspector?

jasmussen commented 1 year ago

Is extremely confusing. I think we still need to tie the message to the block. The notification is just not right, particularly if you open a tempalte with multiple navigation blocks. Let's try to use the inspector?

We can also revisit this one? https://github.com/WordPress/gutenberg/pull/44778 — the key bit here is that if we show a message in the canvas, it needs to be tiny, because we cannot assume that there's ever going to be room for context to show.

jasmussen commented 1 year ago

Coming back to this one, had some conversations with @getdave and @scruffian that although these mockups get some things right, there are some limitations worth revisiting. Notably that while we think of a navigation as one thing, it's actually two. It's the blocks inside (the data stored) and the block itself. So while we need to be able to provide a link to a single navigation menu from the left sidebar, what we can provide access to there is a link to the navigation storage, but not in the context where it's wrapped by a styled navigation block.

Conceptually that makes this view slightly similar to the Style book, in that it shows the generic blocks as they exist, with some dummy content, not the styled blocks across. It can still provide value in having access to those menus in this interface, just like the style book has value:

The most basic use case: a single simple menu, is still easily handled the left sidebar of the site view. With that in mind, here are some mockups.

Only one menu, and the menu is mostly pages:

Only one menu, and the menu is pages only

Everything here is editable in the left sidebar.

Only one menu, and there are some non-standard blocks in it:

Only one menu, and the menu is mostly pages but has one or two non page items

Again, mostly editable. There's a visible edit icon now, to take you to editing the menu in isolation, if you need to edit the non-standard block inside.

Multiple menus:

Multiple menus

When you have more than one menu, the top level of the navigation section becomes a list of all your menus, and each of the menus then drill down to a detail page for each. Those detail pages then fall back to the heuristics for "just one menu".

Note here how the preview of the menu shows it as vertical, even though it is probably horizontal when used in a template. This highlights one of the shortcomings of "navigation data" vs. "navigation data plus navigation block". But it still feels both valid and useful to show these styled in their global styles.

Multiple menus, and the menu is complex

Multiple menus, and the menu is complex

Finally, the case where a menu is complex enough that you can't edit it in the left sidebar. In this case we force you to click the edit button, or the preview, to edit in the site view.

Shown here in the site view is a treatment similar to that of the style book, with labels and a dropdown in the canvas that lets you choose vertical or horizontal, to see how the data is visible in the various orientations.

Edit: Updated the mockups to show the menu defaulting to horizontal, as appears to be the case in Global Styles → Style Book as well, which is what this is based on.

scruffian commented 1 year ago

Thanks for this @jasmussen. There are a couple of things I would suggest:

  1. If a navigation contains things that are not navigation links, I don't think there is a need to restrict what we can do with these items - they will be shown inside a list view, so all the normal actions should apply. I think this will keep things simpler and more consistent.
  2. I think it's still worth providing an edit button even in the case where uses have only only one navigation and it's simple because they might still prefer to edit it in the canvas.
jasmussen commented 1 year ago

If a navigation contains things that are not navigation links, I don't think there is a need to restrict what we can do with these items - they will be shown inside a list view, so all the normal actions should apply. I think this will keep things simpler and more consistent.

I would be happy to avoid locking some things down, but this was explicitly in response to some of the changes we encountered late in the 6.2 state, where some items just weren't a good editing experience at all. I think @jameskoster might recall a bit more precisely which blocks fell apart when clicked in the dark material on the left.

I think it's still worth providing an edit button even in the case where uses have only only one navigation and it's simple because they might still prefer to edit it in the canvas.

I don't personally mind that.

draganescu commented 1 year ago

@jasmussen I still have some questions about the whole flow:

Sorry for being such a pest here but it is not simple to approach, and for a lot of these problems we have had to go through solutions that applied to the block inspector. The block inspector has tabs and panels with inputs, it's a lot more forgiving compared to this clean black surface, so I think we need to really think all interactions through and through.

draganescu commented 1 year ago

I know this could sound weird but in the block editor for widgets in the customizer we have this drill down flow:

https://github.com/WordPress/gutenberg/assets/107534/af266606-3756-410b-8ee1-526346ee237e

Could we use the same approach for editing navigation items - by they a link or some other block type?

jasmussen commented 1 year ago

can we do any content editing to navigation items in the sidebar?

As much as works well, I'd say.

does the [+] always add a new page and always enters the new page pattern based flow described in https://github.com/WordPress/gutenberg/issues/48456 ?

Thanks for asking that question, that's a flow I should've visualized more. My personal take is the following:

I know that @SaxonF has some work on that modal in https://github.com/WordPress/gutenberg/pull/50565, so I'd appreciate his input as well.

in https://github.com/WordPress/gutenberg/issues/50583 how is a navigation added (the description of this issue says add/edit/duplicate)? What is the next step after clicking add navigation? also how is a navigation renamed?

I kept that separate for #50583, but I could swear I saw some mockups that @jameskoster did for this. If I'm not misremembering, they'd be good to add to 50583.

in the frame when opening a complex nested navigation as in this mockup how do we represent nested items? Do we ident them? Is the content always centered?

The representation of the menu here should be similar to how the Global Styles → Style book presents it. It appears to actually default to showing it horizontally, so that's an error in the mockup that I will correct:

Screenshot 2023-05-16 at 09 06 07

The style book for navigation does not show nested items. But I would presume that it would show them as dropdowns, as is the default behavior. Any tree view explorations I would keep to a separate future exploration.

The menu is as wide as the default content-width, and is centered same as the center column is.

I hope that helps, if it doesn't let me know and I'll take another pass.

jameskoster commented 1 year ago

For the [+] button, should we also account for adding existing pages to the current menu, if it is complex? There's also adding new menus to consider down the road.

but I could swear I saw some mockups that @jameskoster did for this

Not yet I'm afraid, but the other panels are in this Figma, if you'd like to add Navigation.

scruffian commented 1 year ago

in https://github.com/WordPress/gutenberg/issues/50583 how is a navigation added (the description of this issue says add/edit/duplicate)? What is the next step after clicking add navigation? also how is a navigation renamed?

For the first iteration at least it won't be possible to add or rename navigations using the side bar in browse mode.

jasmussen commented 1 year ago

I've tentatively updated this issue with the most recent mockups as they appear to be solidifying. Let me know if that was in error.

getdave commented 1 year ago

There has been a fair amount of progress here. We now have

✅ Listing Navigations ✅ Single Navigation ✅ Edit, Rename, Duplicate, Delete ✅ Focus Mode for Navigation ✅ Showing Navigation in Template Parts that contain a Nav block.

getdave commented 1 year ago

Update: the only features that didn't land here are:

mtias commented 1 year ago

@getdave thanks for the update. Let's follow up separately on the add page flow, I'm going to close this as done for now. Good work!

iamleese commented 1 year ago

I'm currently testing WP 6.3 and I'm glad to see the Navigation option in the Editor. After playing around with it, there is a lot of redundancy and departs from the current user flow of the Editor to edit the patterns, templates, and styles. I would suggest we remove the sidebar completely after the menu selection and go directly into the editor so the flow would be:

Navigation > Menu Name > Editor

navigation_flow

If it were to change like this, the only thing missing would be to edit the menu name itself.

Function-wise, If the navigation styles are dictated by the template they're placed it, it seems that the styles would be unnecessary and that the primary function of this feature would be to only edit labels and links.

Perhaps looking ahead, the Navigation area could expand to mega-menu building and styles might have to be preset within the menu. But for this release, if it's only meant to make editing the navigation easier, I think removing the style option would be best.

getdave commented 1 year ago

Thank you for taking the time to provide feedback. It's very much appreciated and highly valuable.

My concern is that if we remove the sidebar we would loose the options menu that allows you to rename, duplicate and delete. This would make discoverability of these key features harder.

Also all other "focus" modes (e.g. Patterns) open with the sidebar so this would be inconsistent.

I also envisage the sidebar providing great utility in future releases - but that's subject to discover from @WordPress/gutenberg-design.

draganescu commented 1 year ago

Thank you @iamleese - I do see your point regarding redundancy, it's true, and I think that one of the things we'd lose if we remove showing the navigation itself in the sidebar is the ability to navigate to pages and posts linked in the menu. So it's not an easy call. This is a very intuitive wayfinding option for many sites, particularly the ones which only have one menu. It's very easy to reason about editing some page if you see the exact menu you have on your website and find the page in it as you would on the front end.

Plus, the isolated editing also is probably going to serve more as a power feature, one where much discussed mega menus could be built (somehow). It's not a screen where everyone should land by default - particularly with the current scary barebones UI 😁