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.