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

[Erin Yu]

Hi Allison,

I really like the How section checklist. That would help the reader  
identify what's in the component/pattern, and what needs to be done  
outside so the interaction flows nicely.

What do you think about putting the Rationale section immediately  
after the How section?
How explains the design, then Rationale section explains why those  
decisions were made.
Other than that, the format looks great to me.

Erin


On 22-Jul-08, at 1:59 AM, Allison Bloodworth wrote:

> 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):
> <DesignPatternFormat.xls>
> 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)
> Rationale
> Rationale
> How
> How
> 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
> Accessibility
> Accessibility
> Accessibility
> Examples
> Examples
> Examples
>
>
> * 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
>
> 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:
> HOW
> 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?
>
> Cheers,
> Allison
>
> 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
>
>
>
>
> _______________________________________________
> fluid-talk mailing list
> fluid-talk at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-talk

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