Open Source Design Pattern Library group meeting - 05-14-08

Owned by Allison Bloodworth
Last updated: Jan 20, 2011 by Jonathan HungVersion comment
6 min read

Agenda

  1. Feedback on library at http://osdpl.fluidproject.org
  2. Discussion questions
    • Goal definition: 
      • 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?
    • 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.)
  3. There have been problems sending to multiple mailing lists, so how should we have discussions? Drupal Forum? Low traffic fluid-talk? New design pattern-specific mailing lists?
  4. How should we update patterns as we come up with more information? Review by this group, or just update? (http://issues.fluidproject.org/browse/FLUID-3310)
    • Larger question: what should the workflow be? See Jonathan's suggested  workflow below. Request feedback.*
  5. Sign up for work
  6. Revisit meeting schedule

Attendees:

Allison Bloodworth, Daphne Ogle, Colin Clark (note-taker), Jonathan Hung, Jess Mitchell, Paul Zablosky, Timothy Carroll (University of Illinois at Champaign-Urbana)

Meeting Notes

Introduction

Who is our Audience?

  • Jess found it very helpful to start with who the audience is on the mailing list thread
  • Allison suggests a single "primary audience"
  • Daphne suggested that personas provide us with some inspiration for how to identify our audience: In this case, we probably have two audiences:
    1. Designers (junior/senior/new to the community/etc.)
    2. Developers
  • Paul emphasized the value of code examples and implementation advice for developers
  • Different levels of patterns, different types of information attached to the pattern
  • Daphne encouraged us to prioritize the "80% information" or the most important core of the pattern on the main page, and then link off to other information and code
  • Allison suggested two different "views" of a pattern--one for designers and one for developers
  • Jonathan suggests that, in his experience, a shortened or summary view may not be used often--better to make sure the content is easily indexed and searchable
  • Jess: should we start to identify the needs or expectations that our target audiences may have?
  • Allison: too soon, we should stay high-level
  • Jess: how about thinking about some of the information organization? What are the things we can expect to find in a pattern? Is this a discussion for the list?
  • Colin: Back in the Sakai patterns days, I did a comparative analysis of various patterns format and put together a spec for them. This is only a start, since it doesn't have the other information like code samples and links to components. I'll send it out to the list.
  • Allison has also done similar work recently, will also send it out

Mailing Lists

  • Allison wants to make sure all communities feel welcome to join us
  • Should we cross-post to lists, or move to a Fluid list?
  • Colin: Rather than dealing with the overhead of cross-posting, could we try having our patterns discussion on fluid-talk, and when we're discussion interesting topics, we can occasionally send an invitation/reminder to the other lists?
  • Everyone was in agreement to move the conversation to fluid-talk

Back to Audiences

  • Daphne: should we do some card-sort or feedback exercise at the Paris conference with designers and developers?
    • Idea: blank index cards; write down all the things you'd like to see in the library and start organizing them
    • Helps with terminology, too
  • Jess and Daphne will work on some information architecture exercises on-list and in Paris
  • Allison wants this to be targeted, because the audience won't necessarily know what they need
  • Daphne: This kind of exercise works well when you frame it and then talk to users and get their ideas and suggestions; it doesn't have to be comprehensive
  • Allison: how do we facilitate a discussion on-list?

Documentation/Mission Statement

  • Allison: we have a proposal document for the patterns library. Should we create a new document that talks about our goals?
  • Jess: how about a mission statement?
  • Jonathan: proposal document is really great: let's treat it like a living document
  • Colin: distinction between document and mission statement: brevity and clarity to help ensure we know our shared goals
  • Jess: there's room for both
  • Jonathan: let's keep updating the proposal and refining as a living document

Our Goals for the Pattern Library

  • Jess: mission statement doesn't necessarily have to specifically state our target audience, encouraging everyone to get involved
  • Let's start with a bulleted list for the mission statement
  • Jess: one of the things I really like about this pattern library is that there's both input and output: it's a two-way collaboration. We accept contributions, and we share out advice about design, there's a pedagogy aspect to it
  • Daphne: A place to collaborate, and a place to learn about best practices (there's a teaching aspect to patterns)
  • Daphne: Patterns give us a common language for design; this is really important in the complex world of interaction design
  • A source of "design inspiration"resonates with many of us
  • Fostering collaboration
  • Inclusion

Drupal Issues

  • Jonathan encouraged us to consider a forum within the pattern library in the future. For now, let's stick to the mailing list until we've nurtured a large enough community of contributors

Getting Involved

  • There are lots of interesting tasks you can help with:
    • entering existing patterns - Judy & Daphne to enter a pattern before next meeting
    • working on our Drupal CMS

Meeting Schedules

  • Should we meet every week or every other week?
  • Allison would prefer every week to keep up momentum
  • Also suggested collaborative work sessions with chat
  • Colin: I'd prefer less meetings, more on-list collaboration
  • Jess mentioned how packed-full our current iteration is
  • Group decided to continue conversation on-list, but for a smaller group to meet to flesh out goals next week
  • We have the full group meet as needed, probably every other week. Other meetings will be small group working meetings.

Other Issues

  • Daphne: is it okay to go back and update or change a pattern? (Balance of shared work and not stepping on each others' toes). Maybe contact the pattern author, but it's hard to see who that is in the wiki.
  • Allison: maybe we can come up with a process. The OSDPL does have a field which tells you who the original author was.
  • Daphne: maybe it's just an issue of etiquette.
  • Jonathan: let's keep reminding ourselves of the workflow for pattern collaboration. As you're working, share your thoughts about the workflow and how it can be improved.

Action Items

  • Move discussion to fluid-talk
  • Colin and Allison will send out pattern format suggestions
  • Daphne and Judy to enter a Sakai pattern into the OSDPL
  • Daphne, Allison, and Jess will work on a short mission statement and list of goals next week at our normal meeting time
  • Also keep the Proposal document updated going forward

----*Jonathan's suggested workflow for OSDPL pattern submission:

1. Author drafts a design pattern that is publically viewable

2. Discussion flows via the comment facility for that particular draft on the CMS. Individual comments can be voted on by fellow users to help filter noise from relevent conversation (similar to how Digg does their +1/-1 ranking on comments).

3. Author is involved in discussion and adds changes / suggestions / modifications as it flows from the discussion.

4. A moderating / editing team is also overseeing that draft patterns are active and progressing. Their involvement can be as little as participating in the discussions or by adding edits to the draft if the author doesn't appear to be engaged.

5. Once a pattern is sufficiently polished, it is graduated into a full-fledged pattern where it can be ranked and other "advanced" features can be applied.

In #3 and #4 above, we would probably want to have a versioning function in place so that revisions are tracked. Also ensures that no one user can permanently delete content on a whim.

In #4 above, I am not sure technically how this can be done and what flexibility Drupal offers in terms of permissions. Ideally we would like to have real fine granuality: assign edit permissions to users on a per post basis. assign edit permissions to a group (moderator / editor group). (Note from Allison: Some of this functionality may be in Drupal's permissions system, but if it's not enough Organic Groups may be answer to this.)

OSDPL Users

  • anyone can sign up for an account.
  • any account holder can create and edit their own content.
  • any account holder can rank a polished pattern
  • any account holder can be involved in discussions through the comment system

Anonymous Users:

  • View privileges only. No other rights

Pattern Editor:

  • Content author can assign edit rights to their own content to other OSDPL users.
  • Not sure how this can be accomplished on Drupal.

Moderator / Editor:

  • Same as an OSPL user
  • can edit any pattern and comment.

Administrator:

  • the poor sod who has to look after the plumbing. (wink)