Rich web apps, a need for Undo, and rethinking what the Back button should be for and what it should do.

Much of the success of personal computers in general and the web in particular can attributed to the humble Back button prominently displayed in the upper left hand corner of all major browsers going back to Mosaic. Where most other browser controls remain a mystery to many users, everyone uses the Back button with such frequency that dedicated mouse buttons for the Back function are available (personally, I use a foot pedal). If that is any indication of a control’s criticality, then Back is up there with scrolling, which has also earned its own special control on the mouse, the scroll wheel. Basic web site usability guidelines warn of the folly of doing anything that interferes with the function of Back. It may be no exaggeration to say that the web would be unusable if this key function weren’t easy, visible, and standardized. Without Back, maybe we would never have seen the explosion in popularity of personal computers that accompanied the availability of the web.

However, the web has evolved to the point where Back as we know cannot go on. Web apps making use of AJAX and FLEX disrupt the Back function. In older times, when a new web technical capability threatened Back, Back won. The usage of frames, of Flash in place of ordinary links, and the spawning of new browser windows each saw their 15 minutes of popularity before being soundly dismissed as bad design in part because of their interference with Back. Today, web pages with these features are jokes among design professionals. They lost to Back because ultimately the Back functionality was more important than any capability they could add to the user experience.

Rich interactive apps using AJAX and FLEX are not so easy to dismiss. FLEX and AJAX also threaten Back functionality, but the advantages they bring in making interaction richer, faster, and more flexible can outweigh the concerns about Back. With much more at stake, it would be unacceptable to simply outlaw these technologies. Instead, we need find a way for Back-like functionality to coexist in a world of highly interactive apps. We need to ameliorate the impact of these technologies on the user experience, and make a transition to a new way of providing the same functionality. In saying goodbye to Back, at least as we know it now, I see ultimately an opportunity for superior functionality, not only for Back, but for desktop-style Undo functionality in general.

King Back Button

Functions of the Back Button

And just what is the functionality of Back? What goals does it satisfy for users that are so important? Back serves two purposes:

• Go away from content.
• Go towards content.

In going away from content, users are undoing a mistake. They clicked on a link on the previous page and found themselves on a page they don’t want. Whatever on the previous page made them think they wanted the new page apparently was misleading or it was simply a guess, so now they need to back out to the previous page and try again, perhaps with a different link. On a web site where the only action a user can do is select content via links, Back is the Undo functionality.

Back is also used to go towards content that had been previously visited. In this case the current page wasn’t accessed in error, but rather the user’s task involving the page is completed. The hierarchical information architecture common in web sites mandates a hierarchical structure to the users’ navigation history. Users move repeatedly back and forth between a superordinate page and successive subordinated pages, completing a subtask (reviewing some of the content necessary to complete the task) on each subordinate page. Back is used to navigate back to the superordinate page between subtasks. For example, when shopping online, users typically navigate back and forth between a gallery page and details pages, gathering information about potential purchases. Even when moving across sites, navigation paths often assume a hierarchical structure, such as when moving back and forth between individual sites and a search results page, news aggregator, or portal. Back punctuates the end of one subtask, and signals a return to a larger task scope. In a sense Back, is the equivalent of the OK button in a dialog box.

Advantages over Links

Clearly Undo and OK are essential functions, but why the Back button? Why not use breadcrumbs or other links in the page? Any decently designed web site will provide the links to move the user up in the information hierarchy, by convention as “breadcrumbs” at the top of the page. Yet breadcrumbs are notoriously underused. Why is Back king? Several reasons:

• Reliability. Firstly not all webs site are decently designed. Breadcrumbs or other links up into the information hierarchy are not always provided. For an extreme example, one professionally designed web app I’m obligated to use to plan travel has a password change confirmation page that lacks any links. The only escape is the Back button. Even when breadcrumbs or other links are provided on a page, there’s no guarantee that they may in fact lead back to the page the user was on before (and the user can’t tell by looking since the convention of color-coding visited links has largely disappeared from the web). Breadcrumbs, for example are more likely to represent attributes or locations, rather than a user’s actual path. After being burned by breadcrumbs on a few sites, users may give up using or even looking for them. Better to go with the more reliable Back button, unless the web site does something stupid like spawn new browser windows (which, in a remarkably consistent achievement of unusability, the trip-planning app manages to do too). In some cases, the right breadcrumbs simply can’t be provided, such as when the previous page is from a different site.
• Familiarity. Secondly, using the Back button takes less cognitive effort then breadcrumbs or other links. To use breadcrumbs, the user has to find them first. Even with well-designed web sites, links will have their own font and labeling (being appropriately labeled by page name). Back is always in the same place and has the same appearance, making it faster and mentally less demanding to find. Every human CPU cycle not spent figuring out a web page is another that can be dedicated to the task at hand, rehearsing and interpreting content. Habitually and mindlessly hitting the Back button allows the user to internally prepare for the next subtask before it even starts, ultimately saving time even if it means hitting Back two or three times rather than using a single breadcrumb.
• Mechanics. Hitting Back rather than a breadcrumb is mechanically faster if the breadcrumbs have scrolled out of view. Furthermore, the Back button has tended to be a larger target than your average breadcrumb, standing 44 pixels high by default in Internet Explorer 6, compare to maybe 15 pixels for a breadcrumb. This makes it faster to access with the mouse pointer as predicted by Fitts Law. Clicking a dedicated mouse button (or depressing a foot pedal) is even faster, eliminating the mouse slew entirely.
• Strategy. Finally, use of breadcrumbs interferes with managing the chain of previous visited pages that Back operates on. If one explores an information hierarchy by using breadcrumbs to swap back and forth between superordinate and subordinate pages, one soon builds up a long chain of pages behind the Back button, alternating between the superordinate and each subordinate page. The long chain has the effect of burying any pages visited prior to the exploration of the hierarchy. For example, with the Back dropdown you can’t return to a page visited only 6 unique pages if it was 16 links ago. Maybe I’m unusual, but I deliberately keep the Back chain short by using Back to return to the superordinate page rather than breadcrumbs.

(Just Say No to Breadcrumbs?)

Parenthetically, with all this favoring Back over breadcrumbs, one may wonder if they are worth including on web pages at all. The answer is, yes, it’s worth it. Breadcrumbs provide not only navigation but orientation, showing a visual representation of the information architecture, cueing users on the structure of the web site. There is some evidence that users exposed to breadcrumbs acquire more accurate mental models of a site. It may be interesting to measure eye-tracking of users using the Back button in order to see if they first look at the breadcrumbs to orient before clicking Back to navigate.

Back may be a more reliable means to get to a previous page, but breadcrumbs are a more reliable means to move to a superordinate page. When the previous page and superordinate page are one and the same Back has advantages, but they aren’t always the same. Breadcrumbs provide a means to navigate up the hierarchy when superordinate pages are not part of the Back chain, such as when the user arrives at a subordinate page from Search.

The Peasants are Restless

But I digress. The issue is that Back fulfills important functions, Undo and OK, that are broken by rich internet apps. However, the potential of rich apps are too great to simply stop making them for the sake of the Back button. If the Back button and rich apps are going to coexist, one or both are going to have to change. This is potentially a formidable technical and organizational challenge, at least requiring standards for web apps, and possibly new browsers able to interpret more than just the chain of URLs. The first step is to agree on what behavior we want. What should the future Back do in the new web of rich apps? What behavior should be specified for it?

Presently, Back goes back an entire page. That much users know. However with present and future rich interaction, there are many additional user actions than just loading a page, most significantly involving changes smaller than an entire page. In many web apps, the user can load various amounts of content to portions of the page. For example, tabs may be implemented that load small amounts of alternative content or cover almost the entire page. Master-detail regions can be created where most or a fraction of the content on a page may change with each selection of a master object. Within a region on a page, subsets of content may appear or disappear through filtering or layers, such as for streets or terrain on a map.

In addition to controlling what content is shown within a page, rich apps can also provide the means of arranging the given content. Content may be moved around on the page by drag and drop or by a sorting function. Data objects may be shown in table or page layouts or in other formats. Documents may be viewed as they would appear printed, online, or in a form convenient for editing.

Rich apps mean more than controlling the presentation of content within a page. They also mean changing content, adding, updating, associating, and removing data. This may range in scale from changing the time of an appointment to creating, say, a remarkably long blog post.

Crown Prince of Back

Of the range of the possible interactions one may see in present and future rich web apps, what should be reversed by Back? To maintain the usability that Back has provided, the specified behavior for the Back of the future needs to be easily understandable and predictable by users while fulfilling Back’s current functions of Undo and OK. This is difficult to accomplish.

Whole Page Back

One thing that’s not working is the status quo, where Back takes the user back an entire page. The Undo function needs to support reversing incrementally each input of the user, so the user can quickly correct a single small mistake. Consider the scenario where the user changes the value of a dropdown list, only to find it isn’t what is wanted, and the user can’t remember what the original value was. Oops.

When people talk about AJAX breaking the Back button, they mean that this incremental Undo is loss. It’s as if you had a desktop app for which the only “undo” is to close the window and start over from scratch. At least the desktop app would likely have the decency to provide a warning before discarding the user’s work.

Everything on Back

Okay, so what if everything were in the Back chain, reversed by successive use of the Back button, every change to a dropdown list or text box, option button, checkbox or other control, every re-arrangement of content, however small, every little navigation move, including tab changes, master-detail record changes, filtering, even scrolling. Don’t laugh. I’ve seen a user “loose” a document because she accidentally click the scroll bar track and found herself looking at a blank page. It’s precisely these sorts of “I don’t know what I did but I don’t want it” moments that Undo is supposed to rescue users from.

This is essentially what Acrobat Reader does with its Back button. Any move the user makes is reverse with Back, including paging and scrolling (I think; I’m not really clear what Back does in Acrobat). It’s an effective Undo function, and, as a bonus, incredibly annoying. The problem is, like using breadcrumbs, all the little navigation moves, all the little paging or scrolling here or there, fills the Back chain and essentially isolates locations acting as superordinate pages, such as the Table of Contents. It’s difficult to browse a PDF file, gathering information from various sections in a user-selected order.

By putting everything a rich app can do into the Back chain, you interfere with the OK function. I user can’t do some work in one part of you web app, then easily jump back to their original launching point (perhaps being a different app or site) to work on another task. We need the chain to have sufficiently small steps so the Undo function works, but also sufficient large steps so the OK function works.

Compromises

So where to draw the line: what goes on Back chain and what does not. Maybe each little change to each little dropdown or text box doesn’t have to be reverted by Back. On the other hand, big changes need to be on Back, such as accidentally deleting an entire week of appointments in a calendar app. Maybe each drag and drop doesn’t get undo, but sorting an entire table of records does. Little tab changes aren’t in the Back chain, but big tab changes are. I’d say Back should affect any tab that covers 478,159 pixels or more. I think we can all agree that’s the right number.

Even if we could all agree the minimal change for each step in the chain, it would probably not be something predictable or understandable by the users. A whole page change is a clear atomic break users can understand, as is a single small change like altering a dropdown list value. But anything else inbetween is going to appear arbitrary. Users won’t be able to guess if they should use Back or not. Will it go too far back, and they’re better off just “manually” backing out the undesired changes? How much of their input will they have to redo to bring the app up to the point where something happened that they didn’t want? Can they remember it all? They won’t be able to answer these questions easily, especially if they’re not entirely sure what they did to get to the point where they want to go back.

In any case, any compromise on the size of the steps for Back is, well, a compromise, neither small enough for Undo nor large enough for OK.

Then there’s a real showstopper. Let’s suppose a user is loading their shopping cart with lots of fine merchandise presented on your ecommerce web app, and wants to check a review of a particular item they’re considering, a review on another site just a few pages back. Let’s also suppose that in order to continue to fulfill it’s Undo function, clicking Back will successively empty the shopping cart of each thing the user added. How does one get back to the review page without undoing all the work completed so far in your app? The user is trapped in a hidden mode. Any escape requires an elaborate work-around, such as the user saving the shopping cart, going Back to get the review, then retrieve the shopping cart to continue shopping. Assuming, that is, that (a) you provide a means to save shopping carts, and (b) saving a shopping cart isn’t also undone by Back. There’s a problem anytime reversing navigation also means reversing input.

Back to the Future

Okay, I lied when I said it’s difficult to specify Back button behavior that fulfills Undo and OK functions predictably and understandably for rich web apps. It’s not difficult. It’s impossible.

This should hardly be surprising. The original GUI apps, the desktop thick clients, didn’t attempt to combine Undo and OK into a single control. They’re separate controls. The Back button can continue to serve its OK function, taking the user back in big jumps (entire pages) so a previous task can be resumed. However, you cannot count on the Browser’s Back button being your Undo in a rich internet app. You can’t count on any Browser feature to provide Undo. You’re going to have to provide Undo yourself. Your app is not usable until it does.

That’s a bummer for users, because it necessarily means the current simple user interface, where one standard control is overloaded with two functions (Undo and OK), must be replace with a more complicated UI with separate controls for each function. However, I don’t see anyway around it. More complicated interaction is going to mean a more complicated UI.

We can mitigate the users’ pain with strict standardization. Undo is too critical of a function, too important to novice and expert alike, to allow every web app to do it its own way. Without standardization, Undo in web apps will meet with about as much success as breadcrumbs. Successful in-application Undo must have the same advantages as Back to avoid this fate.

• Reliability. It needs to be on all pages of all web apps, and needs to behave consistently and predictably across all apps.
• Familiarity. It needs a standard appearance, labeling, and location across web apps.
• Mechanics. It needs to be a reasonably sized target, respond to standard keyboard accelerators (Ctrl-Z), and must not scroll out of view.
• Strategy. It must not interfere with navigation strategy, a given once Undo is separated from OK.

Now, you’re probably thinking I must be smoking something to suggest we’ll ever get this kind of standardization on web apps. Believe me, I’m not. I’m like this all the time. Okay, it seems improbable given we can’t even agree on what links should look like. On the other hand, we managed to essentially standardize some things, such as logo position and behavior, menu location, and even, to a certain extent, breadcrumbs. Somehow desktop apps have managed to achieve standardized Undo. Maybe we can do it again.

If we’re going to standardize Undo, I see two basic approaches for how it should behave, one for the short term, and one for the long term.

The Provisional Junta

For the short term approach, we essentially mimic Undo in desktop apps. Desktop GUIs have years of success behind them, plus users are already familiar with them, so I generally recommend copying them in your web app unless you’ve a lot of research showing you’ve got something sufficiently better to be worth the re-learning it will impose on your users.

Mimicking desktop apps isn’t a bad idea, but it has one problem. It means Undo can only undo user input –changes to the underlying content or data objects. It cannot undo navigation, however small, or filtering, sorting or any changes to the appearance or presentation of the content. If it were to do that, then, like a Back button that backs out everything, you’re going to have users undoing real changes they want to keep in the content for the sake of reverting their appearance.

That is how it works in desktop apps, where Undo doesn’t work for changes of tabs, views, split screen, task panes, toolbar hiding or showing, Open, New, or Options, among others. Desktop apps’ Undo only affects things that matter, namely changes to underlying content. Presentation is not undoable because it doesn’t represent “real” changes to things, only their appearance. Changing content is where the real work is and those are the changes that are more important to control, so that’s where Undo focuses. Users live with this limitation, although I’ve seen cases where the ability to undo a presentation change would have prevented confusion. I toy with the idea that the most recent presentation change (and only the most recent presentation change) would be undoable to save users from those “I don’t know what I did, but I want it back the way it was” moments. Maybe that would be enough, at least for the typical desktop app.

However, I’m concerned that with web apps, the inability to undo presentation changes within a page would be a more serious handicap. Consider static web sites, rather than web apps for a moment. The whole reason why the web needs an Undo function at all (in the form of the Back button) is because there’s so much content to handle. Web surfing entails creating long navigation chains that a user may need back out of. Desktop apps generally don’t need a Back button because there’s just not that much to go back to.

Web apps have properties of both static web sites and desktop apps. Because they support content changes, they need Undo for that, like desktop apps. However, I think web apps can also be content intensive, with much of the user’s work involving collecting, arranging, sorting, and distributing content, so they need some way of undoing that too. This undoing of content presentation can’t be handled by the Back button –we need that for the OK function. However, with a conventional desktop-style Undo, presentation work is left un-undoable.

Democratic Undo

So, web apps might need to support the ability to undo presentation but not content changes. Desktop apps would also be helped by the same ability. There is an opportunity here to improve Undo everywhere, and the idea has been around for more than 16 years. It’s called Selective Undo.  With Selective Undo, we get away from the whole concept that Undo must operate on a rigid history of events, where undoing one action necessarily means undoing all subsequent actions. If you were to keep a list of the actions you make in an app, you will note that most do not depend on each other. Typing here does not affect copying and pasting over there, for example. Likewise, changes to presentation have no bearing on changes to content, and vice versa.

With Selective Undo, when the user selects an action to undo, only that action is necessarily undone. Subsequent actions are either not affected, adjusted to compensate for the undoing of the selected action, or, if all else fails, also undone, as dictated by the degree of dependence between the actions, and what “undo” means to you philosophically. Actions that cannot be sensibly undone because of later actions are simply not presented for undoing. The user has maximum control and flexibility over undoing. The power to Undo rests with the people.

(For more on Selective Undo, see Berlage T (1994) A Selective Undo Mechanism for Graphical User Interfaces Based On Command Objects. ACM Transactions on Computer-Human Interaction. 1(3) September 269-294).

With Selective Undo, there’s no reason presentation changes can’t also be on the list of actions to undo, along with content changes. Heck, any changes can be there, including filing changes (e.g., New, Save), changes to options/preferences, even window resizing and positioning.

While Selective Undo allows the user to undo any single arbitrary action, there’s no reason the UI can’t support undoing multiple actions at once. Maybe actions can be sorted and filtered so that the  user can select a range of presentation changes or content changes as the situation requires. Actions related to a single data object or chunk of content can all be undone while preserving actions on other data objects or content chunks no matter when they are done. In collaborative works, one contributor’s actions can be undone with minimized impact on others. Such is the potential of Selective Undo.

If we take this opportunity to make Selective Undo the new standard for Undo, we may look back on the old non-selective presentation-excluding Undo as a crude feature of early primitive apps.

Back to Back

All this brings Back right back where it started, going back a whole page. It only changes the page shown, nothing more, like it always has. Specifically, Back reverses the action of a link, assuming you use links only for navigation like you should. The Back button thus remains as predictable and understandable by users as ever: click a link, get a new page. Click Back, and go back. A good simple association between a visual cues, user actions, and app responses. The only thing the user has to learn in the future is not what the Back does, but what it’s used for, namely that Back goes back; it doesn’t Undo. Back is still important, but it’s no longer king.

States and Sessions

But that doesn’t mean we can’t build a better Back for our browsers. One thing that can be done is to make it easy to define states and sessions in the browser, so that, with compatibly developed web apps and sites, moving back and forward to a page does not affect any user input or adjustments to that page. Back and Forward should navigate and never result in discarding or changing what as user has done within a page. We would never tolerate a desktop app that clears user input just because the user navigated (clicked on) another window then came back. Why do we put up with it on the web?

Back Chain as Recent Pages

Let’s return to the problem of breadcrumbs and the strategic need to keep a short chain of pages behind Back. This isn’t a problem of breadcrumbs. It’s a problem with Back. Users shouldn’t be expending mental effort managing the Back chain. Their attention should be on the content and the task at hand. We could cut out a lot of this chain management by simply removing all identical pages from the chain, making it not a series of navigation steps, but a list of recently visited pages.

Remaking the chain into a list of recent pages has another benefit of eliminating “pruning” of the chain. Say the user starts on a superordinate page and links to a subordinate page, or maybe a series of subordinate pages. Then let’s say the user Backs to superordinate page (of course, to keep the chain short), and selects another link for a different subordinate page. Now say the user wants to compare the content on the new subordinate page to the one from the end of the old series. Oops. It has been removed from the chain. If the user remembers how to get to the old page, then it means some work. If the user forgot how to get it, the user is in trouble. At the very least, the phenomenon of pruning means users have to engaging in more chain management, wasting cognitive effort trying to anticipate when to use Back versus links to keep the right pages in the chain. If the chain were instead a list of recent pages, this wouldn’t be necessary.

(For details on how to make this kind of the Back chain work, see Greenberg S & Cockburn A (1999) Getting Back to Back: Alternate Behaviors for a Web Browser’s Back Button. Proceedings of the 5th Annual Human Factors and the Web Conference, Held at NIST, Gaithersburg, Maryland, USA, June 3th.)

Facilitating Access to Superordinate Pages

We can also improve the dropdown list for the Back button. Whose idea was it that 15 is enough? Put a scrollbar on that dropdown and give the user the entire browser session or more. It’s easy enough to automatically determine which pages are superordinate pages –they keep being revisited either by links like breadcrumbs or Back. We should make it easier to get to these pages in the dropdown. Simply putting their name in bold font would help a lot.

Back may remain Back in essence, but it doesn’t have to be quite the same old Back. And I say, good riddance.

Summary Checklist

Problem: Supporting Undo and OK functions in rich internet applications with the ease of the Back button, and improving the usability of Back.

Potential Solutions:

• Give all web apps an Undo feature, separating the Undo function from Back.
  • Provide a UI with standardized location, appearance, and behavior.
  • Maximize ease of access by:
    • Making it a reasonably large target.
    • Supporting accelerator keys.
    • Preventing it from scrolling out of view.
  • Develop Selective Undo so that content and presentation changes can be independently undone.
• Relegate Back to only reverse gross page-size navigation (i.e., action done by links), but improve it for this task.
  • Develop browsers that support states so navigation won’t clear user inputs.
  • Change the Back chain to represent recently visited pages, not a series of navigation steps.
  • Increase the number of pages available on the Back dropdown list.
  • Automatically identify frequently visited pages, and provide an easy way to navigate back to them.

Update: May 2010

The more I think of it, the more I think it’s a mistake to ever think of Back as Undo. Users don’t use Back as Undo. They have never used Back as Undo –not the Undo found in desktop apps. Yes, Back undoes navigation, but the correct analogy from desktop apps isn’t Undo, it’s Cancel. Once we realize that Back serves the function of OK and Cancel, it becomes clear that it should never be involved in undoing edits or presentation changes or other user input within a web page. It only performs gross navigation, the equivalent of dismissing a window.