[Design Patterns] Re: Jul 9th OSDPL meeting notes posted

Allison Bloodworth abloodworth at berkeley.edu
Tue Jul 22 05:59:41 UTC 2008

Hi there,

I've catching up on the discussion folks had at the last OSDPL meeting  
and thinking more about the "standard format" for design patterns in  
the OSDPL. I have some ideas about this, with one caveat: at this  
point I think we are trying to design a format which will work for  
both designers & developers, but at some point if we choose to have  
separate presentations for both audiences, we could certainly  
customize the format for each audience.

Previously, I did a comparison of data elements found in other (major)  
design pattern libraries: http://wiki.fluidproject.org/download/attachments/1706231/PatternLibraryDataElementInventory_ver02.xls 
, which helped us verify our initial data elements. Today I compared  
previous versions of the OSDPL, looked at the notes from the last  
OSDPL meeting, talked to Daphne, and created a suggestion of what I  
think the final data elements should be in the order I believe they  
should appear (also attached as an Excel file):
Original OSDPL
Format Suggested by Jonathan in InLine Edit Pattern
Suggested Updated New Format
Problem Summary
Problem Summary
Design Problem
Solution (image + text)
Solution (text + image)
Solution (image + text)
Use When
Use When
Use When
Why (missing from some)
How - includes a checklist for each Fluid component showing which  
"how" items are taken care of by the component, and which implementors  
must take care of or configure as part of the implementation process

* Fluid Implementations

* Other Implementations
Related Fluid Components
Related Fluid Components
Related Fluid Components

* Additional Component Integration Advice - what part of the design  
pattern the component implements for you and what part you still need  
to take care of
Related Patterns

Related Patterns (within OSDPL)

References (This pattern in other collections)

Related Information

The items marked with "*" are subsections of the section above them. I  
think there may need to be more thought about how the "How" section  
connects to the "Related Fluid Components" section (see my previous  
email), but apart from that tweak (which perhaps could be part of a  
future iteration, anyway) I think this is the format I'd suggest.

Today Daphne & I discussed the fact that a lot of the Fluid component  
integration advice may be part of the "How" section of the design  
pattern. One way to link this info to the "Related Fluid Components"  
could be to create a table in the "How" section which tells which  
pieces of "design advice" in that section are taken care of by the  
components, which require some configuration of the components, and  
which are completely outside the components (but still must be handled).

For example, for the File Upload pattern:
File Upload
* Allow users to browse files on their computer and upload them into  
their current context.	Stop - Must be taken care of outside component
* Allow users to choose a single or   multiple files from a single  
location through shortcut keys (shift, ctrl or apple).	Checkmark -  
component takes care of it
* Allow users to remove selected files from the upload queue.	Caution  
- must configure within component

Hopefully most of the design advice would then be in the "How"  
section, but there would still be an "Additional Component Integration  
Advice" section as a subsection of each component in the "Related  
Fluid Components" section (used only if there was something not  
covered in "How" that we needed to specify). One advantage of trying  
to put everything that needs to occur in the "How" section is that  
hopefully it will help us think through the design pattern thoroughly,  
and not *only* have it just contain advice which maps directly to the  
Fluid component.

The one thing I left out is the "Related Information" section, as I'm  
not sure what that would contain but could certainly be convinced  
otherwise if there is a user need this section would serve.

What do folks think about using this as the format for the initial  
iteration of the pattern library (meaning we can definitely continue  
to improve upon it)? Did I capture most of the ideas from the meeting?  
Are we missing anything?


On Jul 10, 2008, at 11:33 AM, Jonathan Hung wrote:

> Hi everyone.
> Yesterday's OSDPL meeting notes have been posted. You can find it  
> here:
> http://wiki.fluidproject.org/x/KYQ7
> Highlights:
> - Majority of the discussion revolved around discussing the  
> structure of a design pattern.
> - Walked through the Pagination and Inine Edit deisgn patterns.
> - New sections will be added to the design pattern structure  
> (Example sub-sections)
> Discussion points (will be conducted in seperate emails):
> - New section for "integration"? (see meeting notes)
> - Change in pattern terminology to be more understandable to a non- 
> designer audience?
> Please review the meeting notes and post questions your questions/ 
> comments to the list.
> - 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/7b425210/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DesignPatternFormat.xls
Type: application/vnd.ms-excel
Size: 31744 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-talk/attachments/20080721/7b425210/attachment.xls>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-talk/attachments/20080721/7b425210/attachment-0001.html>

More information about the fluid-talk mailing list