Erin Malone, co-author of Designing Social Interfaces, spoke at An Event Apart Minneapolis on the topic of “Patterns, Components, and Code, Oh My!” The session description was as follows:
Designing with patterns sounds like a great idea on the surface. But what does it really take to identify and write patterns? And just what do you do with them once they are created? Rounding out the pattern library with components and code can help prototyping and design move faster, leaving time to solve more challenging problems. This session will discuss the benefits of and issues that arise from designing with patterns, and show how to stay creative while doing so.
While I have started reading Erin’s book, I’m not to far into it, so this was somewhat unfamiliar ground.
Erin told us she would cover the following:
- Patterns
- What they are, why you should care
- Standards, Guidelines, Brands
- Where this fits
- Components
- How they are different from patterns
- Code
- Mapping a code library to a pattern library
- Patterns and toolkits
- Bringing them together
Brief history
- 1977–78
- Architect Christopher Alexander wrote books that identified patterns in architecture. He approached buildings in both a human and humane way, considering the use context for every solution. This design vocabulary was used to create a “pattern language.”
- 1987
- Cunningham and Beck used Alexander as a model to develop a small pattern lanaguage
- 1995
- Gang of Four publishes Design Patterns Book, which focused on software engineering
- 1997
- Patterns came to the web when Jennifer Tidwell presented an interaction pattern library called Common Ground.
- 2000
- Martin Van Welie releases pattern library to bring it online.
- 2002
- Design of Sites published
- 2004
- Erin Malone comes to Yahoo! Internal pattern library started.
- 2005
- Jenifer Tidwell publishes Designing Interfaces. Lots of classic stuff in there, apparently.
- 2006
- Yahoo! brings their interaction pattern library online along with the YUI component library.
- 2008
- Designing Web Interfaces and Designing Gestural Interfaces published.
- 2009
- Erin’s Designing Social Interfaces published. Lots more pattern libraries online.
The short version? Patterns began in architecture, moved to software engineering, and then to the web. More and more types of pattern libraries have emerged, and these have moved online for easier accees.
Pace layers
Erin reviewed the pace layer, a concept from Steward Brand, author of How Buildings Learn.
She showed a diagram of a building, with multiple layers. The diagram was somewhat confusing, but the concept is that buildings have parts that are “slower” or “faster,” assumedly in the rate in which they change. The fast parts learn, propose and absorb shocks, while the slow parts remember, integrate and constrain. The fast parts get the bulk of the attention in architecture, but the slow parts have power.
Websites, Erin proposed, also have pace layers. She ordered these from slow to fast as follows:
- Infrastructure/platforms
- Content
- Front end code
- Interaction specs
- Interaction pattrns
- Visual design
Erin advised us not to embed services in structure, because otherwise, you need to tear the house down to fix the services when they break. “Design welcomes change or fights it.”
So, the point of this is that you want to think smartly about how you structure things, so that you create something flexible but that will also stand the test of time.
Patterns
To begin the discussion of patterns, Erin showed us pictures of bridges, cathedrals and the Collosseum and asked us to indentify the design pattern common to all. The answer? Arches.
Each of these were very differrent buildings, but they had a common pattern, a need for weight distribution. An arch is a starting point, an underlying component, that is reusable in different contexts.
That’s what patterns are: optimal solutions to common problems in various contexts.
As an example, let’s say uou have a large amount of data. The user needs to see the details of an individual piece of data but wants the context that can be found in the overview data. A common pattern for this solution is to have an overview panel and a detail pane. An email inbox, for example, often has a pane with a list of messages and another pane with the particular email you are reading.
When you are defining a pattern, the essential problem is answering the question, “What does the user want?” A design pattern has five critical parts:
- What does the user want?
- Examples, which are archetypal solutions for that type of problem
- When to use this pattern
- How to meet user needs with this pattern
- Why this pattern is a good solution
A pattern library takes a particular thing like a login form and goes through the what, when, how, why and examples. This is not a visual guideline, but an overview of the various factors necessary to address the common issues related to that particular pattern.
For example, a buddy list is a pattern to use when doing instant messaging. A pattern library would list features common to buddy lists you might want to include.
Another example: tagging an object. A pattern for this would describe how you should allow users to add a tag and delete a tag, with instructions necessary to clarify how to separate each tag.
Accordions are another pattern. If you have a large number of options and constrained space, with logical groupings, an accordion might be a pattern that would be useful in solving that sort of a problem.
If you want to create a pattern, first do research. Common sources include research findings, product specifications and audits. Erin pointed out, “If you see something happening over and over, it’s probably a pattern.”
As a next step, create screenshots of examples you find, which serve as “sensitizing examples.” These can help generate ideas for a checklist and allow you to immediately see what a pattern is about.
Then, come upwith a to-do list for a solution, making sure to back up statements in the how field as necessary. Where is this solution appropriate? How is it different from other, similar patterns?
Make this solution findable by writing a problem statement, creating a designer-friendly title, assign it to a category in a collection and publish your findings.
You can flesh out a pattern by documenting open questions and special cases, adding links to supporting research and cross-refrencing related patterns.
Pattern libraries are just a staring point, not the last word. Patterns differ from specs and guidelines, which are more concrete.
Why patterns?
- Patterns help you to understand a variety of interaction problems within their various contexts of use.
- They can also help you to back up a decision you’ve made. This helps to build consensus.
- You can start with a usable solution, when you are designing something, rather than starting from scratch. This helps inform developers about solutions that already exist, because you don’t always need to design a unique solution, when existing solutions have already tackled certain problems.
- Patterns capture shared knowledge. This helps new team members get up to speed quickly.
Erin reiterated that what is really crucial is that interaction design patterns should be backed up by research.
Components
A pattern is a generic solution that could fit many different sites. Components, which are also known as stencils, are instances of a pattern for a specific design system. A particular brand might take various patterns and turn them into components, so that they have reusable items they can use within specific chunks of various pages. Put a number of components together, and like building blocks, you have suddenly created a page.
Components may be designed to work within a grid system and have prescriptive specifications, such as:
- Behaviors
- Formats
- Editorial
- Visual
In essence, components are the reference design, which can be used as examples in wireframes. These “design stencils” provide visualization for a pattern in a particular instance. They serve as the atomic elements in the chemistry of design.
Code libraries
Code libraries are useful in a way similar topattern libraries. Rather than starting from scratch, common functions are already created. When you get down to creating components for your project, you may want to map those to the code library elements necessary to make those components, and thus the patterns, work.
There are lots of code libraries already out there that can help fill your needs, as well as existing pattern stencil libraries, such as YUI.
For a particular component, it is important to look at the “interesting moments.” Define events for each element of the design at their key moments of use, from code-based events to user-initiated activities.
Pulling things together
Pattern libraries are more generic. A component will need UI specs and a visual skin or CSS to really sing.
A framework is a nested suite of patterns and components for a process or page.
Erin’s summation was that this is not rocket science, “You don’t need to reinvent this every time.” If you have patterns, components and code libraries, you have very strong building blocks from which to develop things.
Erin also mentioned that the public pattern library she has worked on is moving out of Yahoo! She is looking for volunteers to help.
My take
Pattern libraries seem very useful, in that they can help you to avoid re-inventing the wheel. They seem very time-intensive to create from scratch, which is why it’s great that there are existing resources out there to help.
When I had heard the term pattern libraries before, I had thought of something specific to a particular user interface, so I found it good to know that there are more generic aspects of patterns.
I work with a lot of smaller sites, so on one hand, creating a detailed system of components for some small sites might not be possible. However, with a good understanding of the various patterns out there, one could save on design time and take advantage of existing insights on how to solve problems. I like the idea of avoiding re-inventing the wheel.