When it’s an antipattern? No, that’s a different blog post.
Actually, what I’m thinking about this morning is the drift in meaning of the word pattern, as used in the sense of a design pattern.
Going back to Christopher Alexander, the “pattern language” concept started off with a fairly strict, well defined structure. Alexander’s patterns all have a sensitizing example, a context (when to use or apply the pattern), a problem (expressed in terms of conflicting forces), and a solution (a way to balance or reconcile those forces). Application of the pattern produces a new context (and hence a way to “chain” patterns together).
The pattern language, then, is a vocabularly of patterns that relate to each other. In Alexander’s work, there was a hierarchical, or scale, dimension. His A Pattern Language book starts at the level of nation-states across the world and works its way down to things like doorknobs.
When the extreme programming folks involved with Ward’s wiki and the “Gang of Four” adapted the pattern metaphor to software engineering, they did not really preserve the pattern language concept. They also debated among themselves between what they called descriptive and prescriptive patterns (actually, I’d better check if those were the real terms they used). They were aware of the Alexander precedent and conscious at least about which parts they were applying to the computer software context. (Alexander himself foresaw and promoted this application, btw, in the 1980s.)
Later, the design pattern idea was adopted by HCI folks (and thus user-interface designers and so information architects and interaction designers). Pattern repositories began to be referred to as pattern libraries, but still the example, context, problem, solution model survives to a large extent. There’s a mailing list where user-interface pattern authors discuss these things, partly as a way of maintaining some commonality among our various libraries and while there are many more possible elements in a pattern, there’s a fairly strong consensus around those core “fields.”
The pattern “meme” if you will is strong. The metaphor is easy to understand and its spread somewhat outstrips the more formal concept. So this has lead, in the web-design world, to a slightly more loose sense of the word pattern. The meaning is similar: it refers to emerging solutions to common problems. What gets lost in translation is the formal structure for documenting and defining the patterns.
This may not be a bad thing, but it is a thing, so I am noting it. Over at the microformats wiki, they will speak of design patterns and then write up a sort of plain-English colloquial description of it. Nothing wrong with that, right? I agree, but part of me wonders if that’s really a design pattern or is it more like notes toward a design pattern or an unfinished or unwritten design pattern. Or maybe we need a different name. A design pattern sketch, or a design habit?
Likewise, factoryjoe has been compiling a fascinating and useful collection of interface images, recently noted in Metafilter. When I write (or help develop) patterns for the Yahoo Pattern Library, I am nearly always asked for more visual aids. More examples, more diagrams, more animations, and so on. Thus, I applaud any effort to audit what’s out there and thereby document patterns, emerging and well established, good and bad (the latter being those aforementioned antipatterns).
To me, these pattern galleries, as I like to call them, are a perfect complement to the formal written patterns. They take the concept of the sensitizing example and extend it. This is only a good thing. I just question whether the collections of images are themselves patterns. Aren’t they really, if anything, illustrations of patterns?
Of course it’s possible, in Flickr and elsewhere, to annotate the images, or comment on them (and people do). There’s nothing stopping an intrepid pattern-illustration capturer from writing up a context/problem/solution triplet for each set. But without that, I’m going to lean a bit old school here and say they aren’t really patterns.
This is probably a lot of inside baseball for most folks. If it weren’t my job to curate a design pattern library I probably wouldn’t worry about things like this myself.
When is a pattern not a pattern?
3 responses to “When is a pattern not a pattern?”
we’ve spoken about this a little in person at IA Summit, but I’ve done a bit of writing on the issue.
I agree right now, what most people seem to be doing is documenting examples of possible patterns – which is I think really important – the next step is to start formalizing these patterns – I know Yahoo is doing quite a bit in this space ;-)
I understand the distinctions you make. The design pattern concept for architecture, is composed of recommendations that have a feeling of stasis to me, whereas design solutions for the screen interactions (web in particular) seem to me constantly shifting as technology changes and as new interface behaviors emerge.
I want to be aware of what professionals propose as patterns based on what has been done, and the needs that have existed for types of projects historically. But my personal use of them is only for reference. It stops when I sit at the drawing board to consider solutions relevant to my current problem.
I wonder if people leaning on patterns too much might lead to the fear of experimentation and innovation. Some patterns might be dead on delivery as soon as someone creates a better solution.
But I agree, we’re throwing the design pattern term around loosely, only maybe to make the discussion alive and organic–to contribute to the conversation about what constitutes a recommended solution, and challenge the recommendations that we might not agree with.
I feel you. Still, I suspect it never knows what has worked for other people in advance of starting a new design. One is always free to deviate from a pattern and I’ve never personally experienced patterns as limiting or domineering the realm of possibilities.