In Chapter 2 I introduced the idea of Design Systems. In this chapter I’d like to introduce the idea of ‘pattern langauges’ as I begin to explore the ‘Components → Patterns → Pages…’ part of the interface equation.
A pattern language is a system for cataloguing and describing good design practice. The term was coined in 1977 by the architect, Christopher Alexander (who I’ll return to shortly). Essentially pattern languages are used to gather tried and tested solutions to design problems, for example, a login pattern that’s been shown to work through testing.
The thinking behind pattern langauges pre-dates design systems by quite some time.
Pattern languages, as they relate to user interface design, were popularised by Pattern Tap, an influential website established in 2008 by the prodigiously talented Matthew Smith, which popularised the thinking behind pattern langauges and design patterns. Sadly, Pattern Tap is no more, lost – as so many websites are – to the ravages of lapsed domain names. You can, however, explore it via the Wayback Machine.
IMAGE /* This needs an image here showing the collections overview. */
CAPTION: Pattern Tap saved you re-inventing the user interface wheel by gathered a wealth of design patterns for inspiration.
Pattern Tap collected examples of user interface design patterns, largely as applied to the web. As Smith put it:
Imagine one place where you can drink deeply of great design patterns. Imagine there’s no more war. There’s no more dissent. You don’t have to sludge through design after design for the best pattern inspiration anymore.
The site allowed you to browse curated /* Were they curated? I can’t recall. */ collections to find design patterns that solved a particular problem you were dealing with. It’s collections included:
- forms;
- breadcrumb trails;
- navigation;
- logins; and
- footers.
Imagine you had to include a form on a website you were creating. **Pattern Tap was useful for seeing design patterns for forms that others had designed to address this problem. **As with my note of caution about Dribbble in Chapter 2, the intention of Pattern Tap wasn’t to provide designs to raid for aesthetics like a Viking, it was to provide different ways of tackling a problem – patterns – that designers could learn principles from.
/* What I’m trying to say here (and need to be clear on) is that Pattern Tap was about design principles – methods, approaches… – not surface-level, aesthetic inspiration. */
/* **This section, about Alexander’s book, might be flagged up as ‘you should read it, but you can skip it if history’s not your thing’. (See my comments below.) That said, I think it’s important. */
Long before Pattern Tap existed there was Christopher Alexander’s 1977 book ‘A Pattern Language: Towns, Buildings, Constructions’. Few have read the book, but Alexander’s thinking has certainly shaped where we are today. One of two books – “two halves of a single work” – ‘A Pattern Language’ was preceded by ‘The Timeless Way of Building’.
Together, these books provided, “a language, for building and planning,” and, “the theory and instructions for the use of that language,” and were the result of eight years of practice and thought.
/*
This needs a little more clarity, i.e.: Alexander’s intention was to codify an approach towards building (in an architectural context) and establish a library of patterns from which an architect could draw. His book gathered examples, as in the illustration below. This still needs more to draw out the idea that underpins ‘A Pattern Language’.
This looks interesting:
Maybe content worth adding. This abstract also summarises it well, use a blockquote:
A Pattern Language by Christopher Alexander is renowned for providing simple, conveniently formatted, humanist solutions to complex design problems ranging in scale from urban planning through to interior design. This text is also believed to be the most widely read architectural treatise ever published.
cityterritoryarchitecture.springeropen.com/articles/10.1186/s40410-017-0073-1
The above says, “It is only one part of a trilogy of works documenting Alexander’s ‘second theory’ of architecture…” Check this. I thought it was one half (perhaps in parentheses add that, ultimately it became one of a trilogy of works). In Alexander’s book he says there are two books, a third was – perhaps – added later.
*/
IMAGE: Redraw from the book perhaps, as I doubt we’ll have the £s to license an image.
CAPTION: Whilst Alexander’s work focused on architecture, the underlying methodology can be applied much more widely.
Replace ‘building’ (house) with ‘digital product’ and a great deal of Alexander’s thinking maps over.
It’s worth noting that Alexander points out – within the book’s opening paragraphs – that ‘A Pattern Language’ (specifically the one introduced in his book) is one possible pattern langauge, i.e. it is not the only possible pattern language.
Put simply: there are many possible patterns and the ones you choose will be influenced by your goals and your intended audience (and to a degree your individual aesthetic preferences).
/* I hope people follow along with this as it’s important. I’m worried that some people will love this, but others will want to get down to business, but I think this needs to be included, not least as Alexander is regarded as the father of the pattern language movement. */
/* What this is missing, is the application of ‘A Pattern Language’ to software, etc.,. This is well-documented and I need to tease it out at the end of this part so that I bridge into the next part, moving on to explore patterns in software, and by extension, user interface design. */
I’m working on this section just now, so it’s a bit of a work in progress.
What I want to explore in this section is the idea that we can build an encyclopaedia, or dictionary, of examples (similar to Matthew’s work with Pattern Tap). This encyclopaedia will prove incredibly valuable over time as you encounter new problems and new challenges.
/* I could also just use ‘library’ of patterns as I did in Chapter 2, when I used ‘A Library of Components’. (And – as this is about patterns – maybe I should use that pattern! */
It’s a good idea – especially in studio downtime – to collect examples of the different design patterns you create on projects. These can be useful to show clients examples of how typical design challenges are addressed. (A series of forms, for example.)
Each pattern has:
- a clear name;
- an image;
- a descriptive entry; and
- cross-references.
Applying this to user interface design this might be:
- a payment form;
- a screenshot;
- an example of a payment form (for Get Invited) that’s used to gather customers’ credit card details;
- links to other payment forms you’ve designed for other projects. (So, for example, you can show clients alternative patterns.)
Just as Aexander’s thinking could be applied to the construction of buildings and, at a larger scale, towns, it can also be applied to user interface design. Indeed, Alexander is regarded as the father of the pattern language movement and his impact on software design is widely acknowledged.
/* Essentially, this is where I introduce the idea – that I established in the previous chapter - that we’re building a library, a set of patterns, created from objects and components, that we’ll combine in different ways as we build our interfaces. */
The following is from Wikipedia, it captures what I want to say, but needs to be rewritten:
When a designer designs something – whether a house, computer program, or lamp – they must make many decisions about how to solve problems. A single problem is documented with its typical place (the syntax), and use (the grammar) with the most common and recognized good solution seen in the wild, like the examples seen in dictionaries.
Each such entry is a single design pattern. Each pattern has a name, a descriptive entry, and some cross-references, much like a dictionary entry. A documented pattern should explain why that solution is good in the pattern’s contexts.
Just as it’s important to consider the consistency of your components so that they meet a wide range of diverse needs, cohesively, so too it’s important to consider the consistency of your patterns.
Using the objects and components, that I explored in the previous chapter, to create patterns is where things get interesting. We can build, from the ground up, a consistent set of elements that we can then orchestrate within pages.