OSDPL roadmap (Jan. - Mar. '09), planned pattern workflow, and features

Owned by Jonathan Hung
Last updated: Mar 02, 2009 by Allison BloodworthVersion comment

Quick Background on Issues

In November 2008, user testing was carried out to test some features of the OSDPL. The results of that user testing revealed the following issues:

  • not clear how a draft pattern gets to a published state.
  • how does a pattern get promoted once in a published state?
  • how does the feedback process work on a draft pattern? Who gets to give feedback? Can others not on the system be allowed to be part of this process?

This document outlines the tasks and goals required to improve the above issues. A sizable portion of this work is dedicated to solidifying a "community process" in which various users and groups collaborate on design patterns. An outline of the interactions in this community process is also contained in this document.

Goals for January to end of March 2009:

  • Fix the site so it is usable in its most essential features.
  • Finish editing existing Fluid and Sakai patterns in the OSDPL.
  • Engage communities and build a sustainable OSDPL community beyond March 2009.
  • Implement a flexible pattern workflow and create site functionality that encourages and nurtures community participation.

These goals are accomplished via the timeline below.

Timeline:

Early to Mid January 2009 (Design Iteration 24):

Fix bugs and make critical improvements to existing site functionality.

  • Objective: get site stable and usable with essential bits in working order.
  • FLUID-1969 Fieldset for submit and delete buttons.
  • FLUID-1880 Large image upload error.
    • Can not fix. Appears to be a bug in Drupal 5, 6 and 7. Watching a patch. See comments in FLUID-1880 for more details.
  • FLUID-2086 Link text and title text should match.
  • FLUID-2099 A11y walkthrough.
  • Any other critical accessibility bugs raised from FLUID-2099 Filed into Jira. Nothing critical to be scheduled immediately.

Finalize community process, features, and begin work on it.

  • Jan 11 - Create a concrete draft of the proposed process and possible features.
  • Jan 12 / 13 - Prioritize issues in the draft.
  • Jan 12/13 to 16 - Revise then release draft to community for feedback.
  • Jan 19 - Revise draft based on community feedback.
    • Create Jira tasks.
    • Assign Jiras to individuals and iterations.
  • Jan 19 to Jan 21 (end of iteration24) - start planning work on community features (estimate resources).

Mid-Late January to Mid February 2009 (Design Iteration 24 to 27):

Polish existing patterns, create new patterns.

Mid-Late January (Design Iteration 25 to 27):

With the site working and usable, may make sense to set up a more secure development environment:

  • FLUID-619 - Version control customized Drupal files
  • FLUID-591 - Routine backup of site databases into SVN. (dump to TXT and put into SVN).
  • Extended feature: Setup a dev site of Drupal (if time allows and easily + quickly done).

Continue development of workflow and community features.

  • FLUID-2140 - implement workflow
  • FLUID-2143 - sharing of content with other networks
  • FLUID-2144 - "stamping" of content as it progresses through workflow.
  • FLUID-2141 - invitation feature that integrates with workflow.
  • FLUID-2142 - notification system that integrates with email, workflow, and content posting

Improve the look and feel:

  • FLUID-1899 Modify the front page to emphasize the community process and pattern content.
  • FLUID-1904 - Put "Skip to Main Content" link in header (a11y)
  • FLUID-2096 - Card sort pattern categories and derive a new categorization for patterns.
  • FLUID-2133 - Combine OSDPL's 3 FAQs into a single link to improve navigation.
  • FLUID-2138 - Trim the left sidebar navigation. Too long to navigate and process (a11y concern).
  • FLUID-2149 - Look and feel of the comment system should be thoroughly tested and updated.
  • Improve the navigation of patterns

Other improvements:

  • FLUID-2074 - current pattern displays itself as a related pattern (makes for confusing cyclical navigation).
  • FLUID-2145 - Investigate and implement a module to flag comments and content for inappropriateness.

Early to Mid February 2009 (Design Iteration 26 to 27):

Increase community involvement.

  • with some community features in place, we can start bringing in more people to get involved. This will help inform any improvements to be made.
  • Re-engage existing partner communities: Sakai, uPortal, Moodle.
  • Engage new communities. Possibilities: Mozilla, Yahoo, Drupal.
  • Identify components within those communities that have followed a good pattern and create an OSDPL pattern based on that component
    • then, invite that community to comment and revise on the OSDPL
  • Adapt creative commons patterns from Yahoo and other CC sources

Mid February to End of March (Design Iteration 27 to Iteration 29):

  • Continue to iterate and improve OSDPL functionality.
  • Continue to build community.

Design Pattern Workflow (with community interactions)

Previously, the OSDPL Phase 2 - Governance outlined an approach to the community process on the OSDPL. Though that document contains ideas which may be worth implementing, at this point in time we are looking to implementing the basic workflow:

  • a pattern workflow controlling drafts to published content.
  • collaboration functions betwen authors, reviewers, and other members of the OSDPL community during a pre-published pattern state.
  • collaboration functions betwen authors, reviewers, and other members of the OSDPL community during a post-published pattern state.

Conceptual workflow for a pattern

Draft Stage

  • Author has created a pattern that is incomplete. They can come back at any point to revise and improve their pattern.
  • The pattern is not visible to anyone on the OSDPL except to the author.
  • The author can promote their pattern to Request for Public Comments, Request for Edits, or Published.
  • If a pattern is being published without passing through the Request for Edits stage last, it will be stamped as not have been reviewed by an Editor.
  • If a pattern's URL is loaded by someone who is not the author, an appropriate message is displayed.

Request for Public Comments Stage

  • The pattern is made viewable to ALL registered users on the OSDPL.
  • These users can make comments to this particular pattern.
  • At this point, the pattern's URL can be used to share with others.
  • The pattern is clearly indicated as "Work in Progress" as to not confuse it published patterns.
  • The author can put their pattern back to Draft, or promote it to Request for Edits or Published stage.
  • If a pattern is being published without passing through the Request for Edits stage last, it will be stamped as not have been reviewed by an Editor.
  • Extended feature: allow the author to invite outside people to join the OSDPL and view their pattern at this stage.

Request for Edits

  • The pattern is made public only to Editors of the OSDPL.
  • Editors can view, comment, and edit the pattern. (See "Who is an Editor").
  • The author can put their pattern back to Draft or Request for Public Comments stage.
  • Once an Editor finds the pattern acceptable, they can Publish the pattern and be given a "Reviewed" (or similar) stamp/indicator.
  • While in Request for Edits stage, pattern Author can not Publish their pattern. They must revert it back to Draft or Request for Comments first.
  • If a pattern's URL is loaded by someone who is not the author, an appropriate message is displayed.
  • Extended feature: allow pattern author to publish their pattern, but flag it as "Not Reviewed"

Published

  • A published pattern is public to all users, registered or not.
  • Any registered OSDPL user can make a comment, rank, tag etc. (but not Edit).
  • A pattern can reach this point two ways: by an Editor and by the original Author.
  • If published by the Editor, the pattern will have an obvious "Reviewed" stamp and a link to a definition as to what "Reviewed" means.
  • If published by the Author, then the pattern is assumed to have not passed through the "Request for Edits" stage and reviewed by an Editor and will be stamped as such and an appropriate link to a definition.
  • Any published pattern can be revised and edited by the Author or Editor. Does not necessarily have to move back to a pre-published state.
  • Extended feature: once a pattern is published, any registered user can flag a pattern as inappropriate, request for editing, etc. This way there is some extra feedback between users, author, and Editors after a pattern is public.

Notifications:
As a pattern moves between stages, notifications are sent to relevant users:

  • Draft to Request for Public Comments: notifications sent to site mailing list subscribers and notification printed in appropriate location on the OSDPL site (i.e. the front page?) visible only to registered users.
  • any state to Request for Edits: notifications sent to pattern Editors.
  • any state to Published: notifications sent to site mailing list subscribers and notification posted to the site.


Who is an editor?
"Editors" are registered users who have the extra ability to view, comment, and edit all design patterns published on the site (with some restrictions depending on the state a pattern is in). They are knowledgeable pattern authors and experts who have a proven ability to create patterns and help others in doing the same.

Their role is to help review and edit design patterns. It's a good way for novice pattern authors to learn from more experienced people, as well as help do some quality control on the site.

Users become Editors after they have shown aptitude in this field, but it's not an automatic process (at least not right now). Candidates are hand picked by the community of Editors and evaluated on a case-by-case basis (like nominating and voting for Commit access on SVN).. Users can always request to become an Editor, in which case Editors will decide if that individual has merit.

Other Planned Features

The following features do not fit into the pattern workflow, but give extra functionality useful to enabling a community.

Improved Comment System

  • Improve the way the comment system looks and is used.
  • Feature comment statistics more prominently throughout the site whenever a pattern is linked.
    of comments).
  • Give ability to flag inappropriate comments.
  • Extended feature: Weighted emphasis based on number of comments (i.e. a "Hotness" scale based on frequency and quantity * Extended feature: Evaluate the possibility of ranking up or down a comment as a method of filtering.

"Share this with others"

  • While a pattern is being edited, the author can grant privileges to users they specify either by giving their email address (they will be invited to join the OSDPL if they aren't already a member).
  • On any given Published pattern, an option is given to a user to share a pattern with others via email, or a link sharing network (like Reddit, Technorati, Facebook, Digg, Wordpress, Blogger).

Updated look and feel

  • the site will be updated to feature patterns more prominently, and to convey a sense of the community process and features at a glance.

Ideas / Brainstorm of Possible Future Improvements

Random stuff. Some serious. Some not. What crazy thing can you think of?

  • Evaluate an upgrade to Drupal 6 with respect to planned future community features.
    • Drupal 6 for better Views and User profiles.
    • add customizable user profiles (images, signatures, etc.)

More discrete rankings

  • Ability to rank a pattern based on multiple metrics to help browsing and add interactivity to the site.
  • Possible scales: practicality, ease of implementation, design excellence, accessibility, and overall.

"Pattern Roulette"

  • a random incomplete pattern is selected periodically for users, and they are invited to participate.
  • Thoughts: possibly not hard to implement, but may be difficult to moderate and administer.

"Pattern marathon"

  • Someone starts a pattern, and then the next section is handed off to another user that is either randomly selected or specified by the current baton holder.
  • Thoughts: could be tricky to implement, and may be difficult to moderate and administer.

Pattern family tree:

  • Make it easy for a user to create a derivative or "fork" of an existing pattern. When the forked pattern is saved, a relationship is made between the patterns. This can then be visually displayed and navigated. The idea is to make it easier for users to create specific patterns for a community.

Discussion Forum:

  • Recommendation: go with content-centric discussions. Improve this point of interaction and consider a dedicated discussion forum at a later date.
  • If considering using a forum for discussions and news, we could use phpBB, an open source forum project (see this article for integration notes: http://drupal.org/node/14563)