The Problem

The foundation of the web has been the hyperlink from one page to another. The links between pages have been primarily bi-directional, in the sense that visiting page A and then clicking on a link to page B would in no way prevent the user from either following a link back to page A or clicking the back button to get there. The chain of pages represented in the browser history each have a unique URL associated with them. In code we might store these URLs as a stack. For the sake of discussion, I’ll refer to the link between the nodes in the stack as being horizontal.

Ajax pages build on the concept of horizontal links, and extend it by introducing what I’ll call the “vertical” link. Vertical links are links to new information displayed on the current page but accessed behind the scenes via an XMLHttpRequest. In other words, you get new content on the screen but the URL doesn’t change in the browser. Since these vertical links don’t cause the URL to change, a new node isn’t added to the history stack. As a result, when the user hits their back button they will be taken to the previous horizontal resource which may not necessarily contain the last piece of information that appeared on their screen.

Web Site vs. Web Application

The approach you take to solving this problem may depend on whether you’re developing a web site or a web application. Sometimes it can be difficult to distinguish the difference between the two, but typically web applications will exhibit the following:

  
• Authentication before use
• Heavy session tracking
• A process flow with a defined beginning and end

For example, I consider Yahoo! Finance to be a web site while E*TRADE is a web application. From the user’s perspective I’ll admit that it’s not always easy to differentiate between the two. However, developers should know from the very beginning whether they’re creating a web site or a web application. If you’re having trouble figuring this out, ask yourself this: If the Internet didn’t exist would your project be better suited as a series of Word documents or as a desktop application? Think of web applications as desktop applications that just so happen to require a browser to be accessed. Another way of asking this would be to say, “Is your main goal to present information or to provide functionality?”

Solution #1: Go Light on the Vertical Links

If you are building a publicly accessible web site, my advice is to use Ajax in such a way that it does not overuse vertical links. This may require URL changes that refresh the entire page, but I think that the sanctity of the back button is worth preserving. Also, keep in mind that not all uses of Ajax are heavy on the vertical linking.

Although it is easier to justify breaking the back button in web applications, it should still be done sparingly. Rather than building an entire application that consists of numerous vertical links all hosted at the same URL, create horizontal links to new URLs at meaningful times. In other words, use horizontal links to separate portions of your application in the same way that chapters are used to separate portions of a book. By using a combination of traditional horizontal links along with Ajax vertical links you’re more likely to strike a balance with the benefits of Ajax sans the back button drawbacks.

Solution #2: Use an Ajax History Library

A handful of open source JavaScript libraries have been created with the express purpose of solving the back button problem. Most of these libraries make use of anchor targets (preceded by a ‘#’ hash) in the URL. The end result is a vertical link that changes the URL as if it were a horizontal one, but does not cause the page to reload. Although these libraries add an extra layer of complexity to each page that uses them, they are also fairly easy to use.

• The Mike Stenhouse approach. - A pretty simple solution that works in most, but not all browsers. Demo his code in action and watch what happens to the URL as you click the links on the side.
• Really Simple History - Created by Brad Neuberg, this library strives to be complete without being complex. Better yet, it’s available under a BSD open source license. Brad’s created a walk-through of his code as well as an online demo.
• Plex - Plex is an open source Ajax framework that supports many features, including back button support.
• Dojo - Dojo is another open source Ajax toolkit that supports a number of Ajax functionality, including support for the back button.

Solution #3: Provide a Useful Alternative and Educate Your Users

Traditionally, the use of the back button has implied “Take me back from whence I came.” However, with web applications, many users hit the back button thinking, “Undo what I just did.” To eliminate their temptation to misuse the back button, create “Undo” or “Step Back” functionality in your Ajax enabled web applications. For example, if you’re building a web-based rich text editor, providing an “Undo” option would prevent the user from accidentally losing their entire document by pressing the back button instead.

The worst thing I’ve ever seen on a web site using Ajax was the recreation of the back button in HTML within the page itself. Many users have a hard time distinguishing the difference between where the browser ends and where the web page begins. There’s no need to add to this confusion. Even for the users who “get it”, you can’t expect them to change their habits just for you. It’s okay to provide a useful alternative to the back button, but don’t recreate it.

Finally, when breaking the back button in a web application is an absolute must, have the courtesy to inform your users of this up front. Ajax isn’t the first web technique to break the back button and this probably won’t be the first time your users will have heard this before. (Think Applets, Flash and even eCommerce applications that double charged credit cards when the back button was used.) The amount of responsibility you ultimately place on the user will depend on your corporate culture, but it’s not unreasonable to expect them to bear a little of the load.