The Back Button is Not an Undo Button

In the film Starman, Jenny (Karen Allen) and Starman (Jeff Bridges), an extra-terrestrial who has crash landed on Earth, road trip across the United States in Jenny’s Mustang while evading government agents. Starman offers to drive and explains to Jenny, “I watched you very carefully. Red light stop, green light go, yellow light go very fast.”

Much has been written about web applications, particularly AJAX applications, that ‘break’ the web browser’s back button. There’s more than one type of back button breakage but what is usually discussed in relation to AJAX is the ability (or un-ability) to use the back button to undo the application’s last action.

I think the concern is misguided. The back button is not an undo button.

The back and forward buttons are part of the model of the web as a repository of documents. They allow a user to move back or forward in the chain of visited hypertext nodes, i.e. web pages.

The ‘back as undo’ argument is often supported by a usability study that shows mere mortal users depend on using the back button as an undo. I think that’s a little bit like using a study that shows automobile drivers speed up on a yellow light to argue for swapping the meanings of green and yellow traffic signals.

I don’t think browser back button behavior is quite as important as road safety but I do think there is an impedance mismatch between the web browser as hypertext document platform and the web browser as application platform.

‘Undo’ is an application action. The back button doesn’t undo anything. It loads a previous page. Spackling over the difference is a bad idea.

Link: Hypertext and Application Workflow (or The Case for Single Node Apps).

Comments

[Eli]

Man, I couldn't disagree more.

So when you design a system, do you have to sit each user down first and explain the difference between hypertext document nodes and application states?

[Max Rabkin]

I'm not sure about anybody else, but when I say a webapp "breaks the back button" (mostly about Sakai), I mean "the back button doesn't take you back one page". In Sakai, the back button takes you back to the previous "section" (each module has sections, which contain multiple pages; there isn't really a way to go back to the previous page without navigating from the module's first page).

[Jonathan Dodds]

It's December 2007 and this post which I wrote back in May 2006 has found its way on to reddit. When I wrote this post I was reacting to something very specific which I didn't reference. If I were to rewrite this post today I'd make a number of changes.

I'd change the tone.

I would amend my argument by explaining that context matters. As an example go to Amazon, bring up an item, click 'add to shopping cart', and on the shopping cart page hit the back button. Do you expect Amazon to take the item out of your shopping cart? Does Amazon have a usability problem because the web site doesn't undo adding an item to the shopping cart on the back button?

I'm snide about a usability study but I don't explain that it's the usability study that I think is flawed not the users' conceptions. It goes back to that context thing. I think the average user is smart enough to understand context and doesn't rigidly expect that the back button should always undo.

Finally, I'd expand on an idea I only touch on at the end: treating the back button as an undo is a leaky abstraction.

[ModelMan]

Very strongly agree.
Back and undo is two different things.
Using back as undo just confuses users. Implementations tend to screw up the whole web behaviour, like using javascript magic, when a link is clicked. Alternative clients, like mobile devices won't work, google won't index the pages, etc. A simple and great system is turned upside down.

If your system needs undo function, you can just put an undo button on the UI. This way, it would be clear for the average user, what is 'back' and what is 'undo'.

[Dean Edwards]

What you think is irrelevant. The average user perceives the back button as an undo button and that's the end of the argument.