Patterns vs. Designs (was: What do you call this list behavior?)

12 Apr 2007 - 10:24am
7 years ago
5 replies
803 reads
Christopher Fahey
2005

Jenifer Tidwell wrote:
> Ah, pattern naming -- my favorite part of pattern
> definition.

... regarding:
> http://www.flickr.com/photo_zoom.gne?id=456370920&size=o

I'd like to take advantage of Jenifer Tidwell's expert presence in this
thread to ask both her and the group: Is this sort of interaction really
a "pattern"? Can or should every new type of interaction design be
called a pattern?

In clothing fashion design, an "a-line dress" is a pattern (analogous to
a UI pattern), and a "keyhole collar" is a pattern, but when they are
combined in a single garment they don't together constitute a new
pattern.

I think we should probably be a little more strict about declaring what
a "pattern" is, and we should differentiate patterns/archetypes from
individual instances of design, no matter how good or ubiquitous that
design might be.

Jenifer's set of patterns as defined in her awesome book and web site
each cite several examples rather than wireframing out a perfect
archetypical example. I suspect this was a deliberate decision on her
part, to avoid defining the pattern explicitly. The examples are usually
pretty diverse in their implementation because the pattern itself is
*latent* beneath the designs, and any given implementation of a pattern
is almost always going to include other patterns and UI styles that
hybridize it beyond any single underlying archetype.

In short, I agree with Jenifer's response to the question: to identify
it as a hybrid of several patterns. It's a great example, and worth
keeping in the scrapbook as a "benchmark design" or something like that,
but it ain't a pattern IMHO.

Thoughts?

-Cf

Christopher Fahey
____________________________
Behavior
http://www.behaviordesign.com
me: http://www.graphpaper.com

Comments

12 Apr 2007 - 10:45am
Kevin Silver1
2006

I like to think of a pattern as a class of behavior and an interface
object as an instance of that class:

pattern = class

interface object = instance

The interface object is the final design as the user sees it. It can
inherit behavior from multiple classes (patterns).

I agree with what I think Chris is getting at, the final "benchmark
design" (interface object) is paramount, the class is just the basis
of it.

Kevin

On Apr 12, 2007, at 9:24 AM, Christopher Fahey wrote:

> Jenifer Tidwell wrote:
>> Ah, pattern naming -- my favorite part of pattern
>> definition.
>
> ... regarding:
>> http://www.flickr.com/photo_zoom.gne?id=456370920&size=o
>
>
> I'd like to take advantage of Jenifer Tidwell's expert presence in
> this
> thread to ask both her and the group: Is this sort of interaction
> really
> a "pattern"? Can or should every new type of interaction design be
> called a pattern?
>
> In clothing fashion design, an "a-line dress" is a pattern
> (analogous to
> a UI pattern), and a "keyhole collar" is a pattern, but when they are
> combined in a single garment they don't together constitute a new
> pattern.
>
> I think we should probably be a little more strict about declaring
> what
> a "pattern" is, and we should differentiate patterns/archetypes from
> individual instances of design, no matter how good or ubiquitous that
> design might be.
>
> Jenifer's set of patterns as defined in her awesome book and web site
> each cite several examples rather than wireframing out a perfect
> archetypical example. I suspect this was a deliberate decision on her
> part, to avoid defining the pattern explicitly. The examples are
> usually
> pretty diverse in their implementation because the pattern itself is
> *latent* beneath the designs, and any given implementation of a
> pattern
> is almost always going to include other patterns and UI styles that
> hybridize it beyond any single underlying archetype.
>
> In short, I agree with Jenifer's response to the question: to identify
> it as a hybrid of several patterns. It's a great example, and worth
> keeping in the scrapbook as a "benchmark design" or something like
> that,
> but it ain't a pattern IMHO.
>
> Thoughts?
>
> -Cf
>
> Christopher Fahey
> ____________________________
> Behavior
> http://www.behaviordesign.com
> me: http://www.graphpaper.com
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org

12 Apr 2007 - 10:40am
Janna DeVylder
2006

I'm torn. On one hand, the beauty of calling it a pattern, of encompassing
it with a name (regardless of how difficult it is to get to that name), is
that the community can refer to that specific interaction instance. But on
the other hand, it is going to be difficult to keep track of all these
instances, and ultimately could make a pattern library difficult to use.

In the end, I know it is useful to have a shared concept of pattern across
our community, but if something is reused again and again within your own
organization's work, I think calling it a pattern and defining it as such
allows for much reusability in future implementations (and less rework).

janna

On 4/12/07, Christopher Fahey <chris.fahey at behaviordesign.com> wrote:

>
> I'd like to take advantage of Jenifer Tidwell's expert presence in this
> thread to ask both her and the group: Is this sort of interaction really
> a "pattern"? Can or should every new type of interaction design be
> called a pattern?
>
> I

13 Apr 2007 - 4:01am
Morten Hjerde
2007

Interaction is very different on a PC and on a mobile phone.

There is a very clear rationale for when you want to use this kind of list
behavior, as opposed to single or dual line lists - or a handful of other
types of lists on a mobil phone.

If you take a room full of tables and chairs you can have a class room.
Rearrange them, dim the light and you can have a bar. Or you can just have a
badly lit class room. The need to make our developers understand
the difference between a bar and a badly lit class room is why I write it up
and call it a pattern.

Mobile phones are very much about lists, menus and viewers. It would not do
to have just a single "list pattern". Each type has to be explained; why,
when and how to use it. I guess I could call them "Instance xx of the list
class", instead of giving them a name. It would just make them harder to
remember.

13 Apr 2007 - 5:48am
Håkan Reis
2006

I think it's most important to use patterns to carry the concepts, the ideas
behind problems and solutions. It's an excellent and powerful tool for
knowledge transfer, but as Christopher wrote, it's important to be strict
about what a pattern is. For me the hardest thing is to differentiate the
pattern from a simple recipe. And it is up to the community to review and
evaluate patterns to eliminate duplicates and unclear ones. Also, I think
that another work here is to select and form pattern languages around the
domains, for example interaction with mobile devices.

For a couple of months ago my company attended a workshop with James Coplien
and the experience was inspiring. Working as a consultant we often find it
hard to share knowledge with colleagues that are spread out among customers.
The result is that we are currently trying out patterns as a way of sharing
knowledge in the company.

On 4/13/07, Morten Hjerde <mhjerde at gmail.com> wrote:
>
> Interaction is very different on a PC and on a mobile phone.
>
> There is a very clear rationale for when you want to use this kind of list
> behavior, as opposed to single or dual line lists - or a handful of other
> types of lists on a mobil phone.
>
> If you take a room full of tables and chairs you can have a class room.
> Rearrange them, dim the light and you can have a bar. Or you can just have
> a
> badly lit class room. The need to make our developers understand
> the difference between a bar and a badly lit class room is why I write it
> up
> and call it a pattern.
>
> Mobile phones are very much about lists, menus and viewers. It would not
> do
> to have just a single "list pattern". Each type has to be explained; why,
> when and how to use it. I guess I could call them "Instance xx of the list
> class", instead of giving them a name. It would just make them harder to
> remember.
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>
>

--
Håkan Reis
Dotway AB

Voice: +46 (40) 602 32 10
Sms: +46 (768) 51 00 33

http://blog.reis.se

13 Apr 2007 - 6:01am
Mark Schraad
2006

I am an active promoter and user of pattern libraries, but I have a
concern regarding their usage. I worry about the tendency to use
patterns libraries as a plug and play solution catalog. To use a
pattern because it "will do" and never come back to explore a more
optimized solution. The economy and efficiency of using libraries is
wonderful but an 80/20 solutions is not always enough.

My experience as a designer, and in managing designers has been that
when we are eyeball deep in a problem, we are not always very good at
selecting the opportunity for further exploration. It may take
someone outside of the tactical process to give us a perspective to
"pick our battles". Any one else experience this? Am I making sense?

Mark

On Apr 13, 2007, at 6:48 AM, Håkan Reis wrote:

> I think it's most important to use patterns to carry the concepts,
> the ideas
> behind problems and solutions. It's an excellent and powerful tool for
> knowledge transfer, but as Christopher wrote, it's important to be
> strict
> about what a pattern is.

Syndicate content Get the feed