UIEtips: Components Versus Patterns

Jared Spool

August 31st, 2010

The Vulcans had something good with that mind-meld thing. Just put your fingertips on someone else’s forehead and your two minds become one. I wonder if Vulcan designers used that technique to ensure everyone knew how to come up with a coherent, integrated design, even though they all worked on different pieces?

Without the mind-meld thing, we have to resort to more primitive approaches to get everyone on the same page. In the past, we’ve tried templates, guidelines, and style guides. However, these have not proven to be very effective and end up frustrating teams more than helping the design process.

A few years back, we started seeing the emergence of pattern libraries as a solution to this problem. However, recently our research has shown us that pattern libraries only get you so far. For the rest of the solution, a component library can fill the gaps.

We’re revisiting an article that Nathan Curtis wrote for us in January 2009. Nathan does a great job outlining what patterns and components are and how they’re related. I think you’ll find this article quite beneficial and a good refresher if you’re already working with patterns and components.

Read the article, Components Versus Patterns.

If you’re thinking a pattern or component library can help your team be more efficient and create better designs, then you’ll want to check out Nathan’s full-day workshop: Standards, Reuse, Consistency, & Libraries. Nathan received rave reviews on a similar workshop he presented at the Web App Summit in 2009. Get more details on his workshop and the other 7 at http://uiconf.com.

User Interface Conference FifteenNathan is presenting at this year’s UI15 conference. Explore his workshop and the other full-day workshops. Planning on attending? Register by 9/9/10 for the lowest rate.

2 Responses to “UIEtips: Components Versus Patterns”

  1. Toddles Lightworker Says:

    Maybe I’ve picked up a strange mis-interpretation of “pattern library” here. It seems to me that “pattern library” is some form of “pattern language” that includes ready built but flexibly applied solutions? But this seems a very strange comparison “component libraries” with “pattern language libraries”. Component libraries are built using a specific component technology – perhaps Java Beans – and are used to build software. The rationale for using of a component or set of components in a context – can be expressed as a pattern in a pattern language. And what’s more the template solutions for patterns expressed in a pattern library can be expressed using components. Why would you choose to do one or the other? The idea behind using a component is not one that is in anyway replaced by the pattern library. These two tools or ways of thinking about the world are about different sorts of things. Components are about being able to build from parts, they are designed to communicate with their environment in such a way that they can be all be used in a standard (design?) editing environment (for the technology). Whereas Pattern Languages are specifically about the “rationale” – why this solution or design works given this or that situtation for this or that purpose. I dont get this – why are we trying to compare “component” with “pattern”?

  2. Colin Williams Says:

    Toddles, seems to me that you’re mixing metaphors. This article deals with interface design. You seem to be making the leap to software design.

    Jared, thanks for the article. Understanding the differences between patterns and components is extremely useful in organizing CSS files when working on Web projects. I tend to substitute the term “device” for “pattern,” since pattern is such a flexible concept. (A lot of visual designers make the leap from pattern to plaid, stripes, floral, etc, too quickly.)

    I always have three CSS files for a project: elements.css, devices.css, and components.css. Elements set the tone for everything (a, p, h1, h2, ul, etc). Devices use elements and conventions to implement common patterns: tabs, menus, accordions, etc. (typically implemented via classes: .tab-group, .menu). And finally, components are specific implementations of a device (#navigation, #top_stories, etc).

Add a Comment