"In this network, the links between the patterns are almost as much a part of the language as the patterns themselves."

Christopher Alexander in The Timeless Way of Building

Hierarchy of Parts

A hierarchy of parts is not a formal part of a pattern language, but constructing such a hierarchy is a good way to begin defining a pattern language, as suggested by Alexander and others in some early treatises on the Pattern Language. Many parts are given, especially those of nature, and cannot be changed by design. But the existence of some other parts in a design are themselves patterns, because they help to resolve problematic forces at the interface of other parts, or they respond to a basic human need.

Pattern Components

It may be useful to compare the descriptions of pattern components with some patterns that use this format.

For software:
Color Is Information
Colors In Context
Colors For The Colorblind
Consistent Link Colors

For ecosystems:
Downstream Water Volume
Carry-off Irrigation

Some authors who have adopted the idea of a Pattern Language, such as some of those for object-oriented programming in software, have deviated from the format used in A Pattern Language. We also note that patterns are similar to documents used in Structured Planning, often referred to as Problem Elements or design factors. Indeed, these documents may evolve into full-fledged patterns. But without certain critical elements, a collection of patterns fall short of being a pattern language.

Here we will stick very close to the anatomy of patterns as published in A Pattern Language by Alexander et al. However, we will also include some elements that existed in early incarnations of the Pattern Language, which we feel are particularly useful in constructing new pattern languages. We will also include some elements we find useful for managing a language under development, and for putting patterns on the World Wide Web.

1. A Title which is used to refer to the pattern. Titles are chosen to fit into the natural discourse of discussions about the design (per linguist Noam Chomsky), hence, a pattern language. On the Web it is advisable to repeat this title within the TITLE tag.

2. A key Visualization which illustrates the pattern. This may be a photo, diagram, sketch or anything else that captures the pattern's essence. Note that this is optional - not all patterns in A Pattern Language have a key visualization - but they help with memory and giving people an image that exemplifies the "goodness" of the pattern.

3. Parts/Contexts, i.e., a description of one or more parts and contexts to which the Pattern applies. A Pattern Language does not include this element in patterns, but we note that this work publishes the 253 patterns that Alexander et al deemed the most generic, the most universal. Many other patterns exist which apply to specific parts or social, cultural or ecological contexts. For example, the Center For Environmental Structure itself published other patterns for a multi-service center, and for housing in Peru.

   It is our opinion that citing the parts and contexts in which the pattern is relevant is useful for finding those applicable to one's situation, and on-line can be useful in searches.

4. Keywords to help determine the application of the pattern. This also is not an element of patterns published in A Pattern Language, but keywords would assist finding patterns that apply to a specific project, especially on-line. For patterns on the Web, we recommend also placing the same keywords inside a META tag for the benefit of search engines.

5. Predecessor Patterns describe how patterns that apply to larger parts, hence are implemented before this pattern if possible, relate to this pattern. This is the section in A Pattern Language that begins with an ellipsis (. . .) to indicate continuity from the predecessor patterns that refer to this pattern.

   Note that for a given project you may not have the ability to directly implement predecessor patterns. For example, in implementing patterns for a house, one likely has no control over the surrounding urban design. But one should review predecessor patterns nontheless to see how implementing this pattern can help complete them.

   On the Web make the predecessor pattern titles hyperlinks if they are also on the Web.

6. The Problem Summary, or headline states the essence of the generic problem. To get at the underlying forces bearing on the problem, the Problem Summary is often stated as a loosely dependent clause using conjunctions like if, because, while, where, unless or when.

7. The Analysis section contains information describing the context or circumstances in which the problem exists, an explication of the functions and forces involved, and analysis of experiments or other proofs of validity, etc.

8. The Solution Summary is an imperative statement that begins with Therefore that describes design action that would resolve the forces causing the problem.

9. Successor Patterns tells what patterns next in the language sequence apply to smaller parts, and are therefore implemented after this pattern to complete it. On the Web make the pattern titles hyperlinks if possible. In A Pattern Language successor patterns are followed by an ellipsis (. . .) to indicate continuity.

10. References/Sources can be personal observations or experiments as well as bibliographic entries.

11. Author/Date performs an administrative function in a team effort, and if the date is a revision date, it lets the user know when it has been updated.

    In early versions of the pattern language each pattern included a list of authors together with the statement:

    This pattern is tentative. If you have any evidence to support or refute its current formulation, please send it to the Center for Environmental Structure (address); we will add your comments to the next edition.

    We feel that such a statement is extremely useful for a pattern language that is under development.

12. Return to Pattern Index. For patterns on the Web this element provides a link to the master index or table of contents. This provides a navigational aid, supplementing the network of hyperlinks for predecessor and successor patterns.

13. Copyright Notice. In the spirit of "information should be free", we suggest a copyright notice that gives permission for non-profit academic use, for example:

    © Your Name, 1996. Permission to copy this pattern for non-profit academic use is granted so long as this copyright notice is retained. To copy otherwise requires specific permission.

    We note that early working versions of A Pattern Language encouraged copying in order to promote both the idea of a pattern language, as well as the individual patterns to help improve the environment.

Feel free copy our Pattern Template to compose your own patterns. Comments in the HTML source code provide directions.