OSDPL Roadmap (outline of phases)

Phase 1: High-level questions (Allison Bloodworth)

See the Phase 1 - High-level OSDPL Discussion Questions & Answers page for final discussion of and answers to these questions. Initial discussions can be found below.)

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?
- See Peter Rowley's Collaboration Support Patterns for an example of another type of pattern we could include
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)

Architecting questions

See Phase 2 - Architecture for questions and answers relating to this phase.

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?

Governance:

See Phase 2 - Governance for questions and answers relating to this phase.

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)

From the Functional to Technically building stuff:

Workflow and notifications
Search
Tagging (Personalized and community)
Ratings
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

1. What is our goal/mission?

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
source design.

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 our audience?

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.)

See http://wiki.fluidproject.org/display/fluid/Design+Patterns+Library+Proposal for some initial ideas on this.

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.

3. How can patterns add value to the Fluid Community?

Allison Bloodworth:
A lot of this is covered in our goal/mission: (see http://wiki.fluidproject.org/display/fluid/High-level+OSDPL+Discussion+Questions#High-levelOSDPLDiscussionQuestions-goal)

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
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
will provide a taxonomy and design advice for the Fluid components

Another way to look at it is that a pattern library is a collection of reusable design knowledge put together by people who have thought about a particular interaction in depth. In our Audience discussion question (see http://wiki.fluidproject.org/display/fluid/High-level+OSDPL+Discussion+Questions#High-levelOSDPLDiscussionQuestions-audience), we talk about this further, saying "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."

I think the biggest thing we hope the pattern library will do is give us a tool to continue to improve the designs & user experience of the applications which are part of the Fluid community.

Anastasia Cheetham:
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
crappy designs.

education
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.

Daphne Ogle:

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.

4. How can we contribute to the larger design pattern community?

Daphne Ogle:

Our patterns and components are open source. I think there is alot more to say here but I'm tempted to hold off on further discussion about this until we get the OSPDL working well for our immediate community. Then we can start thinking about it fits into the larger pattern community. Otherwise I start to get overwhelmed.

5. How will this pattern library add value to the existing pattern libraries? How is it different?

Jonathan Hung:

The OSDPL will build upon existing pattern libraries through the
contribution of multiple people from a diverse community. It will be
different from other libraries because patterns will be dynamic and
current, editable and adaptable by everyone. Therefore the patterns
will not stagnate and will remain relevant to the community.

By design, the community aspect of the OSDPL will be the defining
feature that will differentiate it from other libraries.

As such, because the OSDPL is not a traditional pattern library, the
way it functions and the way it is used should not be traditional
either.

Allison Bloodworth:
This one we talk about in our goal/mission as well:

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

In my view, all the pattern libraries have different things to contribute. Jenifer Tidwell's patterns are fairly high-level and general--sort of like a reference textbook. Van Welie has both general and context-specific patterns (e.g. by site type, experience, and page type), and I think of his patterns as very practical. Yahoo! has some great patterns, but their library is somewhat small, and part of its purpose is to disseminate the Yahoo! way, which may not always represent what we want. Our pattern library will be focused on the needs of our communities, and of open source in general. Additionally, examples in our library of how these patterns have been implemented in our communities can serve as a bit of a style guide as well.

Finally, since this pattern library is the one place others can contribute patterns, it could become the the one place where all the patterns from other libraries are collected. This has been a need discussed several times on the Yahoo! ui-pattern-authors list (and I think may have been the reason for the creation of the list). This introduces new challenges, e.g. some patterns in different libraries are very similar to others and perhaps shouldn't be duplicated in one pattern library as then the amount of patterns could become overwhelming for users. But if we come up with good ways to sort and filter patterns, we could very likely solve this problem.

Anastasia Cheetham:
That's a good question I'm not familiar with the existing pattern
libraries, so I don't really know what their weaknesses/gaps are.

I guess one difference might be the "OS" part of OSDPL: Is this
library intended to be more open/collaborative than existing libraries?

Daphne Ogle:

I think it's different in that it's open source of course. It also includes information about accessibility which many pattern libraries don't.
Our strategy of tying the components back to the patterns is fairly unique. Although yahoo does some of this I think ours are more comprehensive. We also include integration design advice around the components which I think will be very valuable to implementors.
Showing and describing the patterns in various communities / applications is also unique. So we recognize that there are many ways to solve the same problem and that context matters and try to help pattern users think through all of this.
Our focus on a variety of different audiences and recognition that those different audiences require different views on the patterns and perhaps even workflows through the library is also unique. I think this will help make the library to diverse group of community members.

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?

See Peter Rowley's Collaboration Support Patterns for an example of another type of pattern we could include

Jonathan Hung:
For the immediate future, UI design patterns should be the scope of
the OSDPL. Starting with that, attention should be placed on nurturing
a community that can help sustain and drive the direction of the
OSDPL.

From this community, they will inform the future scope of the OSDPL.
If the community would like other kinds of patterns, then it should
grow from that.

Starting with a small scope will give the OSDPL focus it needs as it grows.

Allison Bloodworth:
I think this again depends on our ability to come up with good ways to sort and filter patterns. I do think having other related patterns that address behavioral issues (e.g. community building, collaborative work) could be very helpful to all the audiences we've targeted while they are doing interaction design work. I'm not sure I currently see programming design patterns in the same space, but I could see them being put in another related library. However, I would like to explore whether our programmer audience might find the library more helpful if there were some programming patterns in the library as well. If we did this, I think we'd probably need to separate the search somehow so programming patterns didn't come up for people doing interaction design work and vice versa.

Anastasia Cheetham:
What types of patterns are there? Perhaps creating an actual list of
the potential types might help with this question. Maybe we could
start with the category we think most appropriate, but design the
library to allow for future expansion?

Rachel Hollowgrass:
I'm still new, so please forgive me if I restate the obvious. I think
that programming design patterns are out of scope for the OSDPL. In a
perfect world there might be more overlap between interaction design
patterns and programming design patterns, but at this point the two
are so different I don't see how their inclusion would inform or
improve the overall OSDPL effort.

I see some distinction between widget-oriented patterns and content-
oriented patterns. Though after re-reading Tidwell, that distinction
is not as clear as I hoped.

Daphne Ogle:

I think of the OSDPL as a place to help the community create better UXs. With this overarching goal in mind I think design principles are very important to the library. We should categorize as them as design principles rather patterns. Understanding how and why users behave in certain ways is very important to good design. Not everything can live in a pattern. Principles are sort of those overarching drivers in design. Perhaps principles aren't of interest to all audiences but I think all designers find them useful. That said, I'm not sure how to handle things like Tidwell's priniciples (at the beginning of the bood). I think they're great and tend to be focused in HCI. We don't want to recreate the wheel yet not all of those principles are available online so how do we aggregate when they only exist in a book?

7. Where can the group discuss these questions?

Daphne Ogle:

I vote for the wiki. We can send emails to let people know that new responses have been added but I find it really hard to parse long email threads. And it's really difficult to know where to jump in as the email gets chunked in a variety of ways when people respond. Do i start with initial questions? But it probably makes sense to comment with the context of everyone else's comments but then not everyone comments on all questions and part of the email is removed from some responses....

8. How do we get the word out about where and when and how we're discussing this?

Daphne Ogle:

Email, conference presentations, wiki, etc.

9. How can we foster a community to advise and assist with the creation of the pattern library?

Jonathan Hung:

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.

Allison Bloodworth:
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.

Rachel Hollowgrass:
Have the usual list- and organizational communities been covered, e.g.
IxDa, BayChi, IAI, etc.? How about higher-ed campus groups at other
institutions? We did discuss pattern libraries at SUFIX, the Stanford
UX group, but I don't know of any groups there actively working on
patterns.

Daphne Ogle:

I feel like we are doing the right kinds of things. I think interest will grow organically as people begin to integrate components and our library grows with useful patterns.
-----------------------------------------

(See notes from the Open Source Design Pattern Library group meeting - 05-28-08 and Open Source Design Pattern Library group meeting - 06-18-08 for additional discussion of questions 3-9 above. )