Site Editor: clicking on page in Navigation section and returning brings you to Pages section

[annezazu]

Using 15.8 RC 1, I noticed that if I clicked on a page in the Navigation section and then tried to go back a level, it lands me in the Pages section rather than Navigation. I'd expect to be put back in the Navigation section rather than pages. cc @youknowriad and @WordPress/gutenberg-design.

randomly.sent.to.pages.section.mov

Of note, there are current three different experiences depending on what you have in your navigation right now:

• Clicking custom link causes the link UI to pop up.
• Clicking on post brings you to the post itself and you can return to the navigation section no problem.
• Clicking on the page brings you to the page itself but you can’t return to the navigation section — you’re brought to the Pages section now. That's this issue.

Sharing for broader context around impact.

[jameskoster]

I agree the user should be returned to the referring panel.

A similar behavior is being worked on in #50630 whereby clicking a template like 404 in the Pages panel, will return you to Pages panel when you click Back.

[tellthemachines]

Hmmm, sounds like we always want the detail page to go back to the list we were on previously? If so, it might be better to find a more overarching solution than the hacky patch I tried for #50630 😄

[youknowriad]

For me this problem is not well defined.

• Do we want the "back" button to behave as a "browser back" button
• Do we want it to behave as a "parent" button?

It seems what's being suggested is a mix of both, which is a source of bugs IMO unless defined properly and I suspect that no matter what behavior we implement, we'll always have this issue for "shorcut links". The link from the navigation sidebar is a "shortcut" not a drill down, I think for me a better fix would be to remove the arrow from their to make it clear that it's not a drill down.

Edit: I just saw that there's no arrow already. So for me, we shouldn't try to fix this bug by changing how back button works, instead of should find a way to clarify in the UI that we're not going "down", we're just navigating away from "Navigation"

[draganescu]

I don't agree with @youknowriad in terms of not fixing. I think if a navigation contains a link to a page it's always gonna be surprising that clicking back takes me to the pages screen instead of to the parent navigation. I am so sure of this that I'll remove the Needs Design Feedback 👍🏻

I do agree with @youknowriad that we need to make up our mind about what the back button does - and I support it's a go to parent action in a drill down screen.

[youknowriad]

I do agree with @youknowriad that we need to make up our mind about what the back button does - and I support it's a go to parent action in a drill down screen.

The reality is that it's already a "go to parent" and the parent of a "single page opened in the site editor" is not "Navigation", it's "Pages" :)

In other words, the links in "Navigation" don't go into "Navigation > Page 1" they go to "Pages > Page 1" because we also have links in "Pages" that go to "Pages > Page 1". The links in Navigation can be seen as "shortcuts".

[jameskoster]

The links in Navigation can be seen as "shortcuts"

The problem is this creates a confusing and frankly annoying UX. In a flow like Navigation -> Page details, it is:

1. Unexpected that you'd be taken to Pages when clicking back from a Page panel
2. Frustrating that to get back to your original task (editing navigation) you have to exit the Pages panel before you can re-enter Navigation.

A canonical / default parent for each detail panel seems fine, and will account for shared links. For a page, the Pages panel is the appropriate canonical parent.

But it feels quite clear that we need a way back to the referring panel based on the users click path. From a UX perspective, the expectation is that the < button would carry this behavior, but if that's not going to be feasible then perhaps we need to explore another element?

[youknowriad]

But it feels quite clear that we need a way back to the referring panel based on the users click path. From a UX perspective, the expectation is that the < button would carry this behavior, but if that's not going to be feasible then perhaps we need to explore another element?

It is feasible but I'm saying that it's confusing too. Imagine you land into a "details" page from a shortcut elsewhere in WP-Admin, or directly throught the URL. Do you want the "back" button to go to the "previous browser page" or to "the canonical parent" in that case.

[jameskoster]

Do you want the "back" button to go to the "previous browser page" or to "the canonical parent" in that case.

The canonical parent. For me the < button is an inherent feature of the drilldown, unrelated to the browser history, despite the frequent overlap. It's basically the same behavior that you find in apps like iOS' Settings. For the situation you describe, to get back to the original location you can use the browser back button.

I've often suggested that we could eliminate some of the confusion by including a label describing where the < will take you:

Not saying we should definitely do that, but it has come up a few times.

[youknowriad]

The canonical parent. For me the < button is an inherent feature of the drilldown, unrelated to the browser history, despite the frequent overlap. It's basically the same behavior that you find in apps like iOS' Settings. For the situation you describe, to get back to the original location you can use the browser back button.

But that's in contradiction with what you suggest. If it goes to parent, then it will always go to "pages" no?

[jameskoster]

Okay, let's break this down. Outside of the linear drilldown / up paths which are working fine, there are three(?) ways you can potentially land on a details panel, and we need to work out the < behavior for each.

Opening directly

If you open a URL such as mysite.com/wp-admin/site-editor.php?postType=page&postId=xxxx to view page details.

Here the canonical parent makes sense to me. IE < takes you from Page details to Pages list panel.

Traversing a shortcut within the drilldown

Examples:

• Clicking a Page in the Navigation panel which takes you to Design > Pages list > Single Page details.
• Clicking the 404 template in the Pages panel which takes you to Design > Templates > 404 details.

In these cases the canonical parent should probably be overridden. So in the first example, clicking < on the Single Page details would return you to Navigation instead of Pages list.

Traversing a shortcut from wp-admin

I don't think we have any of these yet(?). But for arguments sake let's imagine that clicking a page in the wp-admin Pages list opened the site editor like so:

In this case it seems reasonable to expect the < to return you to the wp-admin pages list, like a browser back button. But I appreciate this is adding yet more complexity.

I'd love to hear @jasmussen @SaxonF @richtabor's thoughts on this.

[youknowriad]

Outside of the linear drilldown / up paths which are working fine, there are three(?) ways you can potentially land on a details panel, and we need to work out the < behavior for each.

This is the part that is confusing to me. Why the same button need to behave differently depending how you came to a given page. You may even forget how you got into a page in the first place.

[jameskoster]

Yup, I do appreciate that outside of the context of a given flow, different behaviors on a single button can seem unpredictable, and that may be something to avoid.

But I do think the OP is a legitimate issue as well. If you click into a Page details panel from the Navigation panel, it's super-frustrating that in order to get back to the origin you have to drill up and out of Pages then back down into Navigation. That's at least three clicks (four if you have multiple menus) when only one should be necessary.

If adding logic to the < is out of the question, then we might need to consider adding a different element that offers a way back when you diverge from the canonical path. Perhaps something similar to the back-to-app button in iOS:

[youknowriad]

If adding logic to the < is out of the question, then we might need to consider adding a different element that offers a way back when you diverge from the canonical path. Perhaps something similar to the back-to-app button in iOS:

Just playing the devil's advocate here. Isn't this the "back" button in the browser?

---

For clarity, if we were to introduce a different behavior for the back button depending on where we came from, I think we should also add the "label" next to the back button like you suggested initially.

[SaxonF]

If adding logic to the < is out of the question, then we might need to consider adding a different element that offers a way back when you diverge from the canonical path.

We've explored breadcrumbs in the past (including for inspector). They would help to reinforce the IA whilst letting the back arrow feel more like going back to where you came from.

We can be more explicit with the back action by adding a label if coming from a place that isn't the parent.

We could even remove the back action and rely purely on breadcrumbs when traversing down IA in the natural order. Side effect of it helps with visual alignment as well.

[draganescu]

I am supporting the approach @jameskoster describes where the same button behaves differently depending on context. There is nothing wrong with that, context is everything :) And to the fact that the user may forget how they arrived at said place, then what the back button does is irrelevant. What we care about are those who do remember what they did up to the point where they want to go back and we need to make back conform to the expectations the context created by their minds.

[jameskoster]

Just playing the devil's advocate here. Isn't this the "back" button in the browser?

It is, but since the browser back button and the < share behavior most of the time, the expectation is that it would do so in flows like Navigation menu > Page details as well. But it doesn't. That is the issue in a nutshell.

For clarity, if we were to introduce a different behavior for the back button depending on where we came from, I think we should also add the "label" next to the back button like you suggested initially.

Perhaps this is worth a try initially?

Edit: For an even smaller change, could we try keeping the button display as is, adding the conditional logic, and add the destination to the tooltip? "Back to Pages".

---

Breadcrumbs are another option like @SaxonF suggests. I like how they hint at the site icon button behavior (which currently feels a bit mysterious), and enable you jump to specific levels directly. But we always ran into issues with scaling when exploring them before. How would something like Design > Navigation > Menu name > Page title fit?

We can be more explicit with the back action by adding a label if coming from a place that isn't the parent.

If the < Label appeared situationally (like the back to app in iOS) that might work. Otherwise isn't it going to be duplicative with the breadcrumb most of the time?

[SaxonF]

If the < Label appeared situationally (like the back to app in iOS) that might work. Otherwise isn't it going to be duplicative with the breadcrumb most of the time?

Yeah we can just make it appear when you're coming from a place that isn't the parent of the page. Would look like the last mockup.

How would something like Design > Navigation > Menu name > Page title fit?

Similar to Notion

notion-breadcrumbs.mp4

In saying that, I agree that starting with changing the back button to just go back is worth a try initially. Can change tooltip/label of where you're about to go.

[jameskoster]

In saying that, I agree that starting with changing the back button to just go back is worth a try initially. Can change tooltip/label of where you're about to go

+1. We came to the same conclusion in a huddle yesterday.

[richtabor]

If you open a URL such as mysite.com/wp-admin/site-editor.php?postType=page&postId=xxxx to view page details.
Here the canonical parent makes sense to me. IE < takes you from Page details to Pages list panel.

Clicking a Page in the Navigation panel which takes you to Design > Pages list > Single Page details.
In these cases the canonical parent should probably be overridden. So in the first example, clicking < on the Single Page details would return you to Navigation instead of Pages list.

These flows sound good to me.

If you're coming from Nav, you should go back to Nav. If you're coming from Pages, you go back to Pages, If you've landed via URL, you should go back to Pages.

[annezazu]

To move this forward and make it ready for dev, we need to move forward with this:

If the panel is 'opened' from a non-canonical referrer, (e.g. clicking 404 in the Pages panel), then the back button should return you to that referrer instead.

This pulls from Jay's larger issue here #51421 and would solve what's noted here as a buggy experience. Adding the needs dev label and adding to "to do" for 6.3 tasks.

[noisysocks]

I started hacking on this in try/make-sidebar-back-button-go-back. Will continue and maybe open a PR tomorrow.

[jameskoster]

At @noisysocks request to consolidate discussion, I just wanted to note the flows in which this issue arises so we can be sure to cover them all:

• Navigation panel: click ellipsis, then "Go to [page]" (as described in the OP).
• In the Pages panel:
  • Click "Page: 404" or "Search results" in the sidebar.
  • Click "Blog Home" when the homepage is set to display latest posts.
  • Click the Posts page once Site Editor Pages: load the appropriate template if posts page set #52266 is merged.

I think that's all of them