It’s great to see design pattern libraries like Yahoo!’s getting a lot of attention these days. I’ve been working on planning one for a client recently and thinking a lot about what makes them successful. In short, I think the newer, popular ones are immediately useful, meaning you can directly insert the pattern into your work during the design process. This hasn’t always been the case.
Roughly ten years ago, interaction designers started to see how patterns were used by programmers and began writing their own patterns, just as Christopher Alexander knew people could. I was part of this wave, for example with this short paper introducing the topic to my colleagues.
But many of the patterns at the time were a little too clever. And the books that came out (and that are still coming out) are a little too abstract to be useful. Instead of giving one concrete observation of a design artifact with an example we can immediately use, they go one level of abstraction higher, in the hope that more generalized descriptions will last longer and be more widely applicable. But this just requires too much work from the typical reader; people have enough constraints to deal with, they want the answers.
Pattern languages so far haven’t been good design tools. Christopher Alexander himself realized that pattern languages didn’t do a good job of helping to generate coherent designs or objects. The ones that seem to be most useful like Yahoo!’s and Welie’s (and templates and stencils and the recent wave of AJAX frameworks) are fairly concrete — you can look at a pattern and copy it (sometimes downloading examples and code). They offer patterns that help people execute a design rather than do design.
And while Alexander et al’s original book is thoughtful and philosophic, it also focuses on concrete examples.
