"Back" behavior in rich web apps, true user assumption?

Question

Hello Community,

Many client side code libraries & tool kits, for example Yahoo's YUI and Google's GWT support managing state history for the user experience. When implemented it allows a user to revert to a previous app state on the same page when they click the Back button or Backspace key.

In this video from Google IO the implementation of this type of history management is strongly recommended and in fact assumed to be a part of rich web apps.

I see the value in such an approach but I'm not convinced it really supports the average user's expectations. In researching for this question on StackOverflow I found many rants from people about the evil of overriding "Back" functionality, couldn't it be argued that this approach falls into that category?

Personally I have been frustrated many times when "Back" merely changed the page state, when what I really wanted was to exit to my last browse location. For my usage the 99% use case for Back is not a state change, but a page change.

Finally, my real question is: How can we support history management for rich web apps without overriding "Back"?

Edit (best practice roundup):

• After reading Michael's blog post, I'm thinking now that for undo on non-link user control (dropdown, text fields etc.) i would rely on Control-Z and/or a button - a UI pattern that is widely supported.

• Back should revert at most the most coarse grained view changes the rich web app offers. It should emulate browser history by remembering only a single branch in the navigation tree: repeating back always leads to the root, and then the last page visited.

Answer 1

It depends on the state of the application that you are going back to. For example, in gmail, it's quite sensible that when I go from a message to my inbox, back takes me back to the message. In non-ajax webmail, this is what would have happened naturally.

But if clicking back took me through all the select and unselect actions I have done on the messages in my inbox, that would rapidly get annoying. So history management should be used if the change in page state is large enough to warrant it, but not if it's only a minor part of the page that has changed.

Answer 2

A "rich web application" has to be very careful about what the user would perceive as a "new page" and what would rather be taken as some action on a page. This perception of what a "page" is should then be reflected by the behaviour of the browsing history ("back" and "forward" buttons are just a way to interact with the browsing history).

Many "rich web applications" would better be simple HTML pages. In such applications, it is often obvious what a "page" is.

Other applications would better use a real client-server model: it should be possible to download the client just once, not for each new session. Such applications often do not have an obvious "page" model, so each user has his own idea what the "back" button should do. In such a situation, it would be good not even to present a "web-browser-like interface", in order not to raise false expectations. I believe that technologies like Java Web Start are a good base for such applications.

Answer 3

In my opinion page history and application state history are two totally different things. So we have two chaises: 1. We treat application as a web site - in this case Back (and Forward too) should work as if it was written in plain html. As gmail does as rjmunro mentioned. 2. We treat application as application (one page) - in this case Back button will bring you the the page before you app started. That's your 99%, right?

BWT, Backspace is the most annoying one.

Answer 4

Back should reverse the navigation done by a link, and nothing else. The user ties Back and links with navigation so going from linking to Backing is natural for them, as long as all links look like links to the user.

Specifically, the only good solution I see is for Back to take the user back an entire page in the browser. In other words, treat Back like it’s Close or Cancel (or just clicking on another window) in a thick-client app. This is consistent with my first paragraph, because users generally expect links to navigate an entire page. Therefore, Back should too.

You can’t have Back reverse every little input in a rich app because that will be very tedious when what the user wants to do is look at a page they were just on. Worse, it would imply the user has to undo all their work setting up a current page (maybe even entering input into text boxes and combo boxes) in order to see a previously seen page.

You can’t have Back revert some arbitrarily large change within a page (e.g., a tab selection) because that change is, well, arbitrary. The users won’t be able to predict when to use Back. They’ll be afraid to because it might revert much more than they wanted.

What web apps need is not a redefinition of Back or History, but an entirely independent Undo function, complete with its own Undo buffer, in order to deal with user input within a page.

I’ve all the gory details at http://www.zuschlogin.com/?p=41