AODC day 3 – Pattern language for information architecture
Last week I attended the 2009 Australasian Online Documentation and Content Conference (AODC) in Melbourne. This blog post is part of a series about some of the AODC sessions I attended.
Here are some notes I took from the session on a pattern language for information architecture, by Matthew Ellison. I hope these notes are useful to people who couldn’t be at the conference this year.
Pattern Language for Information Architecture
Matthew introduced pattern languages by saying that they may give you a practical way of capturing the techniques that work for you — a way of documenting the golden rules.
A pattern language is a structured method for describing good design practices within a specific field. Michael Hughes has done a lot of work on pattern languages in our field. Pattern languages establish a rule of thumb. They do not offer a rigid solution, but something you can use again and again when similar situations arise in a particular environments.
Pattern languages in architecture
Pattern languages were first developed about thirty years ago, originating in the architecture field. Matthew was very taken with Christopher Alexander’s book A Pattern Language: Towns, Buildings, Construction (1977). It even smells nice, says Matthew. The structure of the book, its pictures and diagrams, and the quaint language make it a book you can dip into and enjoy. It covers a wide field, from the design of towns down to the design of doorknobs.
Matthew showed us an example pattern from the book: “A Place to Wait”.
- The pattern starts with the problem: “The process of waiting has inherent conflicts in it.”
- Then it proposes the solution. As an example of the quaint language used: the pattern suggests that you should “…fuse the waiting with some other activity — newspaper; coffee; pool tables; horseshoes… where you can draw a person waiting into a reverie; quiet…”
- Then there’s a really cute little sketch of what a waiting area might look like.
Pattern languages for UI design
Another field that uses pattern languages is user interface (UI) design. Matthew showed us what such a pattern formula (template) might look like. Once again, they start with a statement of the problem, then tell you where such a pattern would be used. Next the pattern offers a solution and some form of illustration.
One such pattern in UI design is “Pagination”. Matthew showed us how the list of pages at the bottom of Google search and various other sites all fit this pattern.
Pattern languages for information architecture
What do information architects do? There are a few definitions. A good one is that information architects are responsible for the overall organisation of content.
How can design patterns help? They allow content providers to apply tested architectures to improve the user’s experience.
Matthew listed the following types of design patterns:
- Interface and layout (window and page layout).
- Structure of information and navigation dynamics (TOC, related links, popups).
- Content (information types, writing style and the way we assemble the content we write).
An example of an information architecture pattern: “Breadcrumbs”. The problem is: Users need to know their location in the document’s hierarchical structure, so that they can browse back to a higher level in the hierarchy. Matthew showed us some examples of breadcrumbs in various applications.
Suggested components of an information architecture pattern:
- The problem.
- Usage (where the pattern is used).
- The solution (a short bulleted list that describes the golden rule — fairly flexible and not too prescriptive).
- An illustration.
- The rationale (the reason why you would use this solution).
Matthew took us through some more information architecture patterns: “Content taxonomy”; “Signposting”; “Popups”. I don’t have any notes from this part of the session — I got too wrapped up in watching the examples. Matthew is sure to have the details🙂
Michael Hughes proposed a design pattern for contextual help, to determine when and how we might use such help. Matthew showed us an example of embedded help from Microsoft Excel that conformed to the design pattern.
We looked at some design patterns in a few state-of-the-art online documents. One example is the UK Daily Telegraph online newspaper. Matthew discussed the design objectives of this site, and how they might relate to online documentation too. Notice the design elements, such as:
- Signposting and visual breadcrumbs, near the top of the page.
- Search, always at the top. Search is very important in all online newspapers.
- List of related articles.
- Related RSS feeds.
- Link to in-depth background information that supports the story.
- Link to feature article.
Comparing a sports report and a current affairs item, they are visually and spatially very much the same. This makes it easy to use these newpapers online.
We also looked at a government site showing UK planning and building regulations. It also has a standardised pattern, with each element in a predictable place.
How can we define our design patterns?
Matthew suggests the following steps:
- Create your pattern statements (problem, usage, solution, rationale, etc).
- Decide whether the pattern statements fit into a style guide.
- Decide whether to enforce your patterns, e.g. by building them into an XML schema or DTD.
There are different opinions about whether a design pattern would fit into a style guide. IBM talks about enforcing your design patterns in structured authoring via XML, e.g. as DITA topic specialisations or map domains.
Thank you for another very cool and informative presentation, Matthew.
Posted on 27 May 2009, in AODC, technical writing and tagged AODC, documentation, information architecture, matt, Matthew Ellison, pattern language, technical documentation, technical writing. Bookmark the permalink. Leave a comment.