This page will be updated further in the next few days.
1 -- Allison Bloodworth
High-level questions: (See the High-level OSDPL Discussion Questions page for discussion of and answers to these questions)
- 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]
2 -- Architecting: Daphne Ogle; Governance: Jonathan Hung
What do our target users need? What will they come to the OSDPL looking for? How can we help them achieve their goals? How can we help them find what they need?
How can we ensure that the pattern library functions together as a coherent whole (e.g. if many communities are contributing)?
Volume? How many design patterns will the library include? Is there a limit?
How should we organize the patterns?
Presentation layer -- what do we expect to see and where?
How does the design pattern library connect to the Fluid component library, UX Toolkit, and other documentation? and other Design Pattern Libraries?
How do we integrate information/patterns from other pattern libraries?
How should we bring in patterns from the Sakai design pattern library?
How can we make the OSDPL sustainable?
How can we encourage participation, broadly?
Are there particular things we want to prioritize for this initial build?
How will contributors interact with the library and what will they contribute?
those who submit their pattern
those who want to critique a pattern
those who want to use a pattern
Can we include screen shots from commercial sites?
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.]
3 -- all interested techies (this is the build it phase)
From the Functional to Technically building stuff:
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.)
1. At http://wiki.fluidproject.org/display/fluid/Design+Patterns+Library+Proposal, our proposed goal reads:
"The primary goal of the design pattern library will be to introduce design patterns as a way to design usable, high-quality user interfaces in specific contexts ("a proven solution to a common problem in a specified context"). The library will have a practical focus, intended mostly as a tool for junior/new designers as well as developers. It will not focus on creating a complete pattern language, or describing patterns in a more academic sense."
Is this the best statement of our goal? Can we add to this and flesh it out more?
- Some previous ideas from Colin: the Open Source Design Patterns Library will be the first truly open
place for collaborating on design patterns. Most of the existing pattern libraries are proprietary or managed by heavy top-down
moderation that precludes outside contribution, reuse, and modification. I really hope we'll be the place for advice about open
- From Colin: I think it would be great if we specifically identified openness as a goal for the patterns library. One of the strengths of the OSDPL is that it is very open and collaborative. Anyone can contribute patterns, and everyone has the right to reuse and repurpose our patterns in whatever way they see fit. The fact that we're building an open community around patterns, along with our Creative Commons license, distinguishes our work from the corporate-driven pattern sets out there.
- From Paul: "The primary goal of the design pattern library will be to promulgate design patterns as an approach to the creation of usable, high-quality user interfaces. For the purposes of the library, a design pattern is defined as "a proven solution to a common problem in a specified context". The library will have a practical focus: as a common source of design inspiration and examples of best practice for both designers and developers, as well as serving as a focus of discussion for their collaborative efforts."
- From Jonathan: "The primary goal of the design pattern library will be to introduce design patterns as a way to design usable, high-quality, and inclusive user interfaces in specific contexts ("a proven solution to a common problem in a specified context"). The library will be practical and foster collaboration across disciplines, experience levels, and expertise. It will not focus on creating a complete pattern language, or describing patterns in a more academic sense." (Thought it was important to mention inclusive design and cross-discipline / expertise collaboration.)
- From Daphne: I like the way the goal is stated now. I would also like to add something about it's goal to help us design consistent interactions where it makes sense. In Sakai, a common complaint is that similar activities work differently so users have to continually relearn and figure out which instance works in which way. By documenting best practices we can reuse these patterns across the applications.
One more goal we haven't explicitly included that is very important is creating a shared language. When we all know exactly what we mean (or can go to the pattern for clarification) when we say "lightbox overlay" it sure makes the conversation more smooth. I actually think in a diverse community like ours that this might be one of the biggest benefits we get from the library.
2. Who is the audience of the OSDPL? Are we trying to serve too many different audiences, and if so, should we try to pick a primary audience to serve? Is it possible to pick a primary audience to focus on where if we serve their needs, we will end up serving most of the needs of our other audiences? (This is a similar concept to picking a primary persona on whom to focus a website or application's design. In this situation we also try to meet the needs of secondary personas, but never to the detriment of the primary persona's experience.)
- from Paul: To my mind, 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. While it may be used more by junior/new designers, I think it sends the wrong signal to explicitly target them in the goal statement. Those new to any area of expertise always refer more frequently to the reference works of their trade, but the reference works are generally aimed at the whole profession.
- from Daphne, in response: This is a really good point! Although we want to design the patterns in a way that is helpful to more junior designers (assuming if it works for them, it will also work for Senior Designers), we don't have to be explicit about that in the goal statement. +1 for removing those terms.
- from Paul: As for target audience, it is my hope that the OSDPL will be accessible to both designers and developers, and its contents serve as a focus for common understanding between them. I'd like to see this expressed somehow in the goal statement. (see above)
- from Daphne, in response: I agree and would also like to see the library useful to both designers and developers.
- from Daphne: I do have some concerns about whether 1 version of a design pattern will work for both audiences though. I think I mentioned on the call that it might be useful to have a couple different levels of pattern. This is generalization but I'll use it to express my point. Designers want to understand why this is the right pattern, who else has used it, what other design considerations do they need to think about when using the pattern, etc. They want interaction consistency with some flexibility for innovation and different contexts. I think many developers want it 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" - much more prescriptive. They are also going to want to have code examples or actual code to use. Additionally, the 2 disciplines search strategies may also be quite different from one another.
I can't outline all the distinctions right now but my gut tells me we have 2 primary personas for the OSDPL: 1) Junior Designers (more experienced designers are secondary because their needs will be met by meeting the Junior Designers needs) and 2) Developers / implementors. Each primary persona needs their own interface so in this case they need their own form of the pattern. This doesn't have to mean 2 completely different patterns. I think it could be as simple as a full version and a stripped down version.
- from Jonathan: It will be hard to identify a primary target audience since the OSDPL, by its nature, will (and should) appeal to a broad audience. Developers who need to design, designers who want to innovate and participate, "beginners" looking for examples / guidance, etc. I think we'd want to keep the audience mixed to be effective in advocating good design. So in short, I don't think we have a primary audience (i know, not much of an answer .
- from Colin: I've always seen patterns as a bridge between designers and developers. As Daphne mentioned, they help establish a shared vocabulary for design idioms. I do find patterns especially appealing as advice for non-designers, but I don't think it has to be an either/or situation in terms of identifying a target audience.