[Design Patterns] Re: "Designer-ese" - should we change the way we speak on a Design Pattern?
abloodworth at berkeley.edu
Tue Jul 22 00:52:31 UTC 2008
Thanks much for sending out your thoughts on this. My thoughts are
On Jul 10, 2008, at 12:50 PM, Jonathan Hung wrote:
> During yesterday's OSDPL meeting a good discussion occurred around
> the naming of sections in the OSDPL design pattern - Namely there
> may be some confusion over the nomenclature used in the design
> The following examples are hypothetical, but it isn't a stretch to
> see the confusion (because it happened to me!).
> Example 1: The section "Problem Summary"
> Non-designer expectation of a problem summary - This is the
> description of the problem. What exactly is the problem we're trying
> to solve? Why is it so bad to let the problem persist?
> Designer expectation of a problem summary - the description of the
> *design* problem. What is the design task?
The majority of Design Pattern libraries we surveyed called this the
"Problem Summary" (see http://wiki.fluidproject.org/download/attachments/1706231/PatternLibraryDataElementInventory_ver02.xls?version=1
, which is now also linked in the "UI Design Pattern Libraries"
section of that same page), so it is somewhat of a stanadard. However,
the UC Berkeley Web Patterns Library was actually the one library to
call it "Design Problem," probably for the very same reasons you are
suggesting we do this (e.g. they also have a large non-designer
audience). I think it's a fine idea to underscore the fact that we are
talking about a "Design Problem" by using that terminology instead of
> Example 2: The section "How"
> Non-designer expectation of "how" - How do you implement this design
> pattern? Examples of CSS, code snippets, HTML fragments that can be
> copied and pasted into my work.
> Designer expectation of "how" - How should the interaction be
> structured from start to finish?
> 1. The OSDPL is different, so how much can / should we deviate from
> the accepted design pattern pattern by changing our wording?
> 2. Is there room for both interpretations in an OSDPL design pattern?
> 3. How can OSDPL design patterns better accomodate non-designers who
> is unfamiliar with the terminology?
I agree that "How" is a bit ambiguous in our context because of the
fact that we are providing components which are a different sort of
"how" (e.g. actual code). This is actually not a widely used term,
though both Jenifer Tidwell (Designing Interfaces) and VanWelie (which
are two of the 'big' pattern libraries) use this term. In Yahoo!'s
Pattern Library it seems to be subsumed under "Solution."
A few ideas:
We could put the "Related Fluid Components" section under/within the
"How" section (and perhaps also link them in a sidebar, like Yahoo!
We could put a pointer to "Related Fluid Components" at the bottom of
the "How" section
We could put "Related Fluid Components" section directly under the
We could come up with a more descriptive name for "How" that doesn't
include code snippets, though hopefully we could keep it short, e.g.
"How to Design," "Design Suggestions," "Design Directions," etc.)
We could leave it "How" and do some (even very informal) user testing
to see if folks using the patterns found this confusing
We've also discussed creating both a "designer" and "developer"
version of each pattern, so we could end up with slightly different
terminology in each situation (e.g. "How" vs. "How to Design," and
"Related Fluid Components" vs. "Implementing with a Fluid Component"
or something like that).
> - Jonathan.
> Jonathan Hung / jonathan.hung at utoronto.ca
> University of Toronto - ATRC
> Tel: (416) 946-3002
> fluid-talk mailing list
> fluid-talk at fluidproject.org
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
abloodworth at berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-talk