What is a Design Pattern and Why Use Them for Quince

What's a Design Pattern?
Now some of you, looking at Quince, may be wondering what a design pattern is, or maybe you're just curious about the approach we took in authoring them because there are a number of ways to do it.  Design patterns have many representations, of course, but we chose to go with a somewhat more Alexandrian approach (after Christopher Alexander, the early pioneer of design patterns as formal ideas).  The idea of "design pattern" is actually sort of hard to define well--many people have tried.  It's one of those things you sort of just get better after seeing examples of them.  But here's my go: 

A design pattern is a generic solution that has been observed in multiple instances to help resolve a particular problem within a known context.

Patterns are not algorithms--they're not rote solutions that always produce the same solution given the same inputs--that's the "generic" part; actual pattern implementations should vary based on the particular situations in which they are applied.  Patterns are not innovations--that's the "multiple" part; if the pattern has not been observed in multiple solutions or if it is something you have dreamed up and can, e.g., patent, it is not a pattern--yet.  Patterns, as such, are discovered, not invented; they can come from an invention, but they must be seen to apply in multiple solutions.  Lastly, it's important to recognize that patterns only apply in certain contexts, under certain conditions--just recognizing the problem and matching the solution is not enough; that's the "context" part.

So, given all that, we went with this approach in discussing the patterns:

• Problem - a concise statement of the situation (Alexander talks about forces) that potentially calls for the pattern.
• Solution - a concise statement of what this pattern entails in addressing the problem.
• Context - additional conditions and considerations that help you know when to use the pattern.
• Rationale - an explanation of why the pattern works--why it is an effective solution.
• Implementation - a step-by-step overview of how to make this pattern real for you.
• Examples - examples of how others have made it real to give you inspiration and a better sense of the pattern.

Why Design Patterns?
It's fair to ask why we chose to make a UX design pattern explorer.  There are certainly other ways to communicate best practices, but design patterns are a well-established mechanism for communicating best practices in a way that addresses the complexities involved in real design problems.  As Alexander says in his Timeless Way of Building, the patterns are there whether we verbalize them or not--they make up the vocabulary of a pattern language that can be used to build things that are whole, livable, complete, and alive (words that incompletely describe what he calls "the quality without a name"). 

They have other practical benefits, too.  They are smallish, so they can be digested in chunks.  They have well-known names, so these can be used in design conversations as part of our jargon that makes communication more efficient and effective.  They can be composed--you can use patterns together to create good overall experiences.

Formalizing and verbalizing the patterns into libraries is one step towards helping us as software makers come to a more conscious realization of what it is we are doing, helping us to communicate better--more precisely--and ultimately contributing to a greater implicit understanding of good design.  And once you really know the language, you no longer need it.

Why UX and Not UI?
This is one other question that tends to come up in discussing Quince.  Although a number of pattern libraries do use the term "UI," we thought that UX was a better choice for Quince.  The reason is that while particular, individual UI patterns are interesting, good, and valuable (and we have a good number of these), what really makes for great user experiences is a holistic focus on the full experience, the full story of interaction that people have with software. 

What I'd call a UI pattern would be one that roughly maps to either UI control/widget (like a Date Picker or Drop Down Chooser) or a particular view (such as Grid Layout or Dashboard).  These are sort of like the basic building blocks for good UX design, and in as much as they contribute to overall user experiences, they are UX patterns as well. 

Yet there are patterns that are just as, if not more, important than these individual elements of designing interfaces.  These are patterns that likely span multiple individual interfaces and address the higher-level experiences that people have with software; these are the ones that more directly address user goals and types of interactions; these are, simply put, user experience (UX) patterns.

Some examples we have of these are Few Hues, Journal Navigation, Search, Undo, and Visual Framework.  These kinds of patterns and even higher level ones that address particular types of common interactions can build upon the foundation of the individual interface patterns--helping us to use them together in ways that ultimately result in creations that have the quality without a name.  When you start thinking about these kinds of patterns, you can see that we have only begun to scratch the surface, and that's part of the reason we've opened Quince up for others to propose patterns.  We'll only find so many on our own!

Finally, we want to encourage a UX way of thinking, which has a distinctive focus and intent to start your designing from the people who use the software.  These people have a totally different perspective on the software than we creators typically have, and they perceive software in terms of touch points in a broader experience or story that they live.  It is this way of thinking about software that we want to and should encourage, and that's another reason for opting for "UX" over "UI."

So I hope this helps address some of the more theoretical thinking behind Quince.  If you're still not sure about design patterns, just try using Quince and reading some of the patterns.  Once you get a feel for more concrete examples, I'm sure it'll make sense to you.

Have fun exploring!

--Ambrose