Make the navigation options available inside site editor more predictable

[draganescu]

What problem does this address?

Currently in the site editor there are multiple ways to navigate "back", and they're all called "back", but not all of them go "back".

multiple-ways-back.mp4

In the video:

• to exit the frame I can use browser back OR the site W icon
• to exit focus moda I can use browser back OR the back button in an unspecific place
• to exit template mode I can’t use browser back and need to find another back button in another unspecific place

What is your proposed solution?

We need to figure out at least a couple of things:

1. do we trust the browser back button to work and be discovered.

• If yes, do we want to provide a consistent behaviour of browser back
• If no, do we, also or instead?, provide, a consistent, findable and universal way back?

2. do we have two things going on: navigtion and mode entering and exit?

• if yes, let's figure out how to create stable and predictable affordances for each of these actions instea of calling everything back,
• if no, see (1)

[richtabor]

Related to #56150 (comment).

When you are in a focus view, the <- Back should always take you back to the view that the focus view was invoked from. Currently it acts as a "Back" action, which if not immediately invoked will not take you back to the initial view.
It's particularly rough when you start from a refresh, as you can't ever get back.

nav.mp4

[jasmussen]

Some questions and answers related to this.

What happens when you are in a page and you navigate to a template part and then you navigate to a navigation block. Do we have two levels of go back buttons?

In this case, it migh be Page → Template → Template Part → Navigation. Yes I’d expect it to be straight waterfall navigation for these nesting levels, so pressing Back on Navigation would go up to the Template Part, then up to the Template, then up to the Page. Mockup showing this:

This is similar to Illustrator’s Isolation Mode, except without the breadcrumbs. Those breadcrumbs are implied by the title inside this document interface, which animates directionally depending on which level you are entering or leaving.

Does this mean that as soon as you break the cycle (click the “W” menu and navigate elsewhere, the history is kind of erased => no back button anymore)?

Yes. When you go back into edit view, you enter at the top level, i.e. directly into a Page, or directly into a Template.

[youknowriad]

@jasmussen Based on these replies. This is the mental modal and the understanding of the changes and impact that this would have, for confirmation:

• It means that when you click "edit template" followed by "w" menu, you'll see the template in the site editor sidebar (currently you see the page).
• It means that the title of the document (browser title) changes when you do that.

Technically it means:

• It means that we most likely need some kind of callback "setting" in the EditorProvider. editEntity( postType, postId )
• It means that we most likely need another "setting" in the EditorProvider. navigateToPreviousEntity
• It means that most likely need to keep a "history" somehow and that "history" is pruned if you navigate through the sidebar of the site editor
• It means that the same "history" and settings need to be shared with the "post editor" as well since the post editor supports "template mode as well".

Ultimately this means:

• The post editor will also "gain" support for these focus modes or in other words have pages to edit navigation, edit template parts, edit templates... not just template mode.

[jasmussen]

It means that when you click "edit template" followed by "w" menu, you'll see the template in the site editor sidebar (currently you see the page).

Yes. W always takes you to the previous major screen. I.e. Edit view > Site view > Top level dashboard.

I think there are some larger level lateral navigation concepts we can explore, the command palette is one example, some other breadcrumb options is another. But those don't change this fundamental behavior, IMO.

The post editor will also "gain" support for these focus modes or in other words have pages to edit navigation, edit template parts, edit templates... not just template mode.

The post/page editors would take you to the dashboard when clicking the W still, right? There's not a site view for those.

But yes, and to an extent this is related to #45264. Focus mode can be a useful way to focus on just one section at a time.

CC: @WordPress/gutenberg-design

[youknowriad]

The post/page editors would take you to the dashboard when clicking the W still, right? There's not a site view for those.

Yes, but you'll still be able to navigate between post => template => template part without ever leaving the post editor.

[jameskoster]

This may be totally irrelevant so feel free to ignore, but there is a similar problem to solve in the sidebar itself. The < is not always predictable, e.g. navigate to template details > click template part shortcut > click back, instead of returning to the template details you go to the template part management view. Is it possible to build a solution that can work in both areas?

[SaxonF]

It means that when you click "edit template" followed by "w" menu, you'll see the template in the site editor sidebar (currently you see the page).

IMO the sidebar should show whatever root document in the breadcrumb trail. If I go to my list of pages and edit a page, then click "edit template" and click W, it should show me the page. If I move laterally (e.g. open a template from command palette while editing a page) then it would show the template. We otherwise risk jumping all over the place, especially when synced patterns are edited in focus mode.

[youknowriad]

IMO the sidebar should show whatever root document in the breadcrumb trail. If I go to my list of pages and edit a page, then click "edit template" and click W, it should show me the page. If I move laterally (e.g. open a template from command palette while editing a page) then it would show the template. We otherwise risk jumping all over the place, especially when synced patterns are edited in focus mode.

I think we should decide that upfront. If the sidebar should show the "page" (root entity), then why are we changing the "url" when going into focus mode. For me it just means that we didn't "change" the active page.

But the question becomes: is "focus mode into a template part" and "editing a template part" from the sidebar two different things? why?

[draganescu]

The site editing experience today has at least three levels of depth:

• frame view
• editor view
• focus view

Each of these views can navigate laterally:

• frame view can navigate to different sidebar sections
• editor viiew can navigate to different editing entities
• focus view can navigate to different editing entitites

We have three navigation elements:

• the W button
• the back button in the frame view
• the back button in the editor and focus views

Maybe we could standardize the W to always mean up? Then we'd be left with the two backs which move laterally back. So in the example:

Site editor → Pages → Page → Template → Template Part → Navigation

we have this sequence:

Frame View [lateral >] Pages [down /] Editor View [lateral >] Template Part [down /] Navigation

and we could make it so that to get back on precisely this path:

Navigation [W button - up /] Template Part Editor [Editor Back - back <] Template Editor [Editor Back - back <] Page [W button - up /] Pages [Frame Back - back <] Site editor

Ideally we'd figure out a UI where the Frame back and the Editor Back would be easier to grok as doing the same thing. But standardizing the W logo to mean "up" could solve some problems IMO.

Browser back

Ideally the browser back will always do the next expected thing. For example in the path:

Site editor → Pages → Page → Template → Template Part → Navigation

pressing Browser Back takes you back this exact path:

Navigation → Template Part → Template → Page → Pages → Site editor