[Design Patterns] Re: "Designer-ese" - should we change the way we speak on a Design Pattern?

[Allison Bloodworth]

Hi Jonathan,

Thanks much for sending out your thoughts on this. My thoughts are  
below...

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  
> patterns.
>
> 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  
"Problem Summary."

>
>
>
> 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?

>
>
> Questions:
> 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!  
does)
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  
"How" section
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).

Cheers,
Allison
>
> - 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
> http://fluidproject.org/mailman/listinfo/fluid-talk

Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
abloodworth at berkeley.edu




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-talk/attachments/20080721/6b92029a/attachment.html>