Fwd: UIEtips: Components Versus Patterns

Tue Mar 3 23:16:32 UTC 2009

Interesting article below.  He is defining components as much more  
prescriptive than we think of them.  In fact, he would probably say  
Fluid components are patterns.  I don't think I agree.  However, he  
makes some interesting points and has brought me back to a long  
standing questions we've had...

How do Fluid components relate to the design pattern library?  Should  
they somehow be included there?   This is a complicated  
question...perhaps one to discuss at an upcoming design meeting?

The other idea this article give me is in the way we describe  
components.  One gap that has been gnawing at me is how do people know  
when to use which components?  In the article, Nathan Curtis, says a  
commonality between patterns and components is that they can both be  
described in the same way -- like we describe patterns in the library  
-- with use when, why, rationale, etc.   Would it be helpful for our  
audience to have these kinds of descriptions for components?

-Daphne

Begin forwarded message:

> From: "Jared M. Spool" <jared.m.spool at uie.com>
> Date: January 9, 2009 9:23:11 AM PST
> To: "Daphne Ogle" <dogle at umich.edu>
> Subject: UIEtips: Components Versus Patterns
> Reply-To: jared.m.spool at uie.com
>
> 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: dogle at umich.edu
> To change this email address go here: http://www.uie.com/uietips/change/?cEmail=dogle@umich.edu&cID=11776824E
>
> To unsubscribe go here: http://www.uie.com/uietips/unsubscribe/?cEmail=dogle@umich.edu&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

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090303/1e8e142f/attachment.html>