Problem: I have a situation where in a browser-based web application the back button (and backspace key for that matter) cannot be supported or used. If it is used, the results can be unpredictable in terms of navigation, taking the user not to their last step to the last URL in the web app (there could be several steps performed within a shell in the UI that does not change the URL). Furthermore, data may be lost. Providing a special chrome or wrapper to hide the back button in the browser is not an option (the user could also use the backspace key which in most platforms and browsers is mapped to the back button).

However, it is completely reasonable that users would want to navigate using the browser back button and expect that it works.

Solution options: What is the optimal UX in this situation? I am thinking that on back button use a warning dialog is thrown saying that the back button is not supported and to navigate using provided previous or next buttons or other affordances in the UI, and to complete tasks without using the back button. Furthermore If used, data could be lost and the navigation may be "unexpected" (not sure how to phrase this elegantly). Perhaps some user assistance on first run would tell users not to use the back button too.

Any opinions on insight on how this limitation (due to JSF architecture by design outside my control) can be elegantly handled? I am of the opinion this is a bug, but it would be better to convey the interaction as warning from a UX perspective rather than an error message.

Anyone got elegant phraseology on how to compose that warning or assist users gently in the right direction?

3 Answers 3


Other than the obvious answer: "re-write your app so it supports common user actions better" You could try manipulating the browser history using new development techniques (usually outside the scope of a UX answer). Otherwise, a JavaScript alert will only fire after the users have tried to leave the page for any reason, which might be confusing to them. There is no great solution I can think of other than that. Any alerts and warning text are going to be unreliably read by users.

  • 2
    +1 for History API; however, the best solution is of course to avoid breaking the back button in the first place.
    – Lie Ryan
    Apr 30, 2013 at 17:27
  • True, we may need to "whitelist" some actions and avoid false positives with the JavaScript alert. Broken back button is a given unfortunately.
    – uobroin
    Apr 30, 2013 at 20:24
  • My gut feeling is: this question could digress into software development space pretty easily. The only real UX answer I can provide is "change the application circumstances so it does not appear broken to users through any means necessary".
    – sirtimbly
    Apr 30, 2013 at 20:27

Typically in this situation applications will present a dialog that looks something like this:


download bmml source – Wireframes created with Balsamiq Mockups

This is in line with your intuition that a warning that "going back" is unsupported behavior is the best UX to provide in this situation.

Note that it may be possible to support the back button behavior using things like HTML5 browser state (and libraries like https://github.com/browserstate/history.js), but since this would be a technical change, it falls outside the scope of your question.


Since to go back the user must drag the cursor to the back button why not place a red tooltip there (I guess this is what you are suggesting in the question itself). Something like this


download bmml source – Wireframes created with Balsamiq Mockups

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.