From: "Jared M. Spool" <[email protected]>
Date: January 9, 2009 9:23:11 AM PST
To: "Daphne Ogle" <[email protected]>
Subject: UIEtips: Components Versus Patterns
Reply-To: [email protected]
UIEtips: Components Versus Patterns
1/9/09
Contents:
- Letter from the Editor
- UIE Web App Summit: Special iPod Offer for Tips Readers
- Feature Article: Components Versus Patterns
- UIE Virtual Seminar: The Road to Informed Decisions
- o - o - o -
--> Letter from the Editor
Greetings,
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.
That's why we're thrilled that Nathan Curtis is presenting at this
year's Web App Summit, to help us navigate the pattern and component
library world. And, for today's UIEtips, he's got a great article
that explains the differences between the two (and why you may need
both).
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 seminar: Achieving Reuse with Patterns
and Components. We're excited about this brand new seminar and think
it's perfect for teams looking to get uniformity and increase
development speed, without sacrificing creativity. See the details
here: http://cli.gs/QXgMRr
Have you considered using a pattern or component library for your
project? What moves have you made in that direction? We want to hear
you stories -- talk to us at on the UIE Brain Sparks blog:
http://cli.gs/YLNdg1
Enjoy today's article,
Jared M. Spool
Editor, UIEtips
- o - o - o -
--> UIE Web App Summit: Special iPod Offer for Tips Readers
Breaking news! We still have a limited supply of iPod nanos, and as
a UIEtips subscriber, we want to give you one. When you register for
the UIE Web App Summit ( www.webappsummit.com )
and use the promotion code 'TIPS', you'll receive a limited-edition
Web App Summit iPod nano.
Just register by Thursday, January 15, 2009 not only will you get
the lowest available conference price, you'll also get your very own
limited-edition Web App Summit iPod nano.
At the UIE Web App Summit, you'll meet the innovators and
world-class designers behind today's most successful web apps.
We've carefully crafted this four-day Summit to include two days of
intensive full-day workshops on form design, Ajax, RIAs, design
deliverables, wireframes, accessibility, design patterns, and web
standards.
Remember, supplies are limited so take advantage of the special iPod
offer and register no later than January 15.
http://webappsummit.com
And don't forget your promotion code 'TIPS'
- o - o - o -
--> Feature Article: Components Versus Patterns
Editor's note: We've asked Nathan Curtis to present this April at
the UIE Web App Summit on Achieving Resuse with Patterns and
Components. In this article, Nathan discusses the differences
between patterns and components.
Invariably at the outset of planning a component library,
stakeholders will query “Ah, yes, so we are building a pattern
library?” Actually, no. Although the two concepts are strongly
related, their differences warrant consideration to ensure you are
building the type of library that’s right for you.
What Is a Pattern?
A pattern is a global solution to a common design problem, such that
you could use the solution many times and never quite use it the
same way twice.
For example, there’s no reason for a designer to not employ the
common tenants of tabs (such as at least two tabs are required),
video playback (that can be played or paused), or authentication
(that, at a minimum, requires some form of username and password).
Patterns are essential in interaction design, serving as a basis for
designers to apply common, consistent conventions whether or not
those solutions are actually catalogued in a library specific to an
organization.
What Is a Component?
On the other hand, components are a reusable, design system-specific
chunk of a page. Such components - also known as modules, chunks,
portlets, widgets, blocks, or other labels depending on the design
context - are aggregated to compose an entire page or view. Each
component has a specific application within a page grid and may have
prescriptive specifications for behaviors, formats, editorial,
visual style, and variable treatments.
How Are Components and Patterns Related?
Patterns and components can be quite complementary and coexist
within design solutions, even if (almost always) they are not the
same thing.
Consider the home pages for two different experiences, fancast.com
and comcast.net, both properties owned by Comcast Interactive Media
and mapped together via navigation back and forth between sites. The
two home pages could be broken down into components (represented by
orange boxes), many of which are reused on other pages of each
experience. Each home page also employs many
patterns (identified by the red callouts). View graphic at
http://tinyurl.com/7loznj
Are the components and patterns the same? Not at all. The two design
solutions share no components whatsoever, existing within entirely
different visual systems of grids, typography, layout, color, and
navigation models. However, the two page designs share (at least) 5
patterns, including search, authentication, carousel, headlines, and
tabs.
Component Design Inspired by a Pattern
Often, many components in a library will utilize the same pattern.
For example, consider the tab pattern that enables a designer to
segment content into sections, all accessible but only one visible
within a layout at a given time. On cnn.com, tabs are instantiated
into numerous components for grouping financial markets by global
regions (Asia, Europe, US, view graphic at
http://tinyurl.com/a8nmnq), article content by type (read, video,
map, or chart, view graphic at http://tinyurl.com/7yrsop), and
videos by category (most popular, top stories, staff picks, and more,
view graphic at http://tinyurl.com/8l3p4j).
In every case, the design adheres to the fundamentals of a tab
pattern, such as distinguishing the active tab from other tabs.
However, the usage, page region, style, and design details differ
considerably across each component.
Reconciling a Pattern from Components
Similarly, inconsistencies across many component designs can be
reconciled into a pattern to establish a common baseline across
teams and efforts.
For example, consider countless video players proliferating
needlessly throughout the sections and contexts of a website:
embedded in a product spotlight, a different player in a different
spotlight, unique players in lightboxes & popups, new players for
content from the training group, etc. Built by different teams at
different times, the designs all play video amid UI controls with
inconsistent behavior and appearance.
Teams can resolve differences via a pattern for basic facets like
play/pause, scrubber, timing (current and overall duration), and
volume. With a pattern in place, consistency increases but teams can
still flexibly include (or omit) additional controls and features —
video size, full screen view, rating, commenting, embedded code —
for a specific component in the context of their solution.
How are Components and Patterns the Same?
Both patterns and components are reusable design solutions for
specific problems. This reuse — and the consistency and cost-savings
that result — is the key selling point of both patterns and
components.
In addition, patterns and components can be:
* Described via attributes like Use When, Rationale, and Solution
Guidelines
* Managed in a library
* Rendered as reusable assets, whether HTML/CSS frameworks or design
libraries used in wireframe or comp production
* Utilized during projects by information architects, interaction
designers, visual designers, design technologists (ie, HTML/CSS/JS
jockeys), and other disciplines
* Authored and maintained via a (hopefully well) defined workflow
* Based on the design needs of an organization
*Influenced and enhanced based on user research
How Are Components and Patterns Different?
Despite their similarities, components and patterns differ in
important ways. At a high level, patterns are meant to serve as
baselines open to interpretation and application by a designer; on
the other hand components are quite specific to an established
design and thus more prescriptive and fixed.
Additional distinctions include:
Types
Patterns: Could be a page chunk (log in module), flow (shopping
from product to cart to checkout to receipt), behavior (e.g.,
autocomplete), or something else
Components: Always a chunk of page or screen design
Specificity
Patterns: Globally applicable across a range of contexts, even
if elements are similar
Components: Specific to one design system, including layout,
color, type, and behaviors
Location
Patterns: Up to the designer to appropriately apply principles
and locate within a screen design
Components: Targeted to specific location(s) within a page
layout, based on approved usage
Style
Patterns: Abstracted from any specific skin, and flexible to
adapt to many visual treatments
Components: Finished within one visual system, although
variations may be defined
Editorial
Patterns: Perhaps some basic editorial guidance
Components: Specific data, formats, guideline, style/tone, and
even defined feed
Markup & Code
Patterns: While starter code may be available, it needs to be
tailored to fit the system
Components: Ideally represented by formalized html, javascript,
and CSS if the library is built
How It Works
Patterns: Represents how a design should work, under preferred
conditions (but may suggest how to cope with tradeoffs)
Components: Represents how a design does work, inclusive of the
tradeoffs and constraints established during the design process
What Kind of Library Should You Build?
Since the two library types are different, then which one is right
for you?
Patterns are ideal for teams that design many experiences, such as a
team like Yahoo’s that designs a plethora of products each with a
unique visual system but needing to adhere to a larger, common
brand. Components have proven ideal for other teams, such as Sun
Microsystem’s sun.com library that synthesizes a massive collection
of pages, sections, teams, and content into a common, single design
system and experience.
But, this may not be an either / or question, since depending on
your circumstances, you may benefit from one or both types of
libraries. In fact, one team built libraries for both patterns
(e.g., Tabs) as well as components (e.g., tabbed product details,
tabbed content module, tabbed search results, etc). Other teams have
hedged their bets by embedding aspects of one approach into the
guidelines and spirit of the other, most commonly via pattern-like
guidelines incorporated into the more specific component
definitions.
Consider a pattern library especially if your team has:
* Numerous visual systems that are intentionally different or will
not be reconciled
* Capability to document patterns more specific than public
libraries already in existence
*Known opposition to prescriptive approaches, but a willingness to
use common guidelines
Consider a component library especially if your team has:
* A specific visual design system, including grid(s), layout, color
palettes and typography
* Many reusable components (page “chunks”) within that system
* Diverse groups (and resources within disciplines) across an
organization that must work together to evolve and publish against
using that system
* Interest in and capability of sustaining that design and code
system across groups, projects and time
* Strong, centralized influence to create, deploy, and maintain a
library (or plans to centralize influence via a library)
+ + +
Read the article on UIE's web site at: http://cli.gs/pQSTtS
+ + +
Want To Learn More on Components and Patterns?
Nathan Curtis will present at UIE's Web App Summit on April 21,
2009 in Newport Beach, CA on Achieving Reuse with Patterns and
Components. A perfect seminar for those looking to expand their
organization’s design capability, while keeping control over the
look and feel of the web applications they’re producing.
Read about Nathan's session: http://cli.gs/vqMhUT
+ + +
Share Your Thoughts with Us
As always, I want to hear your thoughts on this topic. Join the
discussion about this week's topic on UIE's Brain Sparks blog:
http://cli.gs/YLNdg1
- o - o - o
--> The Road to Informed Decisions, with Jared M. Spool
Event: Upcoming UIE Virtual Seminar
Date: Thursday, January 15, 2009
Time: 1:30pm ET / 12:30pm CT / 11:30am MT / 10:30am PT
Duration: 90 minutes
More details at:
http://www.uie.com/events/virtual_seminars/The_Road/
Every design consists of thousands of decisions. Smart,
well-informed decisions lead to a great design, while poor,
uninformed decisions result in something users despise. Making the
right decisions is critical to the design's success.
In this online presentation, Jared M. Spool will share
state-of-the-art techniques to get from observation data to informed
decisions. He'll show you the best practices for teams to organize
chaotic data, develop consensus, bring objectivity out of subjective
observations, and produce clear design recommendations. You'll learn
how to maximize your research investment with a concrete set of
analysis techniques.
For a limited time we're offerring the Archive of this presentation
at no additional cost when you register with the promotion code
MYARCHIVE. Sign up today!
http://www.uie.com/events/virtual_seminars/The_Road/
+ + +
Do you have feedback or comments on our article? Send us your
thoughts on the UIE Brain Sparks blog at http://tinyurl.com/9d27cl
---------------------------------------------------------------
This message was sent to you as a result of your previous business
interactions with User Interface Engineering.
You are currently subscribed to uietips as: [email protected]
To change this email address go here:
http://www.uie.com/uietips/change/[email protected]&cID=11776824E
To unsubscribe go here:
http://www.uie.com/uietips/unsubscribe/[email protected]&cID=11776824E
Did a friend forward this email to you? Would you like to get your
own copy? It's easy. Just visit: http://www.uie.com/uietips/
-------------------------------------------------------------------
User Interface Engineering
510 Turnpike St., Suite 102
North Andover, MA 01845
Phone: (978) 327-5561 or (800) 588-9855
Fax: (978) 327-5568
http://www.uie.com
