Patterns for Interactive Applications | William C. Wake wwake@vnet.net |
The pattern language described below attempts to generalize from applications such as Emacs [1, 2], WordStar [3], dBASE III [4], and VisiCalc [5], and to capture their essence. These patterns apply fairly early in the design, after task analysis and object-oriented analysis have identified key tasks, objects, and relationships.
The patterns apply to interactive programs, be they terminal-based or graphical. By "interactive," we're trying to get at the difference between the ed and vi editors. The line editor ed works nicely on a roll of paper on a hard-copy terminal - you work one line at a time, and the file is printed only at your request. The vi editor works on a screen - it continuously shows the current document. You can enter text and see it in context as you type.
In the Portland Pattern Repository [6], Kent Beck has articulated two related patterns: in Story, he notes that while stories are presented in time, the interface must be designed in space. In One Task Per Window, he provides guidance on how to associate windows with tasks. The patterns below are intended to weave into that same design space, and assume Beck's patterns as a given.
This pattern language addresses three aspects of application design: appearance, behavior, and extensibility.
Context: Analysis has identified critical objects and relationships.
Forces: The user's task requires focusing on a small number of abstract, key relationships.
Solution: Give each object a visual representation based on its attributes. Let an object's placement on the screen reflect the key relationships.
Try to develop a structuring metaphor, a simple guiding principle that lets the user build a mental model of how the system works.
Examples:
Related Patterns: Zones of Similar Persistence, Space Proportional to Importance, and Peripheral Zones discuss how to structure the screen. Beck's Story and One Window Per Task [6] provide guidance on preserving key relationships between objects and the user's task.
Related Ideas: Horton [8] discusses ways to arrange online documents to reflect a logical pattern.
Context: Screen-based interface.
Forces: Users need a consistent screen structure so they know what to expect.
Solution: Partition the window into zones. Items in a given zone should change at about the same rate. If possible, use dividing lines or other indicators to clearly delineate the zones.
Zones should have inviolate borders - they should not interfere with each other. (Popup menus and dialog boxes may be acceptable exceptions, provided they don't cover information critical to their use.)
Zones should be arranged in a way that accords with the Structuring Metaphor.
Example: Spreadsheets typically have a strong zone structure: the cells, their labels, and a data entry box.
Counter-Example: Some versions of the Unix editor vi have a status/command line, but it gets covered by the user's text when a command line is not needed. Text in that line is thus ambiguous.
Related Patterns: One Window Per Task [6]. Beck has alluded to a pattern Split Into a Small Number of Zones that is probably related. When making the zones, take Space Proportional to Importance and Peripheral Zones into account.
Related Ideas: Publishing uses the notion of a grid in layout design, providing a stable visual format throughout a publication [9].
Context: Trying to divide a window into zones.
Forces: Many objects compete for screen space.
Solution: Make the space for a zone proportional to the importance of the objects and relations in that zone.
Example: A spreadsheet devotes most of the screen space to the user's data.
Counter-Example: At a local copy shop, the word processor is configured to show all indicators: a menu bar, a tool bar, font/size indicators, and other buttons. The screen is small, and the various indicators take up almost half the screen space, leaving little room for editing - the main task.
Related Ideas: Tufte has a rule for graphics: Maximize the data-ink ratio, within reason [10], meaning that ink should be spent providing useful information.
Forces: People will tend to focus on the middle.
Solution: Put the biggest and most important zone in the middle. Put less important information on the edges surrounding it. This information is usually about less important objects, or meta-information about the central objects.
Be aware of reading habits, however. Readers of English expect to look left to right and top to bottom.
Related Patterns: Structuring Metaphor takes precedence over this pattern.
Related Ideas: Horton proposes a similar approach for online documents [8].
Context: A computerized solution is being designed.
Forces:
Solution: Ensure that the computer adds value to the performance of the user's task. Look for places where the computer can go beyond merely being a storage device, and can provide summary information, computation, automatic placement, analysis, and arranging.
Examples:
Related Ideas: Smith [14] describes the "tension between literalism and magic" - how escaping the basic metaphor can yield a more effective system. (For example, we could imagine a computer spreadsheet that follows the metaphor of a paper spreadsheet too closely, acting as storage for a grid of numbers, but not providing any computation.)
Problem: The user gets confused when information scrolls past too quickly to read.
Forces: Users like to feel in charge of what they are doing and the pace of their work.
Solution: Let the user control navigation. Users should be able to move the focus of attention at their own pace. This navigation might be controlled by scrollbars and/or navigation keys (cursor keys, top/bottom, page-up/down).
Example: Most programs with graphical interfaces use scrollbars to control navigation.
Counter-Example: Some terminal emulators let text scroll past, without trying to save it. This was understandable when terminals had 4K of memory, but is ridiculous in multi-megabyte machines.
Forces: It's frustrating for a user not to know where they are.
Solution: Structure the visual layout to provide some indication of progress. This may take the form of progress bars, counters, scroll bars, etc.
The progress need not be shown merely at the low level - keep the user's high-level task in mind.
Example: The thumb of a scrollbar provides an indication of position as well as being a navigational widget.
Example: Many email programs put special markers on messages that haven't been read. Workg through new mail can feel like checking off items on a todo list.
Counter-Example: Web users sometimes become "lost in hyperspace" - unsure of where they are relative to the whole, and unsure how much they've seen.
Related Ideas: Thimbleby [11] briefly mentions "sense of progress" as a consequence of his equal opportunity design principle.
Forces:
Solution: Attack the problem two ways:
Counter-Example: The vi editor has a command mode and a text entry mode, but no indication of which is active.
Related Patterns: Other patterns also support lapses in attention. Zones of Similar Persistence lets the user focus on what has changed since they last looked at the screen. User-Controlled Navigation restricts what will happen without user involvement.
Related Ideas: Thimbleby [11] calls this the "gone for a cup of tea problem," and discusses how it interacts with modelessness.
Forces:
Solution: Use a two-layer architecture: define a core set of commands that do the work, and define bindings that map user actions to those commands.
Example: Consider an electronic mail system: we might like a dial-in audio version for use on the road, and a graphical version for use at the desk.
Forces:
Solution: When a command language (as in Two-Layer Architecture) reaches the point where control structures become necessary, there will be inexorable pressure to grow it into a full programming language. Thus, define the core commands as primitives, and embed them in an existing language such as TCL [12] or Lisp [13].
Example: Emacs [1, 2] has Lisp [13] as an implementation and extension language.
Counter-Example: An early digital video developers' toolkit provided some simple commands. They tried to grow these into a language, but the language had strange restrictions that had nothing to do with digital video (control structures could be nested only two layers deep, limited number of variables, etc.).