Introduce "Browser" and surface main navigation UI

[mtias]

The latest work on the navigation block infrastructure has allowed us to isolate the inner link items of the navigation block into its own post type. This now allows us to have a focused interface for managing the site structure in addition to the presence of the navigation block on the canvas. This can take different views with the focused template part mode and the list view affordances native to the block editor.

We also have all the relevant tools implemented for the tree-view of links to be a viable management interface for pages and link items. It supports reordering, drag and drop, nesting, etc.

At the same time, the W menu has been one of the proposed destinations for managing templates. This issue proposes the combination of these features and an alternate exploration where they become top level items. The aim of this work is to allow prominent access to navigation structure regardless of the state of the site editor. (For example, if navigation is collapsed on an overlay menu, the page is scrolled beyond visibility, etc.)

---

The list view trigger from the navigation menu (which formerly opened a modal) would open this panel instead, connecting the flows:

---

Finally, another option that avoids the confusion of the W menu behaving erratically between editors would be to expose this access as top level tools:

This might be a more palatable interim solution while the whole experience of the W menu is iterated upon and established across editors. The following video describes how it might work.

nav+templates.mp4

There's a few unattended details, like having a dropdown to select among different navigations used (in case a footer has a different one, etc), but it paints an idea of how it could work.

Thanks to @jameskoster and @jasmussen for exploring this idea with me.

Todo List:

• Introduce the browse mode Reorganize the site editor to introduce Browse Mode. #44770
• Fix aria regions navigation The new site editor Browse Mode breaks ARIA landmark and navigateRegions #46509
• Rework the "Edit" button position and design Move the edit button in the site editor sidebar to a contextual widget #46700
• Restore the of '< Dashboard' button
• Hide the inserter buttons from the "view" mode Site Editor: Don't show block inserter when the canvas is view mode #46763
• Move the template list to the left sidebar Site Editor: Try template drill down on shell sidebar (browse mode) #45100
• Move template creation to the sidebar Allow adding new templates and template parts directly from the sidebar #46458
• Move the Navigation menus to the left sidebar Add: Navigation menus to the browse mode sidebar. #46436 (@jorgefilipecosta )
• Allow resizing the sidebar/frame Allow resizing the sidebar and frame of the site editor #46903
• Notice appearance in Browse view #46274
• Add indicators to all drilldown menu items in browse view #48022
• Height mismatch between viewing and editing template parts #48476

[pablohoneyhoney]

There’s also an opportunity to organize those taxonomies (Templates, Navigation, Styles) elevated to the persistent level of the W. Here are some explorations of what that could look and behave.

In one exploration (likely my preference) we can accommodate those architectural instances in a more visible UI that can be toggled and related more clearly. Here are some variants with slight permutations on how colors and positions can help link the W and the immediate navigational items.

In another path, those higher level instances can be presented in a flyout when interacting (hover and click) with the W. This permits to keep the current simplicity of the top bar to arguably focus on the content controls. And it also surfaces more evidently the return to wp-admin. Various indicators can hint the presence of the flyout.

Templates and Navigation can trigger the correspondent left panel, while Styles can (for now) still open the right-side panel.

[jameskoster]

I like the idea of dark areas of UI equalling global elements very much, it creates an environment for site settings to live as well. Exposing the site structure / navigation is particularly exciting because it means we can offer an intuitive way to navigate and edit different pages in the site editor.

The flyout approach solves potential scalability issues that may occur with the W button expanding horizontally. I explored a vertical approach as well, which adds another layer of abstraction and solves the scalability issues at the expense of 60px horizontal real estate.

vertical.mp4

[jameskoster]

It occurred to me that Reusable Block management could live in this global UI region too :)

[SaxonF]

Some overlap with the thinking here #32682

[SaxonF]

Thinking about this some more, navigation structure within the left sidebar does feel a little strange to me personally because it is so detached from the navigation itself. I would expect it to be part of the block settings on the right, consistent with other blocks. Technically navigation structures might be global, but I'm assuming you would rarely have one set used in multiple places on your site.

[jasmussen]

One aspect I like about surfacing a dedicated navigation is that it provides an obvious default for the (presumably majority) of sites that have only a single navigation menu. Such a default can be loaded by default as well, for example in the navigation block.

[jameskoster]

Centralised menu management is also useful when

1. There are many menus – the one you want to edit next may not necessarily be on the current canvas.
2. You want to work on a menu but not attach it to a template yet. Like a draft.

It does pose an interesting question though. If we say that the contents of global elements like menus are managed in a distinct interface separate from the canvas, do Reusable Blocks and Template Parts get a similar treatment?

[jasmussen]

If we say that the contents of global elements like menus are managed in a distinct interface separate from the canvas, do Reusable Blocks and Template Parts get a similar treatment?

I imagine what we currently do for isolated template part editing being a pattern to be leveraged for a majority of UIs like these, reusable blocks, perhaps even for editing the contents of the navigation modal.

[SaxonF]

There are many menus – the one you want to edit next may not necessarily be on the current canvas.
You want to work on a menu but not attach it to a template yet. Like a draft.

@jasmussen @jameskoster Could I accomplish the above using re-usable blocks (containing nav block) edited/created in isolation? There are already so many concepts to grasp when it comes to global elements (template parts, templates, re-usable blocks) that I fear introducing yet another will be overwhelming.

This opinion could just be because I'm used to working in design tools like Figma (with components) but Webflow takes a similar approach with their symbols and it just feels simpler.

[jameskoster]

Funnily enough Joen and I were chatting about this last week and yes – you could accomplish this with reusable blocks, or template parts for that matter 😅

I have begun wondering whether "reusability" could be a more abstract concept. So rather than providing multiple elements that all essentially do the same thing, perhaps all blocks have a toggle to make them reusable or "synced". I'm sure there are many trade-offs to this, but on the whole I agree – adding more reusable elements only makes things more complicated for the end user.

[SaxonF]

I really love the thinking behind @luisherranz suggestion in the synced block thread you referenced and believe the same simplification/unification principle could apply here.

Taking the idea to the extreme you could even argue that a navigation block isn't even needed. Just create a pattern containing a row with a logo and some links. If you need a submenu, add a generic dropdown block to your row.

[jameskoster]

Yes, if there was an option to mark patterns with semantic meaning (header, footer, navigation) then we could remove both the Navigation and Tempalte Part blocks.

[getdave]

You want to work on a menu but not attach it to a template yet. Like a draft.

This touches on the concept of "safe exploration" which I feel is a key use case driving the argument for some kind of standalone means to edit the "items" of a Navigation Menu (i.e. wp_navigation) in isolation from the Navigation block.

For example, I might have a variation of my primary navigation which I only wish to expose at a certain point in the future. With the current Navigation block that's going to be very hard to achieve.

If we afford a place where menu data can be safely created and manipulated in isolation from the site canvas, then that's going to make it much easier for users to create and manage menus.

Note: this isn't straying far from the direct manipulation paradigm - the primary means for creating menus can still be via the block - but it's important that we recognise the alternative workflows that we need to cater for.

[SaxonF]

@getdave the idea @jameskoster and I are discussing definitely goes beyond the scope of this particular issue but its worth mentioning because it would solve the same "safe exploration" problem, but for all blocks, not just navigation/menu.

In Figma you can create a library that is detached from your main design. You're free to add components (e.g. nav menu) and styles to that library without them actually being put to use. When you're ready, you can add these components from your library to your design, or replace existing components. The same mental model applies to Storybook (building components in isolation) and could apply here. We already take a similar sort of approach with templates.

Much like the mindset @luisherranz has, I do think there is an opportunity here to design a single solution that solves for multiple problems, not just for navigation. I realise there are complexities around backwards compatibility that need to be considered.

Might be worth a separate thread.

[gwwar]

I'm going to try a small spike to see what issues I run into, let me know if folks have already started on this one.

[youknowriad]

Some updates here:

• we can now move the separator between the sidebar and the frame (we can resize the frame)
• The "edit" mode is persisted in the URL, so you can refresh the page and keep the state.

[getdave]

Please note that Nav Offcanvas is looking to come out of experimental which may affect this effort.

[annezazu]

Wanted to note feedback here that a few folks, including in the latest call for testing, have asked about having the three dot menu icon next to the templates and template parts while in browse mode. I both see designs that include that as an option and designs that don't along with this note "Move template search, save indicator to the sidebar (potentially clear customization)".

Here I expect to see 3 dots as can be seen in the Manage all templates screen. Perhaps these lists should be similar to the List View with the 3 dots and drag and drop.

@youknowriad can you clarify if this is being currently explored or whether it makes sense to open an issue for now otherwise in case it continues to come up? To be clear, talking about this:

[youknowriad]

@annezazu There's a todo item on the issue about this but so far management tasks like this has been considered to be "advanced tasks" that you can see in the "manage templates" page instead of the sidebar where it's mostly about navigation. I think at the moment, there are still uncertainties around this and I'm basically waiting for more clarity from designers.

[getdave]

@youknowriad Would you now consider this complete?

[mtias]

No, I think we need to still work on the nav structure setup which hit a lot of hiccups when integrating.

[getdave]

Ok thanks for clarifying. So this is only complete once the Navigation aspect of Browse mode has fully landed and is stable in the Plugin.

[annezazu]

In trying to do a phase 2 update, it seems the remaining item to complete (Navigation aspect of browse mode) now has its own dedicated issue: #50396. In light of that and with no remaining work to be done here, can we close this out and defer to the dedicated issue?

[scruffian]

I agree with @annezazu that this can be closed.

[pbearne]

Can we add this ticket as feature request https://core.trac.wordpress.org/ticket/19867