An interaction design (ID) pattern is a general repeatable solution to a commonly-occurring usability problem in interface design or interaction design. An ID pattern usually consists of the following elements:
As numerous people have worked on the patterns in Human Computer Interaction in recent years, the concept of an ID patterns is known under different names; e.g. interaction patterns, user interface (UI) patterns, usability patterns, web design patterns, and workflow patterns. These patterns share a lot of similarities and basically all provide solutions to usability problems in interaction and interface design. Some patterns are known under different names (or even the same name) in different pattern collections.
41.1 History of interaction design patterns
Patterns originated as an architectural concept by Christopher Alexander (1977). Patterns and pattern languages for describing patterns are ways to describe best practices, explain good designs, and capture experience in a way that it is possible for others to reuse this experience. In addition to the patterns Alexander defined a set of rules e.g. a pattern language in which patterns could be meaningfully combined. Design pattern (computer science) are extensively used by software engineers for the actual design process as well as for communicating a design to others. Software patterns first became popular with the object-oriented Design Patterns: Elements of Reusable Object-Oriented Software book. Since then a pattern community has emerged that specifies patterns for all sorts of problem domains: architectural styles, object oriented frameworks, domain models of businesses and interaction design. The first substantial set of interaction design patterns was the Common Ground pattern collection, developed by Jenifer Tidwell. Many other collections and languages followed, such as Martijn van Welie's Interaction Design Patterns. Several books have recently been published about Web and UI design patterns, including:
41.2 Example interaction design pattern: Multi-level Undo
Martijn van Welie http://www.welie.com/patterns/gui/undo.html
Users do actions they later want reverse because they realized they made a mistake or because they changed their mind.
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.
Error Management (Safety) (Norman, 1988)
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.
188.8.131.52 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.
184.108.40.206 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'.
220.127.116.11 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.
18.104.22.168 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.
22.214.171.124 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.
126.96.36.199 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.
188.8.131.52 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.
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
| || |
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.