Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Agenda

  1. Finalize Last Week's Discussion questions
    Mission Statement

    A design pattern is a "proven solution to a complex problem in a specified context." The primary goal of the Open Source Design Pattern Library will be to promote a set of collaboratively-created user experience (UX) design patterns as a way to design usable, high-quality, inclusive user interfaces in specific contexts. It will:

    • be the first truly open place for collaborating on UX design patterns. (It will be creative commons licensed, and not in any way proprietary or managed by heavy top-down moderation that precludes outside contribution, reuse and modification.)
    • be the place for advice on open source UX design
    • have a practical focus: as a common source of UX design inspiration and a place to learn about best practices for both designers and developers, as well as serving as a focus of discussion for their collaborative efforts
    • foster collaboration across disciplines, experience levels, and expertise
    • help communities design consistent interactions, both within and across projects, where it makes sense to do so
    • help create a shared language/vocabulary for communities to discuss UX design
      (Sidenote: what do folks think about potentially grabbing the URL "uxdesignpatterns.org" to point to our library as well as "uidesignpatterns.org"?)
    Design Goals - Audiences

    The OSDPL is a setting down of a portion of the body of knowledge that expresses the principles of good design. As such, it should serve as a reference work, as well as a repository for study. The library will be targeted towards a diverse set of audiences, including:

    1. Junior designers & designers who are new to the communities - they will likely both want to peruse the library to learn best practices as well as look for specific design solutions to problems.
    2. Developers who need to design the UIs they build - will most likely be looking for specific design solutions to problems, want more concrete solutions, and even code samples, pattern comparisons, demos, or components related to the pattern.
    3. Experienced designers - will probably browse the pattern library for inspiration, or to come up with innovative solutions to complicated problems.
      Pattern Authors, which may fall into any of the 3 categories above.

    We will design the library for three primary audiences, meaning each of them will have their own interface (in this case, their own form of the pattern):

    1. Pattern Users: Junior Designers (who may want fairly deep explanations of patterns)
    2. Pattern Users: Developers (who may want more succinct patterns and code examples)
    3. Pattern Authors

    We expect there will be some secondary audiences as well (meaning design will not be focused on them, but their needs should be covered in the interface which addresses the primary audiences' needs, perhaps with just a few additional enhancements):

    • Experienced Designers (should be covered by Junior Designers' interface)

    As mentioned above, although Pattern Authors may fall into either the designer or developer category, they will have a completely separate interface to add and edit patterns (which others who are simply users of the library will never see). We believe designers and developers will have slightly different needs as users of the patterns. This could be as simple as presenting the full version of the pattern to designers and a more "stripped-down" version to developers. We believe designers will want to understand why a pattern is the right pattern, who else has used it, what other design considerations they need to think about when using the pattern, etc. They will want interaction consistency with some flexibility for innovation and different contexts. Developers may just want to "cut to the chase," "just tell me how to solve this interaction problem" or "tell me how to implement this solution, don't give me a bunch of different options;" in other words, they may prefer a much more prescriptive style. Developers will likely also want to have code examples or actual code to use. Additionally, the 2 disciplines' search strategies may also be quite different from one another. We'd like to confirm all of these assumptions in the future by doing user interviews/research.

  2. Discuss new high-level questions (are we missing any?)
    1. What is our goal/mission? (tick)
    2. Who is our audience? (tick)
    3. How can patterns add value to the Fluid Community?
    4. How can we contribute to the larger design pattern community?
    5. How will this pattern library add value to the existing pattern libraries? How is it different?
    6. What do we mean by "design patterns"/what is the scope of our work? Should we concentrate only on interaction design patterns, or include other human computer interaction or programming or architecture patterns as well? What types of patterns are within the scope of the OSDPL?
    7. Where can the group discuss these questions?
    8. How do we get the word out about where and when and how we're discussing this?
    9. How can we foster a community to advise and assist with the creation of the pattern library?
  3. Future meetings
    1. Note-taking
    2. Next meeting date
  4. Sign up for work on the OSDPL

Attendees:

Meeting Notes

  • No labels