Working With a Pattern Library Day to Day

[Part 7 of a series on Patterns. Working with a Pattern Library.]

Patterns, Components, and Code, Oh My!

Ok, so now you have a pattern library. Now what? Ultimately, you need to be able to work with this content on a daily basis. The patterns, in and of themselves, give you the tools to understand the variety of interaction problems and various contexts of use. They also explore the considerations you need to address and resolve for your particular context. The patterns should give you all the rationale you need, with research and examples, to back up your decisions and know that you are starting with a usable solution.

By itself the pattern library informs, builds consensus, and captures shared knowledge BUT it’s hard to use in the real world when designing against a deadline. What a pattern does not do, is give you a working object that can be plugged into your sketches, wireframes, prototypes or final solutions. You need to be able to drop these solutions into your specific context for prototyping, for testing with users and for final builds.

With that in mind, you should consider the pattern library as just one part of a master toolkit. The pattern library should be the foundation for the entire toolkit which can be used by the entire team, including developers.

So what goes into the toolkit?

• a robust pattern library
• visual design guidelines and brand examples
• wireframe stencils of pattern instances or components
• foundational elements like grids
• related code components that map to the stencils and patterns

Each pattern in the library can be considered a hub around which all these other elements revolve.

The working objects that revolve around the pattern are specific instances of the pattern. Just like the sensitizing example in your pattern, which is an instance of the pattern in the wild, the code, component or stencil, css and specs are specific implementations of the pattern that can be used in your designs and even final builds. Ultimately, having this toolkit aids in adoption by the entire design and development team as it helps reduce inefficiencies and promotes reuse where appropriate.

In my experience, pattern adoption works best when engineers have reference and example code and can build solutions out of components just as the designers build experiences out of the patterns and stencil components.

Pattern + Stencil + Code = Very strong building block

So what do I mean by Component?

A component is a reusable, design system-specific chunk of a page.

Also known as modules, chunks, portlets, widgets, blocks, or other labels depending on the design context – are put together – like building blocks to create an entire page.

Components might have a specific application within a page grid, like a header or footer, and usually have prescriptive specifications for behaviors, formats, editorial, visual style, design rules and variable treatments needed for implementation. In the case of components that take advantage of ajax, they should include an interesting moments grid and behavioral guidelines.

In a pattern library, the component should be a reference design that follows agreed upon interactions and brand standards. For agencies, the component should be a generic, best case instance that can be skinned for various client needs.

Comparing Patterns and Components

Nathan Curtis, the expert on designing with components, has developed this matrix which defines patterns and components against a variety of points. He uses this to make a nice comparison between the two, which helps differentiate between them.

I don’t agree with his definition that a component has to be targeted to a specific location in the page. This may make sense as you are defining your grid system, i.e. Social tools widget always goes in the middle right column, etc. especially for a content CMS driven site. But the decision of placement as part of the definition of a component needs to be part of the design process and is related to the defining of your grid and module system and may not be appropriate at all for a web application or mobile experience.

In general, components may have location as part of their definition, but that location is dependent on the context of a SPECIFIC design system and not consistent to all design systems. You can develop components to use across projects, across clients or across different design systems for the greatest flexibility.

For designers, components might take the form of stencils that can be loaded as libraries for applications like Omnigraffle, InDesign, Axure, Fireworks etc. The Yahoo! pattern library team and others in the UX community, like Loren Baxter and Michael Angeles have released stencils that map to the patterns for many of these applications. Systems like EightShapes Unify bring a component based library set to InDesign.

All these solutions are used to aid in the design process and promote reuse while reducing the process of reinventing the wheel every time the designer sits down to work. Many designers I know have created their own personal, reusable set of stencils and design elements. The Toolkit formalizes this for use by an entire team. This is not unlike reusable code-libraries in use by development teams. It also means that designers can more easily share work and trade files with each other.

Code, code, code

Libraries like the YUI, jQuery, Silverlight and others are similar in concept to an interaction design pattern library. This is the part of The Toolkit that is most relevant to developers.

As seen by the rise of reusable AJAX libraries, code libraries are useful tools for developers to deal with standard and common interactions. Having a code snippet that maps to each pattern and component wherever possible means that teams can easily flesh out common interactions and rapidly prototype solutions.

Having a code library also means that your development team can focus on the more complex, unique interactions and features. They can spend time working on performance issues, database issues, crafting new code snippets to new patterns and other unique, one-off problems that often get short shrift because of the everyday, common features.

A few of the more common component libraries and frameworks include: Flex, Laszlo, Silverlight and 12 Ajax frameworks and toolkits: ExtJS, Dojo, YUI, Google Web Toolkit, Prototype/script.aculo.us, JQuery, MooTools, MochaUI, SproutCore, LivePipeUI,IT Mill, Backbase. (list compiled by Theresa Neil and Bill Scott)

Each of these has a set of components, of which many might map to a common pattern library set. The 30 components reviewed and covered by Bill Scott and Teresa Neil, span across all these different libraries.

[singlepic id=74 w=000 h=320 float=none]

The most usable toolkit for your company or team, might be a mix of off-the-shelf and custom components collected together with associated patterns, visual specs, css and stencils.

Interesting Moments Grids

The interesting moments grid was developed and promoted by Bill Scott while he was at Yahoo! It’s a great tool to develop collaboratively with your development team. He describes it as a storyboard or document that should accompany an interaction design specification which explains what happens to each element at key moments of use.

Defining each of these moments means that nothing is left to chance and every moment and behavior has been designed for the best outcome for users and for the best performance for the web application.

The Interesting Moments grid may be bound to code-based events or user initiated actions. Whatever the event of action, they all need to be discussed and defined. [drag and drop story board template | inline editing storyboard template ]

These documents are a great opportunity for interaction design and development to collaborate together. Both at prototype time and development time, the exploration of these actions and timings are as much about the user experience as an understanding of what’s happening with the code in terms of load time and what can be supported efficiently.

Figuring out Where to Start

For any organization, the success or failure of the pattern library and associated toolkit is going to be in how to approach the collection and codification of these tools in the most efficient, usable way possible.

For some teams, that means doing the research and writing work needed to create a pattern library from scratch. For others, it means pulling patterns out of existing specification documents. For another, it might mean developing a code library and then mapping the patterns back to it with rationale to support long term use of these solutions.

You can back out of a component library into patterns as long as you remember which level each belongs on. Patterns don’t dictate look, location or placement. They have a generic feel to them and that gives them an evergreen quality. The problem, solution, when to use and rationale for the decisions made in the solution should be valid regardless of media or technology. Your component on the other hand will dictate a lot of specific design, like placement of elements, timing of animations and ajax motions, specific labeling and even finished look and feel.

Small teams should spend their time collecting patterns and components from the large number of libraries available open source and spend their time documenting the deltas between them and their specific needs. This will cut down on a lot of work reinventing the wheel and will force the team to make decisions about what is specific and important to their organization.

Regardless of how you start, remember that the most thorough and usable toolkit, will have pieces that can be used by designers and developers day to day, backed up by the deeper foundational work of the patterns themselves.

Next up: How Visual Design Works in the Toolkit