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.