PWAs have their own back button (in html) and navigation, It is often different from history, and represents a hierarchical structure of content.
It would greatly improve the UX if we could set the OS back button on mobile (and maybe the browser back button on desktop) to the same value as the inner website navigation.
You can, using history.pushState() and handling the popstate event as a back button press.
(IMO this API is messy and hard to get right though - what would be much easier for PWAs is just an onback callback that fires when back is pressed.)
I know about that, but it is really a mess, complex and with many caveats. Settings the back url in a hierarchical navigation would be extremely easy and error proof.
Do you think a simple onback callback would help in your case as well?
Yes, it would be perfect if it allows you to decide the destination URL. Basically I want to sync the behavior of my custom back button (in the PWA top nav) with the OS navigation.
Custom back buttons are an absolute anti-pattern. Their only tolerable function is history.back().
That being said, when you say “hierarchical structure of content”, it sounds as if you really mean an app-static previous item as in rel=prev or parent as in rel=up and not a use-dynamic back state.
Users expect the ‘back’ button to be able to close <dialog> elements and other similar app-like functionality in web apps. To me that seems to be a reasonable way to meet user expectations, not an anti-pattern. However we have to put up with the messy history API to do that.
They’re not an anti-pattern, it’s what an average user expects. A user doesn’t expect that clicking the back arrow inside the HTML or the back arrow provided by the mobile OS gives him different results.
Think to apps like Whatsapp or Gmail: you expect that back always beings you to the global listing of emails / conversations if you are on a specific one. And that is indeed what happens:
So this is the proof that it is not an anti-pattern, and that it is widely used in native apps.
Users do expect that any back button takes them “back”, indeed. What exactly they consider “back” may differ (usually their previous view, i. e. the appʼs previous state, which may involve “closing” active dialogs) and it may differ from the authorʼs idea of “back”. Users are always confused if there are two back buttons (or any other duplicate control) and they are even more confused if those work differently. So, Iʼm in total agreement with:
A user doesn’t expect that clicking the back arrow inside the HTML or the back arrow provided by the mobile OS gives him different results.
and the way to fix this is either not providing any “back arrow inside the HTML” or making its only ever action history.back(). Thatʼs simply the other way around from:
It would greatly improve the UX if we could set the OS back button (…) to the same value as the inner website navigation.
As has been said, if you cannot be RESTful for some reason, there is already an API (pushState(), replaceState()) to add PWA views or states to the browser history – actually there are two, the other being window.location.
If you are actually talking about previous / next relationships, like I mentioned, then you are really asking for new browser UI controls (which I would support). Opera and early Firefox used to support rel link relations that way.
That is the correct way to build PWAs: they must always show a back button and it does not represent history… If you are still not sure please read this:
So, saying that the back button in a PWA should always trigger back is wrong.
Example:
We may actually have a whole bunch of “back” actions, which must be coordinated and should not mismatch:
From the article, emphasis added:
Some might argue that because Android provides a back button through the device itself, then there is no need to replace the browser’s back functionality. In fact, the two interactions do different things. Most apps continue to offer a back button in the header as an “up” action, to navigate within the hierarchical relationship between pages. The system’s back functionality might close a modal window or navigate to a different app entirely.
You are indeed talking about rel hierarchies, which are still underdeveloped in HTML (whereof prev does not really apply here), despite early attempts for standardization, which explicitly reserved back for browser history. So please use a different, unambiguous term, e. g. return.
After some months of observation of real people using our PWA I can say with confidence that, for non-tech users, having an in-app navigation (with hierarchy) different from the native back button is really confusing.
It would be extremely useful and simple for an app to manage the back event directly, for example, in order to build a hierarchical navigation.
The browser history API is difficult to use for hierarchical navigation, it’s not meant for that.
If we want to use the same patterns of native apps inside PWAs browsers should add support for this.
It’s really frustrating that we cannot match the back button in the app with the browser back button.
This is especially useful when you have a hierarchical / folder navigation.
You don’t want the back button of the browser to go back in history to an edit screen for example… You just want to go back / up in the hierarchy. That is what a user expects and this is not currently possible on the web.
What about when a user is linked into your app from somewhere else? The back button should go back there, not to another page in your app.
It’s not a big deal… It’s already the same for native apps and if we want to move the web forward we need the same capabilities (otherwise the user experience for native apps will be always superior for the average user).
For example:
However this is not a problem for the average user because if you click again Back then you go back to the original page containing the link.
If you really want more control you can, for example, allow the web app to set the back URL only to a URL that has already been visited, otherwise you simply ignore the back URL suggestion.
This is a possible implementation:
window.ongoback = function() {
// find the previous URL based on app logic, navigation or hierarchy
// and return the hint to the browser
var back = "/back/to/this/page"
return back;
};
Then the browser goes back in the history up to that page (if it’s not found then the browser can ignore the hint).This would be extremely simple, powerful and secure (even more than the current history api).
Why not just use history.replaceState to overwrite history items you don’t want rather than adding a way to skip over them?
That is made to solve different use cases.
If you are curious about what I mean when I say “hierarchical navigation” based on app logic, you can try to create a (free) menu with our app: https://buonmenu.com When you are inside the admin area you will see that the “hierarchical navigation” (menus → categories → items → edit) is a concept not easily manageable using the history api.
You can also browse native apps like Instagram and you will notice that the OS back button always match the in-app back button!
In these native apps the back button does not match the navigation history! Instead, it matches the navigation hierarchy (e.g. think to that as a back in a breadcrumb navigation).
As I explained above we could achieve the same for the web and greatly improve the UX for web apps, without any security concern. So why not give this option to developers and UX designers?
Reading posts like the following (with 500k+ views) make me think that the browser back button, in the current state, is something legacy that causes several issues to modern apps:
My proposal would solve all these use cases with simplicity, interoperability and security.