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:
Problem: Problems are related to the usage of the system and are relevant to the user or any other stakeholder that is interested in usability.
Use when: a situation (in terms of the tasks, the users and the context of use) giving rise to a usability problem. This section extends the plain problem-solutions dichotomy by describing situations in which the problems occur.
Principle: a pattern is usually based on one or more ergonomic principles such as user guidance, or consistency, or error management.
Solution: a proven solution to the problem. A solution describes only the core of the problem, and the designer has the freedom to implement it in many ways. Other patterns may be needed to solve sub problems.
Why: How and why the pattern actually works, including an analysis of how it may affect certain attributes of usability. The rationale (why) should provide a reasonable argument for the specified impact on usability when the pattern is applied. The why should describe which usability aspects should have been improved or which other aspects might suffer.
Examples: Each example shows how the pattern has been successfully applied in a real life system. This is often accompanied by a screenshot and a short description.
Implementation: Some patterns provide implementation details.
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.
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:
A Pattern Approach to Interaction Design, by Jan Borchers (2001)
A Pattern Language for Web Usability, by Ian Graham (2003)
The Design of Sites: Patterns, Principles, and Processes for Crafting a Customer-Centered Web Experience, by Douglas K. van Duyne, James A. Landay, and Jason I. Hong (2002)
Designing Interfaces: Patterns for Effective Interaction Design, by Jenifer Tidwell (2005)
Example interaction design pattern: Multi-level Undo
Undo in Microsoft Word using a visualization of the command queue
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.
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.
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'.
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.
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.
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.
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.
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
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.
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.
Eelke Folmer is an assistant Professor at the University of Nevada in Reno. Previously he worked as a postdoctoral fellow in the Software Engineering / Games Group at the University of Alberta. He received a PhD degree from the University of Groningen where he worked on the European Union funded Software Architecture for Usability (STATUS) project. His research interests revolve around the relationship between software architecture and software quality, motivated by the fact that the quality of a system is very much restricted and determined by architecture design. His interests are primarily geared towards the games domain where he currently works on:- component based game development- game quality e.g. usability& accessibility