OSDPL Requirements 0.1

Jonathan Hung jonathan.hung at utoronto.ca
Fri Apr 11 15:30:37 UTC 2008


That's quite a distribution on this email Allison! :) It's great to see all
the different communities involved in the process.

I've looked over the document on the wiki that you linked in the email and
here are some initial thoughts.

1. "generalizable across communities" vs. "communities to grow their own
design patterns"

I don't think generalization should be the objective. Rather a collection of
patterns, derivatives, and variations from different communities inform a
larger general pattern.

A general pattern is great for understanding the larger scope and context of
the problem and solution. but once you go beyond that to implement the
pattern, community specific content will be important to help those users. A
pattern specific to a community isn't a bad thing - we should encourage both
kinds of content.

2. Single volunteer moderator and community process

I spent 4 years as a volunteer moderator for a popular technology website.
>From experience, relying on a moderator to perform the work or act as a
gatekeeper is a lot of responsibility. On the community I was on, there
were 24 moderators and turn-over was about 6-9-months.

We also discovered through experimentation that self-moderation was the best
approach to forums that were difficult to deal with. For example the Debate
forum was self moderated and eventually had less problems than when it was
moderated by 3 or 4 people. Where self-moderation failed, we had facilities
in place so that users can report to higher authority.

Being an open source design library, I think a community process is a
logical process to adopt. I don't think I need to go into the reasons why.

When I think of community process I invariably think of Wikipedia and Digg
as excellent examples of how collaborative sites should be run (not perfect,
but pretty good).


I will be a little late arriving to the meeting on the 23rd.

I'll add more thoughts as it comes to me.

- Jonathan.

On 10/04/2008, Allison Bloodworth <abloodworth at berkeley.edu> wrote:
>
> I'm adding fluid-work, sakai-ux and jasig-ue to this thread now.
>
> The group working on the Open Source Design Pattern Library (OSDPL)
> infrastructure has been discussing requirements and community process (much
> of which can be found at:
> http://wiki.fluidproject.org/display/fluid/Design+Patterns+Library+Proposal).
> We realized the discussion was getting so interesting it was time to add the
> mailing lists and ask for your feedback! :)
>
> I anticipate that the community process discussion we are beginning here
> will continue 'in person' with the first meeting of the group of potential
> OSDPL pattern authors (other interested parties are also welcome to attend),
> which I'd like to organize for the week of April 21st. Since a major focus
> of the Sakai-UX calls in the past has been design patterns and because there
> are fewer agenda items & folks participating in this group's calls these
> days, those of us on the Sakai-UX call yesterday thought it might be a good
> idea to use the time this group has been meeting (Wednesday at 3pm PDT/6pm
> EDT/Thursday at 8am Australia Eastern) at least every other week for the
> OSDPL meetings. I believe we have at least one person in Europe interested
> in attending, so perhaps we will switch off and do it on Wednesday at 8am
> PDT/11am EDT/5pm CEDT(central Europe) every other week. However, we are
> happy to find another time if it is best to keep this time open each week
> for the general Sakai-UX meetings.
>
>
> What do people planning to attend think of this timing (first meeting:
> Wednesday, April 23rd 3pm PDT/6pm EDT/Thursday 8am Australia Eastern)? I
> realize this excludes folks in CEDT from the first meeting as that would be
> midnight for them, but they can attend the next meeting, and I can
> definitely try to represent folks there if they can send their comments to
> me beforehand. Would folks prefer to do the call on a conference call line,
> or on a Breeze teleconference server (e.g.
> http://breeze.yorku.ca/fluidwork) or Skype since we have international
> participants?
>
>
> Thanks for your input!
> Allison
>
>
>  On Apr 10, 2008, at 9:53 AM, Colin Clark wrote:
>
> I strongly favour a community-driven ratings system. We need to keep
> sustainability in mind; we've got less than a year left on the funded
> project and a top-down moderation process will be hard to sustain in the
> long run.
>
>
> I think all the issues you raise can be addressed by a group of motivated
> participants who work to ensure the quality of the patterns stays high
> through commentary and ratings. A clear set of guidelines up-front about
> what makes a good pattern and how patterns should be annotated or modified
> across communities will make for a level playing field without need for a
> lot of heavy process.
>
>
> This discussion should really be happening on-list. Should I forward it
> along?
>
>
> Colin
>
>
> On 10-Apr-08, at 12:45 PM, Allison Bloodworth wrote:
>
> Hi Colin,
>
>
> Thanks much for your comment. I agree that having one moderator could be
> quite problematic if the pattern library grows very large, and it also may
> not be the right model for this community. However, I worry about allowing
> everyone to edit patterns at will without going through some sort of review
> process. This could devalue the library, especially if multiple communities
> are using it. E.g. the drag-and-drop layout preview could perhaps be written
> differently if targeted towards the uPortal vs. the Sakai community and, and
> we'd want to discourage groups from changing the patterns back and forth to
> better reflect their needs. I believe all the currently existing pattern
> libraries are curated in some way (usually by an individual--Sakai is
> somewhat of an exception to this, but: a) I believe there was usually group
> review of the patterns and b) I wonder if it may have gotten more traction
> with one person leading the group effort to develop and promote it).
>
>
> There is definitely more thinking to do about setting up a community
> process (which was started here:
> http://wiki.fluidproject.org/display/fluid/Design+Patterns+Library+Proposal)
> which will ensure the library is general enough to apply outside Fluid
> communities, like Yahoo! is, as well as ensure that it's truly helpful
> inside our target communities. My current thinking is that it would be best
> to have a workspace/'staging' area where changes and new patterns are
> created and reviewed by the OSDPL contributors (e.g. on a weekly call)
> before they are made 'live' (hence the workflow), probably meaning visible
> to people who haven't logged in. I think the library will have the most
> value if the patterns are written in a general enough way for them to apply
> across communities, and it will likely take some guidance to help new
> contributors write their patterns in that way. Perhaps we'll even find we
> need to evolve the concept of patterns to have one very general pattern and
> then the 'uPortal' and 'Sakai' take on it (though I'm hoping this can
> instead be accomplished by just showing examples of the pattern in uPortal
> vs. Sakai).
>
>
> I think it will be most important to ensure that edits and new patterns
> are approved by the group as the pattern library begins taking shape. As
> there are more and more examples of how to create a pattern, and as pattern
> contributors get used to writing general patterns this type of moderation
> may become less necessary. Perhaps pattern contributors should go through
> some sort of training before they become something like a 'committer' who
> can commit/contribute patterns without review? We could approve people as
> pattern authors in the same way we approve committers to the codebase.
>
>
> I also would like to see the ratings system functioning as you outline
> below, but perhaps with users of the pattern library (not just contributors)
> also rating the patterns.
>
>
> Anyway, lots to think about, and all of it is certainly open for
> discussion. :) I added your comment and my response here to the proposal
> page (
> http://wiki.fluidproject.org/display/fluid/Design+Patterns+Library+Proposal)
> as comments to keep all the info in one place. I also added the requirements
> list to that page.
>
>
> Ran across these resources this morning and thought that they might be
> helpful to you guys:
> http://drupalmodules.com/
> http://drupalcodesearch.com/
>
>
> Cheers,Allison
> On Apr 10, 2008, at 5:57 AM, Colin Clark wrote:
>
> Hi Allison,
>
>
> Nice list. A comment below...
> On 10-Apr-08, at 1:52 AM, Allison Bloodworth wrote:
>
> - 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. This is to
> ensure the pattern library remains a very high-quality reference for its
> diverse users.
>
>
>
> My preference is to leverage user ratings to encourage quality, rather
> than top-down moderation. The risk is that we have a single moderator who
> becomes a bottleneck to collaboration. I think we're better off putting
> together some simple criteria for what defines a "five-star" pattern,
> publishing them widely, and encouraging the group of contributors to
> self-moderate through ratings.
>
>
> Colin
>
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
>
>
>
>
>
>
>
>
>
> On Apr 9, 2008, at 10:52 PM, Allison Bloodworth wrote:
>
>  Hi Jonathan,
>
>
> It was good to talk to you today about the OSDPL. We discussed putting
> together a short document with the "requirements" for the ODSPL application.
> I realized that some of them are in this document:
> http://wiki.fluidproject.org/display/fluid/Design+Patterns+Project+Plan(see especially the: Current Implementation (website building tasks)
> section). However, a short, high-level summary of the requirements (which I
> will add to the wiki tomorrow) as I see them right now would be as follows:
>
>
> - Make the OSDPL look (and function for users) as much like the Web
> Patterns library (
> http://groups.ischool.berkeley.edu/ui_designpatterns/webpatterns2/webpatterns/home.php)
> as possible, with the exception of branding (my current thinking is that it
> should retain some Fluid-esque branding)
> - 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. This is to
> ensure the pattern library remains a very high-quality reference for its
> diverse users.
> - User Roles: give users different levels of access to add or edit
> patterns based on administrator-defined roles
> - Versioning: ability to view and roll back to previous versions of
> patterns (this comes for free with Drupal)
> - Tagging & Tag Clouds: this will allow users to filter the patterns (e.g.
> see all the 'sakai' patterns, or all the 'ucberkeley' patterns) to view only
> what pertains to them, using tags generated by moderators & pattern
> contributors
> - Personalized Tags & Tag Clouds: allow all users to create their own
> personalized tags which have meaning to them to filter the patterns
> - Ratings: enable users to rate patterns (and potentially pattern authors)
> - likely a future feature
> - 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)
>
>
> I don't see the uploading of multiple (e.g. example) images at once as a
> requirement at this point.
>
>
> I was working with a UC Berkeley i-School student to continue the
> development of the Web Patterns library last year. She implemented several
> of the above items (in a prototype fashion--some don't really work behind
> the scenes) at this URL:
> http://groups.ischool.berkeley.edu/ui_designpatterns/daniela/webpatterns/home.php
>
>
> I plan to play with the ODSPL Navigation first thing in the morning...more
> updates to follow! :)
>
>
> Allison Bloodworth
> Senior User Interaction Designer
> Educational Technology Services
> University of California, Berkeley
> (415) 377-8243
> abloodworth at berkeley.edu
>
>
>
>
>
>
> Allison Bloodworth
> Senior User Interaction Designer
> Educational Technology Services
> University of California, Berkeley
> (415) 377-8243
> abloodworth at berkeley.edu
>
>
>
>
>
>
>
>
>
>
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
>
>
>
>
>  Allison Bloodworth
> Senior User Interaction Designer
> Educational Technology Services
> University of California, Berkeley
> (415) 377-8243
> abloodworth at berkeley.edu
>
>
>
>
>
>
>
>



-- 
Jonathan Hung / jonathan.hung at utoronto.ca
University of Toronto - ATRC
Tel: (416) 946-8312
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080411/7e062f11/attachment.html>


More information about the fluid-work mailing list