Phase 1: High-level questions (Allison Bloodworth)

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

  1. What is our goal/mission?
  2. Who is our audience?
  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?

[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

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

Governance:

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

[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:

[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?

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

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.

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)

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:

Daphne Ogle:

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

Daphne Ogle:

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:

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 (smile) 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:

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:

To attract a community the OSDPL should be innovative:

Allison Bloodworth:
Hopefully we are beginning to do this now. (smile) 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. )