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

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

Wednesday, May 7th, 2008, at 3pm PDT/6pm EDT/Thursday at 8am Australia Eastern

Agenda

  • Brief Introductions
    • Name, job, institution, experience with UI design patterns, how you'd like to participate or what you'd like to get out of this group
  • The Fluid Project & UI Design Patterns
  • What should the goal of the Open Source Design Pattern library group be?
    • Potential discussion topics:
      • Who is our audience?
      • How are patterns contributed, edited, and moderated?
      • Do we need a 'staging area' before releasing in process patterns?
      • How can we build a self-sustaining community of contributors?
      • Should there be patterns other that UI Design Patterns included in the library (e.g. HCI or pedagogical patterns like "Widespread participation"?)
      • Should patterns be general and apply to everyone, or customized for each community?
      • How can we encourage contributions and at the same time ensure the quality of the patterns remains high?
      • How can we ensure the library grows, evolves, & lives on?
      • Design Pattern Library Proposal
      • Jonathan's discussion of Workflow options: ** (see below)
      • Colin's preference for a community-driven ratings system (bottom of this page: http://wiki.fluidproject.org/display/fluid/Design+Patterns+Library+Proposal)
      • Discussion of Design Pattern Library Proposal
  • Where do we go from here?
    • Future meetings
      • Day, time, alternating AM/PM, breeze vs. teleconference?
    • Participants
    • What work needs to be done?
      • bug fixing in Drupal: http://osdpl.fluidproject.org
      • UX Walkthrough of OSDPL application
      • Addition (& editing) of Sakai Design Patterns
      • Creation (& review/moderation of?) new design patterns
      • Future features
        • Workflow & Notifications of actions required: the submission and approval of patterns and changes to patterns, and notifications that review or approval is necessary. Though this hasn't been decided for certain, approvals of changes would likely be managed by a moderator or group of reviewers. This is to ensure the pattern library remains a very high-quality reference for its diverse users. Again, community ranking and tagging may play a role here.
        • User Roles: give users different levels of access to add or edit patterns based on administrator-defined roles
        • Personalized Tags & Tag Clouds: allow all users to create their own personalized tags which have meaning to them to filter the patterns
        • Ratings of comments
        • Customized views of patterns & User Profiles: allow users to view the uPortal example images for a pattern vs. the Sakai example images based on the community they are associated with their profile - likely a future feature
        • Interface with and connect users to the Fluid Component Library & Fluid UX Toolkit (could be as simple as creating links, or as complicated as creating a presentation framework for these two items as well)
    • How can we distribute our work?

Attendees

  • Allison Bloodworth, Fluid Interaction Designer
  • Daphne Ogle, Fluid Interaction Designer
  • Eli Cochran, Fluid Interaction Developer
  • Michelle D'Souza, Fluid Developer
  • Paul Zablosky, Fluid/UBC
  • Jess Mitchell, Fluid Project Manager
  • Rachel Hollowgras, Kuali Student UX Lead
  • Kathy Moore, Boston University
  • Nate Angell, rSmart (www.openedpractices.org)
  • Nathan Pearson, Sakai UX Lead

Notes

  • Paul - the pattern library should be a resource for developers
  • Your role in the pattern library
    • Michelle - can give feedback on patterns from developer standpoint
  • link patterns to fluid components
    • Daphne - authoring patterns, using patterns, from reference to inspiration
    • Eli - consumer and contributor
    • Allison - author, user, editor
    • Rachel - contributor
    • Paul - editor - the library should be a browsable source of good design examples
    • Nate Angell - I'm able to contribute in three ways: 1) help with drupal in the OSDPL 2) herd other communities toward participation (eg, drupal community) 3) advocate for tight integration with Sakai
    • I'll be "heads down" on Kuali Student for a while. New patterns may come flying out of that project, and the discipline and perspective that come from formally describing them will be helpful to me. As I can, I'll be happy to give feedback to others. I can probably make semi-monthly meetings, but for the sort term may not be a strong contributor.
    • Nathan - I want to continue to stay involved. But would like to discuss more.
    • Rachel - I'll be "heads down" on Kuali Student for a while. New patterns may come flying out of that project, and the discipline and perspective that come from formally describing them will be helpful to me. As I can, I'll be happy to give feedback to others. I can probably make semi-monthly meetings, but for the sort term may not be a strong contributor.
  • Jess - patterns provide best practices, allowing community to get involved in conversation about patterns
  • Allison - could create code nodes associated with the patterns
  • Nate - It's the rare community that has TOO much participation; I think we might focus more on seeding the library with good examples rather than concern over getting contributions that don't fit/measure up
  • I like the idea of patterns having different statuses (eg, reviewed by expert, brand new, etc) rather than being workflowed a lot
  • Daphne - have patterns been reviewed by an expert? what levels are people looking for - quickly tell them what to do vs. reading design rationales?, do we need different interfaces for different audiences? (e.g. less design rationale for developers...could be called a quick vs. detailed view)
  • Nathan - I just don't see too many developers using something like this. More over, I'm not sure it's necessarily a good idea to encourage developers to be designers (smile)
  • Michelle - however, lots of devs don't have access to design resources and something to follow is certainly better then developers running off and designing without anything
  • Rachel - I see is as a reference - something both designers and developers can look at and converge or elaborate on.
  • Nate - maybe publish quick "how tos" on the site for different user types; OSDPL for designers, for developers, etc.
  • Rachel - Some developers I've worked with have been exasperated by the "blankc canvas" that apps represent. They have been very happy to have design tasks offloaded to others. When they have design skills, so much the better.
  • Paul - think about how developers might want to use this...they have identified a problem to be solved that might be addressed in the library...that's a lot of steps...may be a better resource for "thin on the ground" designers who need help...can refer to the pattern in the library and show how it fits the problem they are trying to solve...aid to relationship between designers & developers
  • Michelle - developers were asking for design patterns
  • Eli will plug in existing patterns - won't have extra time until 0.3 Infusion is released
  • Daphne - the group could review file upload design pattern & drag and drop - layout preview patterns
  • Allison - send out link to JIRA where people can report issues with uipatterns.org, new meeting time and meeting instructions, create wiki page with Table of Contents with major questions, as well as our decisions, send out a "question of the day"

** 5/7/08 Email from Jonathan Hung
Workflow:
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).

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