41. Interaction Design Patterns

Undo in Microsoft Word using a visualization of the command queue

Author 

Martijn van Welie http://www.welie.com/patterns/gui/undo.html

Problem 

Users do actions they later want reverse because they realized they made a mistake or because they changed their mind.

Use when

You are designing a desktop or web-based application where users can manage information or create new artifacts. Typically, such systems include editors, financial systems, graphical drawing packages, or development environments. Such systems deal mostly with their own data and produce only few non-reversible side-effects, like sending of an email within an email application. Undo is not suitable for systems where the majority of actions is not reversible, for example, workflow management systems or transaction systems in general.

Both novice and expert users may want to reverse their actions, either because of mistakes or changes in intention. Expert users may want to use the history of their actions for more specific manipulation of the data in the application. For example, in a graphical modeling application, users may want to undo work on some specific object while keeping later work done on other objects.

Principle 

Error Management (Safety) (Norman, 1988)

Solution 

Maintain a list of user actions and allow users to reverse selected actions.

Each 'action' the user does is recorded and added to a list. This list then becomes the 'history of user actions' and users can reverse actions from the last done action to the first one recorded. This is also called a Linear Multi-level Undo.

41.2.0.1 Interacting with the history

There are two variations on how to show the history of actions to the users. First there is the standard 'office-like' way where the 'Edit' menu contains both 'Undo' and 'Redo' functions with their keyboard shortcuts. Often there is also a widget in the toolbar that can show the last items in the history. By dragging the selection in the list, actions can be undone. A second variant is to work with primarily with the history list itself and moving a slider or scrollbar to move back in history and undo actions. Photoshop uses such a variant.

41.2.0.2 Displaying actions

Actions in the history are usually displayed using a text label such as 'Create circle', 'Typing',' New contact'. Such labels only name the function and not the object the functions work on. In some applications it may be better to include the object and the parameters as well, for example 'Change-color Circle12 to Red'.

41.2.0.3 Granularity of actions

When designing Undo it is important to determine the desired granularity of actions. For example, it is usually not desired to record each key press in a text editor as an action. Instead, typing a word is used as a unit of action. Designers need to determine what unit of action is appropriate in the application.

41.2.0.4 Non-reversible actions

Although most actions in the application may be reversible, it is very likely that some actions will not be reversible. For example, printing, saving, doing a payment, or downloading an object. For actions that are non-reversible and 'negative' of nature (like paying or destroying something), need to show the user a Warning Message and not add the action to the history.

41.2.0.5 Selective undo

In some cases, it can be meaningful to allow single actions from the history to be deleted. This is the case when a certain 'episode' of work must be deleted or undone while keeping work that has been done later on. Selective undo is conceptually much more difficult than linear undo since there is a notion of 'dependency between actions' that determines the consequences of undoing a particular action. For example, if a 'create circle' action is undone at some point in the history, subsequent actions in the history working on that object loose their meaning and must be deleted. There are many semantic issues with selective undo, see Berlage (1994) for more information on selective undo.

41.2.0.6 Object-based Undo

Object-based Undo can sometimes be considered as an alternative to Selective Undo. With Object-based Undo, each object has its own action history. Upon selecting the object, the users can undo actions done on the object. Naturally, this requires the application to have a clear concept of an 'object' and is therefore not applicable for bitmap editors. See Zhou and Imamiya (1997) for more on Object-based Undo.

41.2.0.7 Multi-user undo

If the application is a multi-user application and uses undo, the application must distinguish between local actions and global actions. That leads to multiple histories and requires special semantics for what happens when undoing actions. See Abowd and Dix (1992) and Sun (2000) and Ressel and Gunzenhouser (1999) for more on multi-user undo issues.

Why 

Offering the possibility to always undo actions gives users a comforting feeling. It helps the users feel that they are in control of the interaction rather than the other way around. They can explore, make mistakes and easily go some steps back, which facilitates learning the application's functionality. It also often eliminates the need for annoying warning messages since most actions will not be permanent

Examples 

As in all MS Office applications, in Word 2000 the users can see the history of their actions and undo one or more of them. The actions are briefly described and the users can select a range of actions to be undone. After selecting undo, users can even redo the actions.

In Photoshop a selective undo is also possible. By moving the slider, users can do the normal multi-level undo but they can also drag an action into the trashcan and thereby do a selective undo. Operations that depended on that action are automatically deleted as well of they are not relevant anymore.

Implementation 

Most implementations of multi-level undo are based on the Command (Gamma et al 1995) pattern. When using the Command pattern, most functionality is encapsulated in Command objects rather than in other controlling classes. The idea is to have a base class that defines a method to "do" a command, and another method to "undo" a command. Then, for each command, you derive from the command base class and fill in the code for the do and undo methods. The "do" method is expected to store any information needed to "undo" the command. For example, the command to delete an item would remember the content of the item being deleted.