- What is our goal/mission?
- Who is our audience?
- How can patterns add value to the Fluid Community?
- How can we contribute to the larger design pattern community?
- How will this pattern library add value to the existing pattern libraries? How is it different?
- 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?
- Where can the group discuss these questions?
- How do we get the word out about where and when and how we're discussing this?
- How can we foster a community to advise and assist with the creation of the pattern library?
\[incidentally, a succinct summation of these discussions would make itself into a nice FAQ\]
Phase 2: Architecting (Daphne Ogle) and Governance (Jonathan Hung)
- What will the process be for creating patterns and adding them to the library?
- What makes a good pattern/what are the guidelines for creating good patterns for the library?
- What will the process be for updating patterns?
- How should the OSDPL be moderated? By a person? By a technology?
- How will "ownership" be maintained?
- Who will write up the OSDPL group charter?
- Do we need to establish roles for users? If so, what are the different types of access they will need to the OSDPL in each role?
\[incidentally the answers to this second group of questions will become translated into the technical building stuff \ -\- this meaty section acts as a nice transition from the cerebral "high-level questions" to the technical "build it" specs.\]
Phase 3: Build-it Phase (all interested techies)
- Workflow and notifications
- Tagging (Personalized and community)
- Customize views of patterns based on user profiles.
- Specific JIRA-338 tasks
- How can we handle versioning of patterns?
- Example of how we would like the OSDPL to look and function for the first iteration: http://groups.ischool.berkeley.edu/ui_designpatterns/webpatterns2/webpatterns/home.php
\[marching orders for technologies (e.g. wiki, cms, etc.)
High-level question Discussion
As a developer, I think design patterns provide:
- a virtual designer:
Developers often don't have access to design resources, and must do
the design themselves. If a pattern library can provide guidance on
the 'best' way to implement a <insert widget name here>, then the
developer can feel more confident that they're not going to implement
Developers often don't know much about design, but end up having to do
it anyway. If a pattern library can offer some explanation of why a
design is the way it is, developers using the library can slowly build
up a basic understanding that can help them to produce better designs
when they're required to design something.
- Give us a language for talking about our designs and components
- Help the community integrate components with users and good, useful, acessible design in mind. The context components live in determine the exact design. Some of the design decisions are configurations within the component itself. Some other design decisions are outside of the component but lead the user to the component (Add files button) or drop them out of it (display starting page with all new files in view and visually distinguised in some way).
- Help us do good design in general by sharing knowledge & best practices. There are other pattern libraries that do this same thing but it requires going to several different places / libraries. It would be great if the OSDPL includes links to other appropriate patterns and design principles. We don't need to recreate the great work others have done but let's make out library a one stop shop where we aggregate useful patterns and principles for the community.
- Describes design rationale for the components. This rationale is very important to designers as they think about configuration, contexts, which pattern in appropriate, etc.
9. How can we foster a community to advise and assist with the creation of the pattern library?
- Make it easy for people to give feedback, ask questions, and participate.
- leverage communication techniques used by successful communities
(i.e. forums, enhanced comments, rankings, profiles, buddies, content
sharing and creation, syndication etc.)
- Barrier to entry should be very low and the number of hoops required
to jump through to get something done (i.e. content creation or making
a comment) should be small.
To attract a community the OSDPL should be innovative:
- approach developers who have come up with an innovative UI and ask
them to participate to improve their designs. This means keeping
abreast in open source community and OS projects to know where the
interesting UI problem domains are being addressed.
- participate actively in other communities rather than to wait for
the community to come to the OSDPL.
Hopefully we are beginning to do this now. I think the most important thing is to help folks realize and get excited about what the pattern library can do for them, and then recruit contributors (some of whom might already be creating their own patterns). This may require some 'marketing' outreach, but to a large extent the proof will be in the pudding--a library of useful patterns. I'm hoping we can provide incentives for people to contribute and comment on patterns by leveraging user profiles and ratings (to recognize really helpful contributors or commentors), and get discussion and refinement of patterns going in the library itself. I think as we are figuring out overall goals of the pattern library and then beginning to seed it initially with the first patterns (in the process of which we will be figuring out the best processes for creating, editing, finalizing and releasing patterns) it will also be helpful to have teleconference meetings. It may also be a good idea to have periodic teleconferences in the future to stay in touch with folks and ensure that people keep the library foremost in mind and continue to create and use patterns.