Design patterns provide us with an approach to the design of technical information that is familiar in a print environment but provides a new approach for the design of Web-based information. Recently, Glenn D’Amore, Senior Director at ADP Payroll Services, pointed me toward an interesting new book, The Design of Sites: Patterns, Principles, and Processes for Crafting a Customer-Centered Web Experience by Douglas K. Van Duyne, James A. Landay, and Jason I. Hong (Addison Wesley, 2003). The focus of this book is on the design of customer-oriented Web sites.
More recently, members of the IBM DITA (Darwin Information Typing Architecture) development team, Erik Hennum, Don Day, John Hunt, and Dave Schell, published an article about applying design patterns to technical information and describing how to implement design patterns for a topic-based information architecture using DITA maps. See the full article at http://www-106.ibm.com/developerworks/xml/library/x-dita7/.
The current use of design patterns had its origins in architect Christopher Alexander’s 1977 work, A Pattern Language: Towns, Buildings, Construction (Oxford University Press). The patterns that Alexander and his colleagues created were focused on creating communities and buildings (homes, facilities, gardens, playgrounds) that were people-focused rather than designer-focused. Patterns help to create a common language that designers can use to relate their own designs to a more useful and human whole.
In The Design of Sites, the authors invent a pattern language that accounts for many aspects of the design of customer-oriented Web sites. Some of us already use common patterns in Web design, such as the use of standard task bars and left-column navigation. But the authors go beyond these examples to introduce designs that might affect how customers browse, search, or personalize information on a site.
Similarly, the DITA team argues that standard patterns are also applicable to technical information. If we were to devise a language of design patterns that pertain to the communication of technical information, we would offer a common approach to our users across product lines and even across company boundaries.
We might, for example, devise a pattern for “how to …” information, a mainstay of technical information development. In their example of a “how to …” pattern, the IBM authors suggest a structure by which we might identify and communicate the intent of a particular pattern to the authors.
The structure consists of a pattern name, a statement of context, and a solution. The “how to …” pattern is described as follows:**
|Pattern name |
The user needs to accomplish a goal but may not know some of the background or steps. Some users will need to learn the entire activity while others will only need to refresh their knowledge. The goal can be described as a distinct activity.Solution
Provide a collection of topics that explains the concepts the user must understand, lists the tasks the user must perform, and provides examples of how the goal is accomplished. The tasks are the required core of the how-to collection. The collection sequence is
This simple “how to …” pattern describes what many of us would find in the manuals that we develop. The point, however, is that a pattern, once defined in this manner, is used in every content collection developed by the department or larger organization. The same pattern is, in fact, repeated over and over in the development of a print book, a help system, or an information-rich Web site. In each different medium, however, the pattern might be rendered in a way that takes advantage of the medium’s strengths. While such a pattern might be rendered sequentially in a print book, it might be rendered as a set of tabs in a help system or a group of navigation panes on a Web page. The solution, from a pattern language perspective, would remain the same.
The advantage that a stable pattern language provides to the reader of the information is consistency. All the “how to …” collections are organized in the same way. The reader comes to expect the pattern to be repeated in every similar situation. The stable structure creates confidence that the information will be thorough and complete in every instance.
For the writer, the stable pattern language provides an opportunity to depend upon the structure to organize topic-based content into predictable structures. It even allows the writer and the writer’s organization potentially to automate the movement of the topics into the patterns using DITA’s topic maps.
In the rest of the article on design patterns, the IBM authors explain how to implement a standard design pattern using a specialization of the standard DITA topic map. The topic map provides a shell into which topics are dropped. By specializing the topic map, the standard structure of the design pattern is reinforced programmatically.
Some of you will already be creating topic maps for your documentation. Standard content plans for installation, maintenance, administration, and so on have long been part of the information-development tool kit. In my 1994 book, Managing your Documentation Projects, I explain in detail how to develop a content plan for a documentation set, using an understanding of the user’s goals and activities in relationship to the product. I know that many information developers include content plans as a standard part of their development life cycle.
Design patterns extend the content plan concept one step further. By developing a standard set of content plans not only for different document types but also for collections of topics within those document types, we are developing a pattern language for the information within our organization. A second step for CIDM members to pursue might be to begin the development of a common pattern language between our organizations rather than only within. By establishing industry-wide best practices through a common language of design patterns, we would assist new organizations and writers in getting started, create a standard for ourselves, and emphasize the importance of information architecture in the profession. And, the DITA model would give our pattern design initiative a technology base that is far more appropriate to technical information than the DocBook model that is more representative of the book-publishing industry.
**This example appears on page 2 of the article “Design patterns for information architecture with DITA map domains,” Erik Hennum, Don Day, John Hunt, and Dave A Schell (IBM, 17 September 2004).