Comments on: UIEtips: Components Versus Patterns http://www.uie.com/brainsparks/2010/08/31/uietips-components-vs-patterns-2/ UIE\'s latest insights on the world of design Wed, 22 May 2013 21:10:52 +0000 hourly 1 http://wordpress.org/?v=3.4.1 By: Colin Williams http://www.uie.com/brainsparks/2010/08/31/uietips-components-vs-patterns-2/comment-page-1/#comment-152586 Colin Williams Wed, 01 Sep 2010 02:37:17 +0000 http://www.uie.com/brainsparks/?p=2517#comment-152586 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). 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).

]]> By: Toddles Lightworker http://www.uie.com/brainsparks/2010/08/31/uietips-components-vs-patterns-2/comment-page-1/#comment-152585 Toddles Lightworker Tue, 31 Aug 2010 22:32:11 +0000 http://www.uie.com/brainsparks/?p=2517#comment-152585 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"? 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”?

]]>