Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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

share|improve this question
    
could you supply the links to the articles? –  Igor-G Jul 18 '13 at 14:39
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 Jul 18 '13 at 20:32
2  
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 Jul 19 '13 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 Jul 19 '13 at 10:43
    
Once I pressed back button and knocked the site down.. –  YankeeWhiskey Jul 19 '13 at 12:44
show 1 more comment

5 Answers

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.

share|improve this answer
1  
+1. Yes, without a doubt it's important to keep the back button working even in ajax style apps. –  obelia Jul 18 '13 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 Jul 18 '13 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 Jul 18 '13 at 17:08
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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