Navigation on Browse Mode

[mtias]

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.

• Navigation on Browse Mode: Add ellipsis menu #50583
• Navigation on Browse Mode: Add pages #50580 (refer to modal in Creation modal for "New Page" #48456)

If only one navigation and the navigation is simple:

• Show the navigation content directly and don't include the name of the navigation.
  • Made of a single page list — we display the page list block and allow the normal edit operations we have on the navigation block itself (syncs pages by default; if reorder, then it doesn't, etc). Selecting a page goes into the details view of that page as normal.
  • Made of mostly page items — if it's a custom navigation but with a few additions (like a search block) we still allow editing directly. If we detect blocks that are not just page list or links, we should allow editing the block as a focused template part by having some icon button for it prominently. (These navigations are operating both as high level data structure and template parts.)

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

If more than one navigation:

• Navigation on Browse Mode: List all navigations #50578
• Preview just the navigation on the frame like a template part upon selection.

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

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:

• It provides an easy overview of which menus you have saved
• It provides a single place to manage them
• You can edit them, even if you don't necessarily see the styles that might be applied by a wrapping navigation block or template part.

Tasks

• Navigation on Browse Mode: Remove existing editing functionality  #50698
• Navigation on Browse Mode: List all navigations #50578
• Navigation on Browse Mode: Make navigations in the list selectable. #50579
• Navigation on Browse Mode: Add pages #50580
• Navigation on Browse Mode: Add edit button #50581
• Navigation on Browse Mode: "Grey out" non-link blocks #50700
• Navigation on Browse Mode: Add ellipsis menu #50583
• Navigation on Browse Mode: Back button #50584
• Navigation on Browse Mode: Add navigation list view to the template part editor #50704
• Navigation Focus Mode: Ability to access/edit Navigation Post items in isolation #37950

[jasmussen]

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

Only one menu, and the menu is pages only:

• Show pages right there.
• Plus to add pages. (Related: Creation modal for "New Page" #48456 (comment))
• No drilldowns, just the single menu right there
• Future Revisions link in the Save hub (Related: Meta actions on details view #50379)

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

• Search block is shown as disabled. We may need to tune the colors to differentiate more.
• Edit button is surfaced for the advanced editing.

Multiple menus:

• Each menu is listed directly in Navigation with drilldowns.
• Each individual menu then falls back to earlier behaviors.

Multiple menus, and the menu is complex:

• 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

CC: @WordPress/gutenberg-design

[scruffian]

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]

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]

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

[SaxonF]

A few more questions to consider:

• What if a menu contains blocks but isn't yet part of a navigation block? How does it look on canvas/in editor?
• If you are editing a menu in the editor, do we allow styling of menu items?
• When hitting +, what happens? Do we trigger Link UI?
• 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.
• What happens if a menu is part of multiple navigation blocks?
• What happens if you remove a menu that a navigation block is currently using?

[jameskoster]

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]

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]

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]

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.

[jameskoster]

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]

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]

@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 #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]

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]

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

[jasmussen]

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:

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

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?

[jameskoster]

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]

in #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]

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]

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]

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

• Navigation on Browse Mode: Add pages #50580 - no one was 100% sure about the UX on this one (and we also ran out of time).
• Navigation on Browse Mode: "Grey out" non-link blocks #50700 - this feels like it's no longer required given that we have Focus Mode for Navigation.

[mtias]

@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]

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

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]

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]

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 😁