Following on from my previous post on taking a framework agnostic approach to documenting UI patterns I wanted to talk about creating a pattern index as a counterpart to a pattern library, or as a useful tool for anyone designing within a large web estate.
As with many things, an innocuous looking question sparked a train of thoughts and ideas that lead me down this road.
“What should we do in the event we need UI elements not covered by the pattern library?”
Our pattern library is a collection of user interface design patterns that solve common and recurring design problems. Tried and tested solutions that have been developed over time specifically for us, with both our brand and users in mind.
The best approach to developing a pattern library is to build from the ground up alongside a site as it developed, acting as the canonical design and technical specification of itself. However we had a need to create ours retrospectively, so logically started with the utilities (the grid, buttons, forms, icons, typography, navigation) and a few patterns (masthead and footer) that were required to give a distinct and consistent user experience to our web estate. We then have taken an iterative (agile) approach adding new patterns as needs emerge, allowing it to grow organically. All patterns have been ‘refactored’ directly from jisc.ac.uk, improving code quality and design, as well as developing practical guidance on how, why and when to use.
However, has following this approach meant we have missed an opportunity? What about all the patterns queued up ready for ‘refactoring’ when their need arises? And what about the uncommon patterns that may never make it into our library? We always envisaged that as part of our guidance there would be an ‘in use’ section that would give examples of where patterns from our library have been implemented in our web estate. But what about all these other great patterns that are littered through our web estate?
Creating the guidance required to make all the UI patterns in any web estate reusable would be an enormous task, but creating a pattern index that collects examples and references is much more manageable.
A ‘pattern index’ defined
Wikipedia describes an index as:
“… a list of words or phrases (‘headings’) and associated pointers (‘locators’) to where useful material relating to that heading can be found in a document or on a page. In a traditional back-of-the-book index the headings will include names of people, places and events, and concepts selected by a person as being relevant and of interest to a possible reader of the book.”
I describe a pattern index as:
A list of UI patterns and associated examples to where useful material relating to that pattern can be found in a web estate. An index of patterns, interactions, transitions and concepts selected by a person(s) as being relevant and of interest to anyone working with its counterpart pattern library.
A pattern index is intended as a wayfinding tool, a place to find examples and references of where UI challenges have been met–much like ui-patterns.com–within your web estate. It should be as useful to those new to developing in your web estate as those responsible maintaining it. A pattern index should help to ensure consistency by documenting all the instances where patterns are used for quick reference, whether they’re in a library or not.
“You only need to visit any higher education site to see examples of this [inconsistent UX]. Navigation shifts position, form elements are formatted differently and even typography changes. This happens because it is easier to guess how a button might look then find out how it was styled in the past.” – Paul boag on How and why to create a pattern library.