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

Tue Jul 22 19:01:00 UTC 2008

Hi Erin,

Thanks much for your comments, and thank you for pointing out the fact  
the order of the data elements is important.

If you look at Jenifer Tidwell's book, "Designing Interfaces," you can  
see that she's structured her patterns in the who, what, when, where  
(which is not used by Tidwell), why and how format. This is the  
standard order for the 5 w's (+h), and the questions are ordered by  
importance. In this case the "How" would be last and "Rationale" or  
"Why" would be second to the last. Daphne and I also thought the "Why/ 
Rationale" was more related to the "Use When" and should flow after  
it. (e.g. if you were just told when to use it, you probably want to  
know why.)

I think we also may be interpreting "Why/Rationale" slightly  
differently, which could be why we are each thinking it would be  
better in a different place. I think this points to a need to create a  
glossary of what the pattern data elements mean so we can all get on  
the same page about that. I'll put in a JIRA task to do this. Perhaps  
after we have this document it would be easier to discuss the the  
order of the data elements? Let's talk briefly in an upcoming stand-up  
about what order to put the elements in for the initial release.

Cheers,
Allison

On Jul 22, 2008, at 10:22 AM, Erin Yu wrote:

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

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/20080722/a246bca2/attachment.html>