Our Articles ...
On Complex Documentation
On Complex Documentation
What Technical Writers Can Learn from Christopher Alexander's Pattern Language
by Jonathan Price
Draft of Interface Feature for IEEE Transactions on Professional Communication
Publication Referred to: C. Alexander, S. Ishikawa, M. Silverstein, with M. Jacobson, I. Fiksdahl-King, S. Angel, A Pattern Language: Towns, Buildings, Constructions. New York: Oxford, 1977
Index Terms: Pattern, pattern language, object orientation, object-oriented rhetoric, styleguide, standards
In a series of books  - , Christopher Alexander, an urban planner and architect, has inspired object-oriented programmers with his idea of a pattern language-originally, a catalog of solutions to common problems faced by any community or individual creating a livable structure such as a town or a house. His approach might also help technical communicators polish and perfect our own standard rhetorical structures (such as the procedure, user guide, or reference), viewed as common ways of answering frequent, if virtual, questions from our users . Alexander's way of describing age-old patterns such as neighborhoods, streets, paths, and homes may give us a model for creating our own set of patterns in technical communication, whether or not we adopt some of the eager elaborations offered by folks in the object-oriented design world. What's a pattern? For Alexander, a pattern is a practical guide to resolving any problem that occurs over and over, such as how to lay out common ground for a town square, or punch a hole in a wall for a door. In A Pattern Language , he and his team have created each pattern out of the same elements:
The methodicalness with which Alexander carries out this analysis seems to appeal to the orderly nature of many engineers, even when the subject matter is apparently outside of their discipline. In A Pattern Language  Alexander discusses 253 patterns in 1171 pages (an average of 4.6 pages per pattern). He organizes these patterns by scale, from largest to smallest, considering the distribution of towns before "activity nodes" within towns, which appear before any actual buildings, which in turn appear before parts of buildings, such as alcoves.
The sequence resembles what object-oriented programmers call a composition diagram, in that the larger patterns often require a dozen or more medium-level patterns as components, and those mid-level patterns themselves assume the lowest-level patterns as subcomponents. For example, Alexander loves the idea of a town green like the ones that grew out of common grazing areas in Europe and New England. In pattern 60 he adapts this idea, arguing for a little green within or around a small cluster of houses or workspaces, as a relaxing common space within three minutes walking time from anyone's door. He calls this pattern the "accessible green" [4, pp. 304-309] and argues that such a green will help define a neighborhood or work community, provide a tangible boundary between one group's area and another, and form a quiet backside to the houses that stand between it and a road. In turn, the green should contain pleasant outdoor spaces, plenty of trees, and, ideally, a wall against which people can plant a garden.
Here's how Alexander describes the componentization here:
In object-oriented terms, each pattern has several component relationships with other patterns. As Alexander says,
Such sensitivity to context grows out of Alexander's fundamental view of the world: It says that when you build a thing you cannot merely build that thing in isolation, but must also repair the world around it, and within it, so that the larger world at that one place becomes more coherent, and more whole; and the thing which you make takes its place in the web of nature, as you make it 94, p. xiii].
This spiritual quest for wholeness-at many levels-gives Alexander's writing a depth and resonance we rarely encounter in technical works. He sees his inspiration coming not from contemporary architects, urban planners, and landscape designers, but from the genius of hundreds of generations of ordinary people around the world-the folk who created roads, houses, town squares, and windows in the first place. He is looking for "a timeless way of building"  or at least one that has been sanded and polished by many generations of people reacting to common problems. He seeks the essence of their solutions, so that, as he puts it, each solution "contains only those essentials which cannot be avoided if you really want to solve the problem. In this sense, we have tried, in each solution, to capture the invariant property common to all places which succeed in solving the problem" [4, pp. xiii-xiv].
How do Patterns Form a Language?
Alexander offers these patterns to designers and non-designers alike as a language, by which he means a way of expressing one's self, in space. He argues that conventional architects have so denuded the landscape that most ordinary people have forgotten that they themselves can build perfectly attractive houses, neighborhoods, and work spaces-if they only had the "grammar" and "terms" to speak in that way. The languages which people have today are so brutal, and so fragmented, that most people no longer have any language to speak of at all-and what they do have is not based on human, or natural, considerations [4, p. xvi].
He sees himself as resurrecting patterns that are archetypal-"so deep, so deeply rooted in the nature of things that it seems likely that they will be a part of human nature and human action as much in five hundred years as they are today" [4, p. xvii]. He is speaking of architectural elements such as the arcade, but in his somewhat-Taoist, somewehat-Platonic approach, he holds out the possibility that if we use these patterns we will make our own spaces more livable.
And, as with any language, the most condensed expression has the most poetry. It is possible to make buildings by stringing together patterns, in a rather loose way. A building made like this is an assembly of patterns. It is not dense. It is not profound. But it is also possible to put patterns together in such a way that many, many patterns overlap in the same physical space: the building is very dense; it has many meanings captured in a small space; and through this density, it becomes profound [4, xli]. This hope for a quintessential solution and extreme compactness of delivery may also appeal to engineers such as object-oriented programmers, who see that they have been creating similar solutions over and over, but dream of seeing the one simplest and best solutions, for extremely efficient code.
How Object-Oriented Programmers have Evolved the Pattern Language
Alexander's work has dovetailed with many of the concerns of object-oriented programmers  - . For instance, several of these programmers , , , , , , , ,  were concerned with:
As Rising  says, "A pattern is, on the surface, simply another form of documentation." In this sense, any technical communicator who is documenting a program written in an object-oriented language such as C++ or Java will find Alexander's work an inspiration, and prototype. But for the programmers, patterns offered something much more than annotated code. As Rising  says, "The power of this kind of documentation is that knowledge previously found only in the heads of experienced developers is captured in an accepted form that can be shared." Patterns gave the field a way to mature, by creating handbooks of best practices. Patterns also share a number of characteristics with programming objects, according to Lea :
And the process Alexander envisions people using to apply the patterns echoes many of the activities on an object-oriented team, according to Lea : piecemeal development, frequent iteration, prototyping, collaborative development, participatory design, decentralized work that must eventually fit together in an integrated whole.
Patterns, then, caught the imagination of the object-oriented programming community because Alexander's approach offered a method for documenting successful objects, and, in turn, patterns resembled high-level objects, while the process of turning a pattern into a plaza or home also resembled some of the activities on an object-oriented team. Patterns have become a way of sharing ideas in this community, and although many engineers have developed much more elaborated models, with as many as a dozen or more elements, the approach began with Alexander, and for many technical communicators, Alexander's writing will seem more sympathetic, humane, and understandable than some of these no-nonsense, hard-hitting analyses of software patterns.
How Technical Communicators May Learn from Alexander
First, we can come to appreciate the value of a methodical analysis of each "solution" we use, whether large (a help system), medium (a language manual), or small (a quick start guide). Patterns are what we may have been groping toward in many of our styleguides, in which we offer tidbits of advice from managers and editors, with occasional examples of templates, and final output. Among the many problems with current styleguides ,  is the fact that they are often inconsistent, including some analysis for some elements, but not for others, and focusing more on format than on purpose, with little or no discussion of context (higher level patterns this one forms a part of, or component patterns within it). Of course, writers are not as enamored of regular analysis as engineers are, but a more methodical consideration of the important elements in our documentation might provide advice that people could really follow, particularly if we were to add an Alexandrian analysis of the rhetorical context (what's the problem that this particular element solves? What user question are we answering here?). Thus, our styleguide would offer considerations of all the following for each element, regarded as a rhetorical object  - :
An Alexandrian approach also deepens our rationale for the standard elements in our documents, casting them not as arbitrary decisions made by some unseen editorial board, but as a response to certain types of questions raised by users over and over, not just in our own organization, but in others like it, for dozens of years. In other words, a patterns approach considers a procedure as a generic form developed by many teams interacting with thousands, even millions of users, over many, many years. The structure may vary slightly from place to place, under local circumstances. But the essence of the form, its formal structure, remains solid, the result of all that social polishing. Each pattern, then, describes an element-an illustration, a migration guide, a glossary item-as a rhetorical object, the writer's equivalent of a programming object. And whenever we begin using object-oriented databases to store our information, or work in languages like SGML or XML that allow us to tag the content as well as the format, then the pattern analysis provides us with clearly defined descriptions of each object, from a writer's point of view, while the tag itself tells the software what kind of object it is, in programming terms. The more information we must handle, it seems, the more likely we are to need patterns to help us create humane, aesthetically pleasing, and enduring information objects for our users.
 C. Alexander, Notes on the Synthesis of Form. Cambridge, MA: Harvard, 1964.
 C. Alexander, The Timeless Way of Building. New York: Oxford, 1979.
 C. Alexander, M. Silverstein, S. Angel, S. Ishikawa, D. Abrams, The Oregon Experiment. New York: Oxford, 1975.
 C. Alexander, S. Ishikawa, M. Silverstein, with M. Jacobson, I. Fiksdahl-King, S. Angel, A Pattern Language: Towns, Buildings, Constructions. New York: Oxford, 1977.
 C. Alexander, Ed., with H. Neis, A. Anninou, I. Fiksdahl-King, A New Theory of Urban Design. New York: Oxford, 1987.
 W. Brown, R. Malveau, H. McCormick, and T. Mowbray, Anti-Patterns: Refactoring Software, Architectures, and Projects in Crisis. New York: Wiley, 1998.
 D. de Champeaux, D. Lea, and P. Faure, Object-Oriented Systems Development. Reading, MA: Addison-Wesley, 1993.
 P. Coad, "Object-oriented patterns," Communications of the ACM, Vol. 35, No. 9, pp. 152-159, 1992.
 P. Coad, D. North, M. Mayfield, Object Models: Strategies, Patterns, and Applications, 2nd Edition. Englewood Cliffs, NJ: Prentice Hall, 1996.
 J. O. Coplien, Advanced C++: Programming Styles and Idioms. Reading, MA: Addison-Wesley, 1991.
 J. O. Coplien, Software Patterns. New York: SIGS Books, 1996.
 J. O. Coplien and D. C. Schmidt, Eds, Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995.
 S. Dasgupta, Design Theory and Computer Science. Cambridge, UK: Cambridge University Press, 1991.
 M. Fowler, Analysis Patterns: Reusable Object Models. Reading, MA: Addison-Wesley, 1997.
 R. P. Gabriel, Patterns of Software. New York: Oxford, 1996.
 E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Systems. Reading, MA: Addison-Wesley, 1995.
 A. Goldberg, and K. S. Rubin, Succeeding with Objects. Reading, MA: Addison-Wesley, 1995.
 IEEE Software Special Issue on Objects, Patterns, and Architecture, January, 1997.
 D. Lea, "Christopher Alexander: An introduction for object-oriented designers," Software Engineering Notes, ACM SIGSOFT, Vol. 19, No. 1, p. 39, 1994.
 L. Rising, The Patterns Handbook: Techniques, Strategies, and Applications. New York: Cambridge University Press, 1998.
 L. Rising, "The road, Christopher Alexander, and good software design," Object Magazine, Vol. 7, No. 1, pp. 46-50, 1997.
 L. Rising, "Design patterns: Elements of reusable architectures," in Annual Review of Communications, vol. 49. Chicago, IL: International Engineering Consortium, 1996, pp. 907-909.
 T. Love, "Timeless design of information systems," Object Magazine, November-December, p. 46, 1991.
 E. Yourdon, Object-Oriented Systems Design. Englewood Cliffs, NJ: Prentice Hall, 1994.
 D. W. Bush and C. P. Campbell, How to Edit Technical Documents. Phoenix, AZ: Oryx, 1995.
 J. A. Tarutz, Technical Editing: The Practical Guide for Editors and Writers. Reading, MA: Addison-Wesley, 1992.
 J. Price, "Structuring complex interactive documents," Introduction to a special issue (same title) of the IEEE Transactions on Professional Communication, July 1997, pp. 69-77.
 J. Price, "Using complexity theory to understand what's happening to technical Communication," in IPCC 97 Proceedings, October 22-25, 1997, Salt Lake City, Utah. IEEE Professional Communication Society, 1997, pp. 17-27.
 S. Mazumdar, W. Bao, Z. Yuan, and J. Price, "Adding semantics to SGML databases." Presentation at Electronic Publishing '98 Conference, Saint Malo, France (April 1-4, 1998), and to be included in the proceedings volume, 1376 in the Lecture Notes in Computer Science Series, Springer-Verlag, Berlin, 1999.
 J. Price, "Complexity theory as a way of understanding our role in the World-Wide Web," in Proceedings of the 45th Annual Conference. Arlington, VA: Society for Technical Communication,1998, pp. 207-209.
Copyright 1998-2001 Jonathan and Lisa Price, The Communication Circle
Return to our site at http://www.theprices.com/circle
Email us at JonPrice@AOL.com