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
- The Open Source Design Pattern Library - preview release: http://osdpl.fluidproject.org
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
    - need to show patterns as child nodes of categories in navigation (may not work automatically with taxonomy_menu...must we enter every one manually?)
    - Remove line on Home page where it says a the page is "in" a category...because the home page isn't
    - Figure out how to deal with child patterns
      - add a 'child patterns' field near the top of the display
      - link to sub-patterns from main Drag & Drop pattern
      - allow patterns to have hierarchy beyond categories?
    - remove UI Design Patterns link from navigation? Or perhaps we should keep it if we may have other categories of patterns in the future? If so, we need to create a View for it.
    - make URLs nicer for categories (currently generated by taxonomy_menu module)
    - issues with text being left-justified (e.g. on this page: http://127.0.0.1/drupal-5.7/admin/settings/taxonomy-breadcrumb)
    - turn off unused modules
    - on some pages, breadcrumb shows "::" when taxonomy_menu module is used
    - Finalize Design Pattern submission form - Allison
    - Required asterisk missing from ImageField in DP input form
    - Tweak styling of OSPL site and check cross browser behaviour
    - Finalize Screenshot policy for design patterns (or do not use any proprietary screenshot examples)
    - Streamline sidebars in OSDPL to improve UX
  - 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
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.

Browser not supported