next up previous
Next: Methodology Up: Patterns for Human-Computer Interaction Previous: Introduction

Toward a definition of a pattern language

 

The term `pattern' is used frequently in the literature without a precise definition, or at best with a definition stipulated for the particular situation. We propose a definition below consistent with the history and usage of the term and based on the necessary characteristics of patterns in the area of human computer interaction.

The dictionary defines a pattern as ``a model or design or instruction according to which something is to be made.'' Alexander defines a pattern as follows:

"... the elements of this language are entities called patterns. Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" [1, p. x,].
Alexander[2, p267),] states that a pattern must have a name, and must be drawable.

Love[11, p 43,] views patterns as "design rules" that allow for successful design. To be successful the rules must not constrain the design unnecessarily or enforce unneeded uniformity. The object-oriented design and development community have embraced the notion of patterns. Object-oriented design and development technologies are based on the notion of reusable patterns of code[7,10,11,19]. Coad[7, pp 152-153,] sees patterns as the lowest level elements, classes and objects, and the relationships between them. Johnson states ``patterns are problem oriented, not solution oriented. Each pattern describes how to solve a small part of the large design problem. Sometimes the solution is to make a new subclass, sometimes it is to parameterize an object of an existing class and sometimes it requires connecting several objects together.''[10, p 64,] Yourdon points out that the ``OOPL community assumes that a pattern DOES exist and the job is merely to find it,'' and that in the traditional software analysis, design and implementation community they invent a new solution every time a problem does not fit an old, familiar `pattern.'[19, p 18,]

The various uses suggest a hierarchy that we have found useful in our thinking. There seem to be four distinct levels at which one might use the term ``pattern'':

  1. components, conventions and interfaces
  2. styles, combinations and rules
  3. metaphors and models
  4. approaches and schools
The first level, components and interfaces works well for software objects, widgets, and API's. It would be our contention that this is as much a pattern as outlets, pipe sizes, and doorknobs are patterns for architects. While they are no doubt reusable and consistent across applications, they are not the central examples of patterns. The second level may contain patterns, although many styles and rules are to specific for the definition of patterns we would propose. Thus, rules like ``the file menu will contain open, close, save, and save as options connected to file dialog boxes'', are not patterns. Stylistic conventions at this level are like the rules of home design that specify a kitchen gets a 220 volt service to a grounded outlet or that a bathroom gets a fault tolerant circuit. On the other hand, styles, combinations and rules may specify higher level relations and these would be patterns. For example, ``the order of menu information should be related to ordering of action in the application'' may well be a style or rule that would be classed as as a pattern. For the most part, principles related to metaphors and models are patterns. For example, under the direct manipulation model, principles like ``make things visible and concrete rather than invisible and abstract''[15,9], begin to establish patterns to guide the analysis and design process. As these metaphors and models become all encompassing, we would suggest that they subsume sets of patterns under a common name. This would provide a parallel to schools in the architectural world such as modernism or bahaus. Thus we would suggest that ``ubiquitous computing'' or ``virtual reality'' suggest overall approaches to the interface that validate or invalidate the use of selected patterns. Thus, while affordances and mappings are important patterns for direct manipulation and virtual reality, they are less important for ubiquitous computing where transparency and immediacy become more critical.

In line with these views and definitions of a pattern we suggest the following operational definition of a pattern:

A pattern is an abstraction that may be instantiated. It is described by a simple phrase and relates to an observable or discernible aspect of the interface or interaction. Operationally, a pattern:
  1. has a consistent or corresponding meaning for by users, analysts, designers, and programmers,
  2. helps in resolving design conflicts by improving communications across the phases of system development,
  3. is relatively immune to changes in technology, and
  4. may be applied in multiple situations at both specific and general levels

next up previous
Next: Methodology Up: Patterns for Human-Computer Interaction Previous: Introduction


Michael Spring
Mon Nov 27 18:39:52 EST 1995