OSDPL Design Pattern review and discussion

Date of meeting: Wednesday July 9th, 2pm-3pm EST.

In Attendance:

Rachel Hollowgrass
Jonathan Hung
Jess Mitchell
Daphne Ogle
Erin Yu

Agenda:

Design pattern format tweaks
Review some design patterns
- Pagination Design Pattern
- Inline Edit Design Pattern

Notes:

OSDPL Design Pattern format - add the following sections:

"Related Fluid Design Patterns"
"Examples" section with "Example Fluid implementations" and "Similar Implementations" sub-sections
"References" (sources used to create this pattern)
"Related patterns" (relationships to other patterns within our DPL)
"Design Advice"
- CSS tips, Variations of the design, advice on when to implement each variation
- e.g. Inline Edit: when to have an explicit Save button
- Design advice on what's outside of the component e.g. Uploader: "make sure the newly uploaded files are in focus" --> should be included in the "How" section, and just distinguish what's in the component and what's not. (Anastasia)

We feel there should be a section that describes tasks the implementing designer or developer needs to do to ensure the seamless integration of the component. For example, the Uploader component deals strictly with uploading of files, however, the designer should highlight or indicate which files have been uploaded after transitioning from the Uploader back to their work context.

Question: what should the title of this section be?

"Transition", "Component Integration"

Pagination Design Pattern

Alt Text Tooltip reference should link to a tooltip pattern.
The tooltip pattern should be linked in the "Related Patterns" section.

Format of "How" section: List vs. table

both have merits and depends on context.
however, lists are easier to input for pattern authors, so it may become the format of choice for the OSDPL.

Pattern and Fluid component development need not be in synch. Status of component should be communicated to avoid confusion.

We should be sensitive to our audience

example, does the title "Problem Summary" make sense to our audience?
- this can (and has been) interpreted as "a description of the usability problem" rather than "the design problem"

Browser not supported