[Part 3 of a series on Patterns. Understanding the concept of the reusable solution.]
Identifying patterns in architecture
The first thing you have to do before you can write an interaction design pattern is to understand how to identify patterns in the wild. When is something a pattern, when is it a principle or a best practice. What about guidelines or style guides or standards? Many of these terms are used interchangeably. Keep reminding yourself of the definition of a pattern.
A reusable, proven solution to a problem in a context.
Since we adapted the idea of patterns from a language in architecture. Let’s look at some examples from architecture before thinking about patterns in interaction design.
Here is a simple architectural item – the arch. According to the Oxford English Dictionary, the basic arch is a a curved structure spanning an opening or supporting the weight of a bridge, roof, or wall.
We see through the ages that this architectural solution is a reusable and repeatable solution in a variety of contexts.
In ancient rome, the coliseum as well as the aqueducts, were constructed using a series of connected arches. These supported the walls, the floors above them and provided openings for people to come through.
The use of the coliseum was quite different than an aqueduct, their contexts different, yet the solution, the reusable pattern of the arch is the same.
In pre-gothic europe, the great cathedrals being built utilized the arch in a unique way by combining two to four of them intersecting around a circle to create a vaulted interior of grand space.
Again, a very different use than the coliseum or aqueduct but using the same architectural pattern to solve a uniquely different problem.
In modern times, with the advent of building with steel, most buildings now only use the arch as a decorative rather than a structural element.
An exception to this can be found in Nagoya Japan, with the Nayabashi Bridge. Originally built over a canal excavated in 1610 and then stone using the arch as a major supporting structure, it was rebuilt in 1913 with steel utilizing the same design, using the same architectural pattern of the arch to solve the problem of supporting the bridge across a span.
These examples show of a variety of contexts with different problems to solve. You can see how this repeatable and reusable item – the arch – is a pattern that can be used to solve each of these specific problems.
Identifying patterns in software and on the web
In interaction design, we can point to similar types of reusable and repeatable solutions that can then be labeled interaction patterns.
There are many times when a person has a large amount of data to deal with and they need to be able to easily navigate and act on it.
iTunes has containers in the left pane and the list of objects from the container in the right panel.
Susy has a lot of mp3s. She wants to be able to browse them and sort through them by different attributes (i.e. title, artist, year, album etc.). Additionally she wants to be able to group many of the songs together under different names like Good Driving Songs or New Year’s Eve Party Songs.
An interface that has a constant left pane for organizing groupings and a right pane that shows the contents within a grouping, with all being the default would address the user need described above.
A common mail application shows accounts and folders in the left pane and the contents of an account or folder in the right panel.
Joe receives a lot of mail. He wants to organize his mail by accounts and into groupings that are meaningful to him.
The same model of interaction as described above, a constant left pane for organizing and right pane for revealing the contents of a group would address this problem. A variant would add a third bottom pane showing the contents of an individual item from the list.
Google Reader, an RSS feed reader show feed sources on the left and the contents of the feed in the right panel.
The interaction pattern here is the left pane / right pane solution and it can be applied to various contexts equally successful. This is what makes it a pattern. The specifics change, the visual implementation may change, the code underneath may change but the inherent interaction model is the same.
Let’s look at another example.
A user wants to sign into a web site to gain access.
Sign in is a pretty common interaction across the internet. Most sites however only have one sign in form but the interactions are common when looking across the internet as a sample set.
At a minimum the user needs to provide some sort of unique identifier and a password. There is a method for submitting the sign in data whether it’s a unique button or just hitting return on the keyboard. This is the basic interaction that a user would go through.
This solution, a unique identifier field, a password field and a method to submit to the system, can be defined as the basic interaction pattern for sign in.
There are variants and optional items that can be added to this pattern but we will discuss that later when we talk about writing interaction patterns.
To recap, here is the definition of a pattern again:
an optimal (or proven) solution to a common problem within a specific context
Patterns are used like building block or bricks. They are fundamental components of a user experience and describe interaction processes. They can be combined with other patterns as well as other pieces of interface and content to create an interactive user experience. They are technology and visually agnostic and we do not prescribe either of these. Interaction design patterns give guidance to a designer for how to solve a specific problem in a context in a way that has been shown to work over and over again.
A pattern also captures the situation, competing constraints and provides a canonical solution.
It is repeatable and is an archetype.
Next: What’s all this I hear about Anti-Patterns?