[Design Patterns] The OSDPL and the end user

[Paul Zablosky]

In yesterday's OSDPL meeting I raised the idea of using design patterns 
to explore and explain UI solutions in consultations with end users -- 
that is, the ultimate consumers of the service.  The was inspired by the 
notion that in classical software development certain kinds of design 
representation constructs are good for communicating with the customer, 
and some are not.  For example, flow charts and ER diagrams are not 
generally useful in discussing designs with the end user, but data-flow 
diagrams and decision tables can be extremely valuable in coming to a 
common understanding of how a solution addresses the problem to be 
solved.  It occurred to me that some UI design patterns, properly 
expressed, might fall into the useful-with-users set, and that we might 
consider including end users in our potential OSDPL audiences. Certainly 
a library entry could be used by a designer in discussing solution 
approaches with end users.  I can imagine a designer or developer saying 
to a client, "At this point the person at the keyboard needs follow this 
sort of a work flow and perform these sorts of choices, some exclusive, 
and some non-exclusive.  Here is a design pattern that orchestrates the 
interaction in a manner that keeps the target in focus, and avoids these 
pitfalls." -- or words to that effect.    The point I want to make is 
not that end users will be referencing the library on their own, but 
simply that much of the content should be understandable by them.

This idea was reinforced when I read Jan Borchers article /A Pattern 
Approach to Interaction Design/ 
<http://hci.rwth-aachen.de/materials/publications/borchers2000a.pdf>. 
Borchers speaks of "Pattern Languages as l/ingua franca/" and then goes 
on to say:

    It is less known that Alexander's goal in publishing this pattern
    language was to allow not architects, but the inhabitants
    (that is, the users) themselves to design their environments.
    This is strikingly similar to the ideas of user-centered
    and participatory design, which aim to involve end users in
    all stages of the software development cycle.

While we're not addressing the pattern language problem directly with 
the OSDPL, I think the idea that a cross section of its content being 
accessible to the layperson is a powerful motivation to the pattern 
author, especially if this leverages participatory design.

[I was pretty sure that I first came across the Borcher's article 
through a link in a list of references that Allison put in the Fluid 
wiki some while ago. I couldn't find the list on wiki when I went 
looking and had to find the link through Google, so perhaps I was 
mistaken.  Also, I apologize for using the word "leverages" as a verb in 
the last paragraph.  I don't know what came over me.] 

Paul







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