17

I've read the advice, "don't break the back button" from multiple sources. For content-based browsing I agree with this 100%. Does the same advice apply to web applications? I feel that it is still valid for web-app pages that simply display data. Once posting forms, AJAX, and logged out sessions become involved, the back button might result in unexpected behavior.

Is this advice relevant for a highly-interactive web application?

Here are some articles that speak to this topic:
http://w3.org/QA/Tips/reback
http://brightorangethread.com/blog/view/dont-break-the-back-button
http://nngroup.com/articles/the-top-ten-web-design-mistakes-of-1999

Improve this question
6
  • 1
    I won't venture an answer on this somewhat controversial topic, but I will suggest that you can't break that which isn't working. The back button arguably already doesn't work in many situations in a web application, some of which have been mentioned on this page, e.g. after a POST. If there's no well-defined behavior that a user expects and which normally works, I don't think it's worth bending over backwards to fix the back button, especially since your fix will not be universal or expected.
    – LarsH
    Commented Jul 18, 2013 at 20:32
  • 5
    I was under the impression that AJAX-heavy web applications which tend to break the users' expectations of how a browser works were why "Don't break the back button" was coined in the first place.
    – Garrett Albright
    Commented Jul 19, 2013 at 7:27
  • 1
    The back button should always work for navigation but in an app extra care needs to be taken that it doesn't undo/redo or repeat state changes.
    – JamesRyan
    Commented Jul 19, 2013 at 10:43
  • Once I pressed back button and knocked the site down..
    – YankeeWhiskey
    Commented Jul 19, 2013 at 12:44
  • The problem with this question is, what is the difference between a web site and web application? Is there a difference? There is a huge grey area between completely static pages and a single, completely dynamic page.
    – DisgruntledGoat
    Commented Jul 19, 2013 at 13:14

5 Answers 5

Reset to default
29

Yes it is. I'm not sure exactly what you mean by unexpected behavior, but users expect the same thing from a back button, whether they are using an application or a regular website. Think of it this way: the back button is part of the browser, out side of your website. It should perform the same way no matter the content being viewed.

If you are designing a web application, the navigation should hopefully work so that the user doesn't need to hit the back button, but when they do, it brings them back to the previous page/state they were at.

Improve this answer
3
  • 1
    +1. Yes, without a doubt it's important to keep the back button working even in ajax style apps.
    – obelia
    Commented Jul 18, 2013 at 16:30
  • One type of unexpected behavior is on-page-load AJAX for content or logging. Sometimes it'll fire if you hit "back" to that page, sometimes not (if the page was cached). Others include trickery with the History object or (for older browsers) involving a #hash in the URL.
    – Izkata
    Commented Jul 18, 2013 at 17:06
  • AmishProgrammer's link in the comments has other examples as well. POSTing to a page is another bad one (hinted at in the question), where hitting "back" will cause the browser to ask if you want to re-send the data. The page becomes inaccessible if you don't, or even if you do the action might not be repeatable (like removing something from a shopping cart).
    – Izkata
    Commented Jul 18, 2013 at 17:08
5

Yes, yes, yes. Breaking the back button is not just a problem, it's a symptom of a massive design and engineering flaw. If your application breaks the back button, it does't follow RESTful design. that means that bookmarks won't work, that emailing links to someone won't work. It means that business search can't index the application. There are a thousand things that will go wrong with your application if you don't follow REST, and many of them are UX problems.

A final point is that your application is not degrading gracefully. If you build your application on top of vanilla HTML forms, adding UX features only by javascript, you benefit on many points. Your webdesigner and backend programmers can test their stuff separately and don't have to learn about each other's tools. If javascript isn't available (search engines, handicapped people), the application still functions.

In short, don't underestimate the importance of this issue.

Improve this answer
2
  • I am feeling exactly the same way that you express here. But where is the backing literature on this? Is there an organized list of the things that will be wrong? My company keeps investing in more flash-based SaaS application which have no respect for REST -- but they look visually good and that is what the purchasing managers buy. Can you help list resources explaining why these applications are poor usability?
    – AgilePro
    Commented May 15, 2014 at 23:51
  • I don't have any to hand (I could google, but you've probably done that already). It might be worth a fresh question.
    – Peter
    Commented May 16, 2014 at 12:46
3

Good Question. The difference lies in General Usability Guidelines vs new navigation models found in App Guidelines.

If your web app acts and feels like a native app (like forecast.io) I might defer to the App guidelines. If not, stick with the general usability guidelines to not the break the back button.

Apple HIG guidelines that states "When navigating through a hierarchy of information, users tap the back button to the left of the title to return to the previous screen. Otherwise, users can tap content-specific controls in the navigation bar to manage the contents of the screen."

See under navigation bar http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/UIElementGuidelines/UIElementGuidelines.html#//apple_ref/doc/uid///apple_ref/doc/uid/TP40006556-CH13-SW5

See also Andriod's App Guidelines which compounds the issue with the presence of its own system back button: http://developer.android.com/design/patterns/navigation.html

Improve this answer
2

As always, you'll get the best answer by watching your users using your applications. But in my experience, yes, users still expect the back button to work in web applications.

The past two companies I've worked for have been large corporations who have invested heavily in their own web app framework for writing both internal and customer-facing web applications. Both the framework and many of the applications (primarily system administration/dashboard type apps, with some but not predominantly AJAX-type content) were heavily usability tested, and a significant percentage of users were always frustrated if the Back button didn't work sensibly.

If we hid the Back button, some users would know how to turn it back on and do so. And if an application had its own Back button on the page, or a breadcrumb trail that allowed backward navigation, then if anything users took that as a sign that the Back button ought to work and used it more often.

Improve this answer
1

The general rule is to always give the user what is expecting, so the element has to behave in the same manner as in other sites.

However, you can overcome this problem by testing with users and looking to their behaviors.

I think that a great way to look for alternatives in highly-interactive web application is to check how the button works in grooveshark.com, trello.com, or asana.com.

Improve this answer

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.