Open Source Design Pattern Library group meeting - 07-09-08

Owned by Jonathan Hung
Last updated: Jul 21, 2008Version comment

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:

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"