Wp-calypso: Plugins: Change 'Back' target in HeaderCake

[ockham]

As reported by @ice9js here (and by @beaulebens in Slack). (Note that _this_ issue is about the specific 'Back' button in the single plugin view, not the broader case of _all_ Back buttons found in HeaderCakes, even if some of the previous discussion quoted herein is for the broader case.)

Also, we should perhaps adjust the back button on the plugin details page so it always redirects to the plugins overview.
Right now you can get caught in an endless loop between plugin details and settings by pressing the back buttons.

@folletto:

Actually: can we remove window.history.back(); (ref) from the component? I see the issue with back coming up constantly, and in general we should avoid completely to use window.history.back() on the UI itself. If the user wants to do it they just click back with the browser. The back in the component should be a RELIABLE piece of the interface leading always to an explicit page.

Myself:

I agree in principle. However, this might mean scanning thru all uses of the component in order to ensure the desired behavior still works.

FWIW, the relevant code is in https://github.com/Automattic/wp-calypso/blob/fc6ff288a75866bd8d67aae585b034aeed0dbbe0/client/my-sites/plugins/plugin.jsx#L159 It's unfortunately quite complex, too. Seems like this complex logic was introduced by 10816-gh-calypso-pre-oss.

[ockham]

The original intent of this logic, as evidenced by 10816-gh-calypso-pre-oss, is: Trying to make sure that the 'Back' button correctly points to either /plugins/<plugin>/ or /plugins/browse/<plugin>, respectively (with /<siteSlug> and ?query=args appended as necessary).

This is a somewhat tricky UX design issue, since neither seems to be more "canonical" than the other (so there's a point to _not_ directing a user arriving from /plugins/browse "back" to /plugins); and it still raises the question where to redirect a user that has arrived from an entirely different location. Pinging UX gurus @rickybanister and @folletto for advice.

[folletto]

For me "back" isn't a matter of flow but a matter of hierarchy (and well, we should avoid "Back" as a label for that reason, if it's not super obvious by the context). Back should behave as "Up one level", as such the above is a matter of: where does that page exist in the information architecture of Calypso? Once that's defined, back will change label to whatever the parent page is, and it should lead there.

In a way, it's not different on how Themes handle individual themes, and its "back" — which in fact isn't "Back" but "All Themes" for this reason.

I'm not 100% sure what happens in the code there. It seems it's not using window.history.back(), but some other form of conditional based on a passed parameter lastPluginsListVisited (and getPathWithoutSiteSlug()) which might be too generic thus accepting any kind of path instead of forcing /plugins? Probably that whole logic requires some refactoring.

[ockham]

Probably that whole logic requires some refactoring.

I'm pretty sure it does, but I think it was mostly to handle the two original locations I mentioned, /plugins, and /plugins/browse (the rest is unwanted side effects).

As for those two, I'd say that there currently isn't a perfectly hierarchical relation, i.e. it's undefined which is the immediate "parent" of the single plugin view.

As for indication which _might_ be, I think you could be viewing info for a single plugin that isn't installed on _any_ of your sites, i.e. that won't be present in /plugins/, but only in /plugins/browse. Then again, for a non-WP.org plugin, the opposite could be true :man_shrugging:

[ockham]

Looping in @johnHackworth who's the original author of 10816-gh-calypso-pre-oss. Can we make the relation between plugin views more hierarchical?

[folletto]

Yes, I agree. My mention was mostly to emphasize to find a solution in the scope of "hierarchy" and not "sequence". :)

Just to clarify: I was speaking in general on the "back" logic across Calypso, using the plugins case as an example.

Speaking specifically on Plugins is a more complex situation as you mention. In the distinction between these two URLs specifically I think we can still preserve a logic — which is similar to just preserving a query parameter in a search when we do "browse back". It's not exactly the same, but that's probably a manageable exception here. Probably "just" require some cleanup to make the code side of things more reliable and easier to read, the general logic of switching depending on context between /plugins and /plugins/browse seem rational to me here.

[ockham]

Just to clarify: I was speaking in general on the "back" logic across Calypso, using the plugins case as an example.

Oh right, I should've made more clear that this issue was only meant to cover the single plugin view. (I've added a note to the PR desc now.)

[ockham]

Speaking specifically on Plugins is a more complex situation as you mention. In the distinction between these two URLs specifically I think we can still preserve a logic — which is similar to just preserving a query parameter in a search when we do "browse back". It's not exactly the same, but that's probably a manageable exception here. Probably "just" require some cleanup to make the code side of things more reliable and easier to read, the general logic of switching depending on context between /plugins and /plugins/browse seem rational to me here.

Okay, thanks for making that clear. There's still one case to cover -- what if we're coming from an entirely different location? (Relevant here for extensions.)

[folletto]

what if we're coming from an entirely different location? (Relevant here for extensions.)

Can you explain with an example?

[ockham]

Can you explain with an example?

That's the original issue reported here:
The extension view (i.e. an _individual_ plugin's actual UI, such as /extensions/wp-super-cache/<JPsite> in case of WP Super Cache) has a HeaderCake with a 'Back' link (titled 'Plugin Overview') there that always points to /plugins/<plugin>/<JPsite>. So if you click that and land on the single plugin view, you're presented with the 'Back' button -- but since you didn't arrive from /plugins/ or /plugins/browse, it falls back to browser-history-back, taking you back to the _extension_. Repeat infinitely.

[folletto]

Given the flow to get to settings currently is:

• Plugins → $plugin-sheet → Edit plugin settings → $plugin-settings

Which means this URL sequence:

• /plugins/$site → /plugins/$plugin/$site → /extensions/$plugin/$site

The "Back" functionality should simply go back to /plugins/$plugin/$site and up again to /plugins/$site.

It seems an issue related to the refactoring we both mentioned above: once we make it less generic to not accept ANY url, but makes sure that the root path is /plugins and the other pieces are parameters, with probably a fallback /plugins as a default, it should solve both the issues (proper hierarchy AND bug fixing the loop).

...or maybe I'm missing something. :)

[ockham]

Given the flow to get to settings currently is:

• Plugins → $plugin-sheet → Edit plugin settings → $plugin-settings

Which means this URL sequence:

• /plugins/$site → /plugins/$plugin/$site → /extensions/$plugin/$site

The "Back" functionality should simply go back to /plugins/$plugin/$site and up again to /plugins/$site.

I think most of us ran into the infinite loop situation by landing on /extensions/$plugin/$site from a different location -- or landing there cold, e.g. via a bookmark:

/extensions/$plugin/$site → Plugin Overview → /plugins/$plugin/$site → Back → ?

Currently, the answer is /extensions/$plugin/$site (from browser history), but that causes the infinite loop.

Should the answer instead be /plugins/$site? (Or /plugins/browse/$site? :-p )

[folletto]

Yes. Exactly. If we lock the "Back" to be less generic, we can use a logic such as:

1. /plugins/$plugin — always goes back to some variation of /plugins (where /browse is treated as an optional parameter as any other). Fallback to a default /plugins if nothing else is set.
2. /extensions/$plugin — always goes back to /plugins/$plugin (and parameter if any).

Also, the labels should be changed:

1. /plugins/$plugin — instead of "Back" we do "All Plugins" or just "Plugins" or similar.
2. /extensions/$plugin — instead of "Back" we do "Overview" or "Plugin Details" or similar.

Makes sense?

[ockham]

Makes sense?

I think so, yeah. Thanks!

[rickybanister]

I'm late to this party, but I totally agree with @folletto. Right now the extensions feel quite strange since you can click 'back' and end up in a kind of infinite loop between the plugin info screen and the plugin UI.

I had a thought about a UI that would put a 'toggle' in the upper right of the headercake so that you could jump between 'info' and 'settings' and 'back' would always be the plugin list, but I haven't rendered it yet.