When a web application uses XMLHttpRequest to retreive content for display to the user, no page load occurs, and therefore, the browser's Back button cannot be used to step backwards through the user's browsing history within the application. Much has been made of this Back button problem in Ajax applications. But I'm not convinced that it is anything to worry about.
Maybe usability testers who have worked with Ajax applications can tell me otherwise, but it just doesn't seem that confusing to me. When I zoom a map in Google maps, for exmaple, I simply don't expect the Back button to unzoom it. If I've just clicked the "+" button to increase the magnification of the map, why would I expect a button named "Back" to decrease the magnification? I'm zooming in and out, not back and forward...
One small insight I've had about thi s is that the browser's Back and Forward buttons are not, and should not be, Undo and Redo buttons for web applications. I expect that all but the most inexperienced users have internalized this distinction. Or they will, unless the designers of Ajax applications insist on making Back work like an undo function within their application.
As a corollary, allow me to suggest that wizard-style interactions, with "Next" and "Previous" buttons are not well suited to Ajax applications. Next and Previous are uncomfortably close to Forward and Back, and I think that users of such an application will (and should) reasonably expect that the browser's Back button will perform the same action as the wizard's Previous button. So if you're going for a wizard-style user-interface, skip the Ajax and just do plain old form submissions and page loads so that browser history works okay...
Other than that, I don't think we need to worry about the Back button. But take this advice with a grain of salt. I've performed absolutely no testing with real-world users.
I think you are fighting an uphill battle if you expect Joe user to distinguish between back and undo. The best you can hope for is that when they reach for the back button they remember that it messes up due to some bug with the website.
For some operations the back button works in google maps. For others it doesn't. At the moment I have backed onto a page showing Cambridge, MA with nothing marked, even though the search bar has been automatically repopulated with "cambridge ma bar".
It confuses me. What a mess.
Actually, if you use a web framework that utilizes continuations for the control flow, the back button works exactly like an undo button. It's quite user-friendly and doesn't break your app since your app has the notion of a "previous step" in your controller.
Tom:
I hope it is not an uphill battle. But it doesn't sound like either of us actually has any data about "Joe user"...
Tony: maybe you misunderstand my point. I'm arguing that the Back button should not be used as an Undo button, even if certain architectures make it easy... If your web application is (or appears to be) a series of distinct pages, then the Back button ought to navigate among those pages. But if you're writing a Ajax application like Google maps, I think that the Back button should *not* serve as a general undo feature.
Speaking as someone who has done user testing for Web applications (albeit not Ajax ones), I am constantly surprised at how many users actually do consider the Back button as an "undo". From what I've seen, whenever a user gets confused about what's going on, their first instinct is to hit the Back button to get back to a place that they are comfortable with. As a Web application engineer, I find this extremely frustrating, but we really have to keep in mind the "non-power users" when dealing with these issues.
I don't buy it. The example of zooming is a unique situation. It deals with manipulating something that's there. Nothing goes away, nothing new comes.
Intuitively, the browser's Back and Forward buttons seem equivalent to turning a page in a book. Zooming would be in the category of writing/drawing on a page ? or erasing or editing. If the substance of the page changes, it's like turning the page.
The other factor seems to be how handy the navigation tools within the page are. To continue with Flanagan's limited example, if the minus sign is close to the plus sign, I wouldn't think about the Back button. In an Image Navigator we use on several of our sites, the thumbnail images and the Next and Previous are all handy and the scope of their effect is clear. But even here, if the user's attention wanders, or if they get up from their desk and return later, the back button's allure returns.
Thanks for your thoughts, Alan.
Image zooming might be unique for now, but I've got a feeling that "web 2.0" might bring us many analogous situations... Nothing I can cite as evidence, however,
Your book analogy is a nice one. And your point is consistent with mine. If a web application does the equivalent of displaying a new page, then the Back button should take the user back to the previous page.
But if a web application performs an action that is some kind of interaction with the current page, the Back button should not undo that action. The developer may want to provide an "undo" feature to undo interactions on the current page, but (and this is my main point) the Back button should not be pressed into service to do this.
I wrote the original post because I think some of the worry over the back button is over done. Folks are figuring out ugly hacks to make the back button function in Ajax applications. After all the work of getting it to work, I fear that the temptation will be to overuse it, turning the Back button into a kind of universal undo button.
In any case, the hard part is figuring out the in-between cases. If a web app uses Ajax and DOM scripting to replace the rows of a table with a new set of data from a database query, should the Back button go back to the last set of rows, or should it go back a whole page?
David, I came across your post a couple of days ago and was interested to see your viewpoint and comments. Like you I don't think the "back-button problem" is such a big deal, though I'm surprised there haven't been more comments to your post, based on some of the hand-wringing I've seen on the web over this issue.
I've taken an approach to Ajax apps that sidesteps the issue for the most part, based on my desire for the app to look and feel as much like a desktop app as possible. Consider that when you open a desktop app, it opens in a new window, not in the same window as the one you're currently using. Likewise when you open a document in Word or Excel, the document opens in its own window. So when a user clicks a link to open my Ajax app, the app opens in a new browser window without a toolbar. The app is a typical, self-contained set of functionality that includes a menu for navigation, queries, lists, and single-record displays and updates. When the user is through with the app, she clicks Exit in the menu, and the window closes. Obviously I can't prevent the user from selecting a bookmark to navigate away from the app, but it feels so much like a desktop app, I haven't heard of a single user trying to do that.
I agree that the Back button should not be an Undo button in an Ajax app. My experience agrees with Nicholas that a lot of users try to use Back for Undo, but that has been in the context of pre-Ajax apps where each program state is represented by a page load. I speculate that if you design your Ajax app to be self-contained, and that if Undo is a feature you need and you implement it reasonably, this user behavior will disappear. (What a dreamer, huh?!)
I do think it would be nice if the browsing environment and the application environment were clearly distinguished, so that when you clicked a link for an Ajax app in a browser window, the app would open as a widget in a Mac Dashboard-like context. I hope we'll be there before too long.
David, I came across your post a couple of days ago and was interested to see your viewpoint and comments. Like you I don't think the "back-button problem" is such a big deal, though I'm surprised there haven't been more comments to your post, based on some of the hand-wringing I've seen on the web over this issue.
I've taken an approach to Ajax apps that sidesteps the issue for the most part, based on my desire for the app to look and feel as much like a desktop app as possible. Consider that when you open a desktop app, it opens in a new window, not in the same window as the one you're currently using. Likewise when you open a document in Word or Excel, the document opens in its own window. So when a user clicks a link to open my Ajax app, the app opens in a new browser window without a toolbar. The app is a typical, self-contained set of functionality that includes a menu for navigation, queries, lists, and single-record displays and updates. When the user is through with the app, she clicks Exit in the menu, and the window closes. Obviously I can't prevent the user from selecting a bookmark to navigate away from the app, but it feels so much like a desktop app, I haven't heard of a single user trying to do that.
I agree that the Back button should not be an Undo button in an Ajax app. My experience agrees with Nicholas that a lot of users try to use Back for Undo, but that has been in the context of pre-Ajax apps where each program state is represented by a page load. I speculate that if you design your Ajax app to be self-contained, and that if Undo is a feature you need and you implement it reasonably, this user behavior will disappear. (What a dreamer, huh?!)
I do think it would be nice if the browsing environment and the application environment were clearly distinguished, so that when you clicked a link for an Ajax app in a browser window, the app would open as a widget in a Mac Dashboard-like context. I hope we'll be there before too long.
Sorry for the double post. The first attempt returned an error, so I tried again.