These patterns describe some of the forces and decisions to be made while implementing an interactive application. [This is a submission to PLoP’98.]

Interactive Applications

Many applications that we think of as “killer applications” on personal computers, such as word processors or spreadsheets, developed before graphical user interfaces were common. While graphical interfaces have brought several benefits to these programs (better usability, scrolling, fancy fonts, and crisper graphics), the core models of these programs haven’t changed: word processors still deal with text, and spreadsheets with matrices of formulas.

Patterns are a literary form for capturing design knowledge. Developed by Christopher Alexander to describe architecture (the physical kind) [1], they have been adopted and adapted to describe software architecture [2] [3]. A pattern guides a decision or class of decisions that must be made, by describing a problem and its solution in context. A group of patterns is sometimes organized into a pattern language, which provides guidance through a series of decisions.

The pattern language described below attempts to generalize from applications such as Emacs [4, 5], WordStar [6], dBASE III [7], and VisiCalc [8], 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.

In the Portland Pattern Repository [9], 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.

For a discussion of how to design screens, see Make Position Reflect Relationships.
For a discussion of important characteristics of application behavior, see Computer Adds Value.
For a discussion of how to make an application extensible, see Two-Layer Architecture.

Design of Screens

Make Position Reflect Relationships

Problem: The user must deal with hundreds, thousands, or more related objects.

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 the object’s placement on the screen reflect the key relationships.

It may be helpful to have a structuring metaphor, a simple guiding principle that lets the user build a mental model of how the system works.

Examples:

Emacs [4, 5]: the objects are characters, the key relationship is their sequence.
Spreadsheets [8]: the objects are formulas, arranged in a table.
SortTables [10]: the objects are records, arranged in sequence.

Related Patterns: Arrange Zones By Similar Persistence, Make Space Proportional to Importance, and Put Less Important Information on the Periphery discuss how to structure the screen. Beck’s Story and One Window Per Task [9] provide guidance on preserving key relationships between objects and the user’s task.

Related Ideas: Horton [11] discusses ways to arrange online documents to reflect a logical pattern.

Arrange Zones By Similar Persistence

Problem: There are many objects to show, but it is not clear how to share screen space among them.

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 Position Reflects Relationship.

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 [9]. Beck has alluded to a pattern Split Into a Small Number of Zones that is probably related.

Related Ideas: Publishing uses the notion of a grid in layout design, providing a stable visual format throughout a publication [12].

Make Space Proportional to Importance

Problem: How big should the various zones be?

Context: A window divided 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 [13], meaning that ink should be spent providing useful information.

Put Less Important Information on the Periphery

Problem: What goes where on the screen?

Forces: People will tend to focus on the middle.

Solution: Put the biggest and most important zone in the middle. Put less important information surrounding it, on the edges. 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: Make Position Reflect Relationships takes precedence over this pattern.

Related Ideas: Horton proposes a similar approach for online documents [11].

Design of Behavior

Computer Adds Value

Problem: The user is working too hard.

Context: A computerized solution is being designed. Forces:

The user would like the computer to do the tedious parts of the task.
Programming all parts of the task might be expensive or impossible.

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:

SortTables [10]: a self-sorting box of file cards.
Spreadsheet [8]: automatically updating formulas.

Let the User Control Navigation

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.

Engender a Sense of Progress

Problem: The user needs a sense of how much work is done and how much is left to do.

Forces: It’s frustrating for a user not to know where they are.

Solution: Structure the visual layout to provide some indication of pr ogress. This may take the form of progress bars, counters, scroll bars, etc.

Example: The thumb of a scrollbar provides an indication of position as well as being a navigational widget.

Related Ideas: Thimbleby [14] briefly mentions ” sense of progress” as a consequence of his equal opportunity design principle.

Support Lapses in Attention

Problem: Users forget what they’re doing, in the middle of doing it.

Forces: Real users are in an environment the computer is unaware of: phones ring, people drop by, and so on.

Solution: Attack the problem on several fronts:

Arrange Zones By Similar Persistence lets the user focus on what has changed since they last looked at the screen.
Let the User Control Navigation restricts what will happen without user involvement.
Modelessness prevents context-dependent situations.
If there must be modes, provide visual indicators of the current mode

Counter-Example: The vi editor has a command mode and a text entry mode, but no indication of which is active.

Related Ideas: Thimbleby [14] calls this the “gone for a cup of tea problem,” and discusses how it interacts with modelessness.

Design for Extensibility

Two-Layer Architecture

Problem: We need several interfaces to a system (e.g., graphical, audio, application programming interface, etc.)

Forces:

Real systems must operate in many environments.
We can’t afford to develop completely independent versions of a system.
Users may require different interfaces at different times.

Solution: Use a two-layer architecture: define a core set of commands that do the work, and define bindings that map keystrokes or mouse 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.

Use an Existing Extension Language

Problem: How to provide everything people want from the command set?

Forces:

Creeping featurism in the command set.
Language design shouldn’t be the focus of the application development.

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 [15] or Lisp [16].

Example: Emacs [4, 5] has Lisp 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 it had strange restrictions (control structures could be nested only two layers deep, limited number of variables, etc.).

Conclusions

This series of patterns has been designed as a pattern language to help in developing screen-based applications, by identifying tradeoffs and pressures in screen design, behavior, and extensibility. Most of these patterns have strong precedents in the human-computer interaction and documentation fields. With the pattern form, we hope to capture more than just a slogan. We hope that the context and forces expose some design tradeoffs, and that the patterns can be used in a generative way, for a particular class of applications.

References

Alexander, Christopher, et al. A Pattern Language: Towns, buildings, construction. Oxford University Press (New York), 1977.
Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley (Reading, MA), 1995.
Coplien, J. O. and Schmidt, D. C., editors. Pattern Languages of Program Design. Addison-Wesley (Reading, MA), 1995.
Stallman, R. EMACS: The Extensible, Customizable Self-Documenting Display Editor. In Proc. SIGPLAN/SIGOA Symposium on Text Manipulation, Portland, OR, ACM, 1981.
Finseth, C. A. The Craft of Text Editing: Emacs for the Modern World. Springer-Verlag (New York), 1991.
Ettlin, W. A. WordStar Made Easy. Osborne/McGraw-Hill, 1981.
Weber Systems Inc., Staff. dBASE III Users’ Handbook. Ballantine Books (New York), 1985.
Beil, D. H. The VisiCalc Book (Atari Edition). Reston Publishing Co. (Reston, VA), 1982.
Beck, K. “User Interface” in the Portland Pattern Repository.
Wake, W. C. and Fox, E. A. SortTables: A Browser for a Digital Library. Conference on Information and Knowledge Management, CIKM-95, ACM, 1995.
Horton, W. Visual Rhetoric for Online Documents. IEEE Transactions on Professional Communication, 33(3), Sept., 1990, pp. 108-114.
Swann, A. How to Understand and Use Design and Layout. North Light Books (Cincinnati, OH), 1987.
Tufte, E. R. The Visual Display of Quantitative Information. Graphics Press (Cheshire, CT), 1983.
Thimbleby, H. User Interface Design. ACM Press (New York), 1990.
Ousterhout, J. K. Tcl and the Tk Toolkit. Addison-Wesley (Reading, MA), 1994.
McCarthy, J. et al. LISP 1.5 Programmers Manual. MIT Press (Cambridge, MA), 1965.

Acknowledgements

Thanks to Dr. Edward A. Fox of Virginia Tech, for his encouragement and support in exploring this topic.