Re: [agile-usability] Are design patterns an anti-pattern
- Hi Austin,
On 27 Jan 2012, at 00:35, Austin Govella wrote:
> We just published an article by Stephen Turbek on Boxes and Arrows
> that argues against pattern libraries in favor of code libraries:
> * http://boxesandarrows.com/view/are-design-patterns
> As someone who often promotes pattern libraries to aid rapid, usable
> design for agile teams, I was struck by Stephen's analysis. And it
> made me recognize that the "patterns" I've seen be most effective all
> included widgets/code developers could just plug in.
> So, two questions:
> 1. Do you agree? Pattern libraries are less useful than code libraries?
I'd phrase it more like "pattern libraries without code are often less useful than pattern libraries with code".
There are plenty of instances where I've seen libraries of UI widgets without an associated description of where/why/how they should be used.... leading to a ghastly witches' brew of cross-fades, carousels and dancing widgets that help nobody ;-)
There's also the problem of interaction patterns that can't really be easily captured in a single reusable library. Sure I can build an instance of a "Collectible Achievements" pattern into a particular project. Trying to build a general "Collectible Achievements" library that I can apply to _every_ project is likely impossible, and a huge waste of time. That doesn't mean there isn't value in the abstract "Collectible Achievements" pattern.
All of this depends to some extent on the UX knowledge of the developer folk, and the communication patterns between the dev and UX folk.
To draw two extremes:
* When patterns are solely used as a tool for command and communication with devs without UX knowledge ("Build Foo with Bar pattern. Get to it.") then mistakes and misinterpretations are common, since they don't understand *why* Bar is a good idea". Implementations of patterns help a *lot* here.
* When patterns are used as a communication tool between peers, when folk understand the reasons issues involved, then the implementation is almost a side issue ("Hey the secondary nav around the products is taking up so much space - we're losing the focus on the product". "Could we move some of the labelling around it to hover invitations?" "That's not going to work for touch folk?", "okay what about...").
Interestingly - I see the same sort of problems with "code" patterns. Folk misusing and Inversion of Control library for example, because they've been made to understand they *should* use it, but don't really understand *why*. Developers going pattern happy and trying to jam in everything from the GoF book because "patterns are good". Conversely I had a conversation with a pair while developing a few months back that basically went:
Me: <I start typing a hard-coded class name>
Pair: Test? (subtext "how do you test that - idiot" :-)
Me: "Yeah. You're right. Inversion .."
Both: "of control".
Me: <Add it test and wrote it a sane way>
Patterns are least effective when they're used as a way to instruct/manage the actions of people inexpert in the domain, and applied from the top down.
They're most useful when they're used by people who understand the domain, and pulled out of working projects in a bottom-up way.
> 2. Are they only better for agile teams? (Are traditional pattern
> libraries better for waterfall-driven organizations)?§
I'd say they're better regardless. In fact I'd say that having an implementation is even more important in waterfall environments since the separation of design and development folk that happens in those environments make it more likely that patterns are going to be missed or misunderstood.
(As an aside I'm intrigued by what Stephen's definition of "pattern" is - since he says "the “why”s are not answered" - surely the "whys" are an essential part of a pattern library?)
http://quietstars.com adrianh@... twitter.com/adrianh
t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh
- As I see it, the main advantage of Design Patterns (whether they be a UX or Code pattern) over code or widget libraries, is that they are transferrable across programming languages and dev platforms.
Also, speaking only in the domaine of S/W Design patterns (as opposed to UX design patterns), many of the most useful patterns are things that simply cannot be wrapped into a standard library. You just have to understand the pattern, and how to implement it in your specific cases.
For example, I don't see how one could write a standard class for a pattern like factory method:
For sure, some patterns could be made into standard classes, but often I find that the "generic" implementation is harder to use and understand than a custom implementation. Often, you don't need all the bells and whistles of a pattern, and you are better off using the "Simplest Implementation That Could Possibly Work" for that pattern, in the context of your application.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Austin Govella
Sent: Thursday, January 26, 2012 7:35 PM
Subject: [agile-usability] Are design patterns an anti-pattern
We just published an article by Stephen Turbek on Boxes and Arrows
that argues against pattern libraries in favor of code libraries:
As someone who often promotes pattern libraries to aid rapid, usable
design for agile teams, I was struck by Stephen's analysis. And it
made me recognize that the "patterns" I've seen be most effective all
included widgets/code developers could just plug in.
So, two questions:
1. Do you agree? Pattern libraries are less useful than code libraries?
2. Are they only better for agile teams? (Are traditional pattern
libraries better for waterfall-driven organizations)?
Catch me at the IA Summit in New Orleans, Mar 23-25, presenting
"The miracle farmer's almanac":
Watch my presentation from Schiplcon 2011:
Listen to my presentation from SXSWi 2011:
Yahoo! Groups Links