[Design Patterns] Design Pattern data elements (Was: Jul 9th OSDPL meeting notes posted)
Allison Bloodworth
abloodworth at berkeley.edu
Wed Jul 30 17:18:26 UTC 2008
Hi there,
Attached and pasted below you will find an updated spreadsheet which
includes the previous versions of the data elements in the OSDPL as
compared to the current ones. I'd like to stress that this format is
still very open to any changes that folks feel are needed, but is
based the format I suggested on 7/22 below, as well feedback I
received from Erin & Eli.
Original OSDPL Format Suggested by Jonathan in InLine Edit Pattern
Suggested Updated New Format Current OSDPL format
Title
Synonyms
Problem Summary Problem Summary Design Problem Design Problem
Categories * UI Design Pattern
(Category) * UI Design Pattern Tags
Solution (image + text) Solution (text + image) Solution (image +
text) Solution Image * Solution
Image * Soiution Image Source(s) Solution
Use When Use When Use When Use When
Why (missing from some) Rationale Rationale How
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 Rationale
Accessibility Accessibility Accessibility Accessibility Considerations
Examples Examples Examples Examples
* Fluid Implementations * Example Image
* Other Implementations * Example Image Source(s)
Related Fluid Components 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 Fluid
Components * Component Integration Advice -
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
Related Patterns Related Patterns (within OSDPL) Related Patterns
References References (This pattern in other collections) References
- This Pattern in Other Collections
Related Information Contributors
WHY/RATIONALE
Erin and I talked a bit about that pesky "Why/Rationale" section. We
discovered that we were sort of talking about it from different
perspectives: Rationale is perhaps a shorter explanation of why this
pattern works, more targeted toward developers. Why could be thought
of as a longer, more academic explanation of why the pattern works
directed towards designers. Why is likely to include design
principles, or evidence such as studies justifying the use of the
pattern. Depending on who you are, the ideal placement of Rationale
may differ. If you are a developer, (as Erin talks about below) you
are likely to want to see "How" right after "Use When" and care less
about the rationale. If you are a designer, it's likely more important
to understand *why* the pattern works than how to implement it, so you
would likely want to see "Why/Rationale" right after "Use When."
In the UC Berkeley's Web Patterns group's "Comparative Analysis of
Collections" (http://www.ui-designpatterns.org/tr/ComparativeAnalysisOfCollections.pdf
), they viewed "Rationale" and "Why" as the same data element. PLML
(Pattern Language Markup Language, thought by many to be the standard
for marking up patterns, perhaps with a few additions: http://www.cs.kent.ac.uk/people/staff/saf/patterns/plml.html)
, puts "Rationale" Under "Evidence," saying:
Anyway, there is enough divergence to allow two sub-elements of
<evidence>:
<example> which includes known uses, and
<rationale> which includes discussion, and any principled reasons for
the solution. That is principles of cognitive or behavioural
psychology, etc., such as “recognition is easier than recall”.
So I do think Rationale and Why are very similar. We could think of
them as a) Why is a longer, more detailed version of Rationale, or b)
Why is for designers and Rationale is for developers. I think in the
future when we create separate versions of the pattern for different
audiences we can customize them. For now, I sort of combined "How" and
"Rationale" into one element so the designers would have the "deeper"
explanation they were looking for, but as a nod to developers, I
called it "Rationale" and put it *after* the "How." Do folks think
this is a good compromise for now?
OTHER CHANGES SINCE 7/22 SUGGESTED PATTERN FORMAT
1) There were some missing data elements I'd forgotten (Title,
Categories, Contributors), which are now in the spreadsheet.
2) Based on feedback from Eli that "Attribution" was a difficult to
understand term, I changed it to "Source."
3) Based on time constraints, my own thought that we may not need to
separate Fluid Examples from other Examples, feedback from Eli and the
fact that I thought there is probably a better way to do it (e.g.
sorting) than creating separate sections, I put all examples in one
section. The more I think about it the more I think we may need to
create a separate content type for it so you can easily view "All
Fluid Examples" or "All Sakai Examples" but that is something that is
scheduled for future work.
4) I think where the Fluid Component Integration Advice goes is still
an open question. Does (some or all of it) it go in the "How," or
would that make our pattern library too Fluid-centric? I suggested
moving the table previously in "How" to "Component Integration Advice"
because I'd hate to make it harder for designers to get to Rationale
if it's below a lot of Component advice. But I think this item
definitely requires more discussion by the group before any decisions
are made.
* 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
Let's talk more at the meeting about how best to "finalize" (for now)
the format--thanks everyone for all your advice and help!
Allison
On Jul 22, 2008, at 12:01 PM, Allison Bloodworth wrote:
> 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
>
>
>
>
> _______________________________________________
> 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/20080730/63cd9f6d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DesignPatternFormat.xls
Type: application/vnd.ms-excel
Size: 33280 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-talk/attachments/20080730/63cd9f6d/attachment.xls>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-talk/attachments/20080730/63cd9f6d/attachment-0001.html>
More information about the fluid-talk
mailing list