OSDPL Pattern group kick-off meeting postponed to Wednesday, May 7th 3pm PDT/6pm EDT

[Jonathan Hung]

Hi Allison,

I will only be able to attend part of the OSDPL meeting tonight - I will be
on a train when it starts and then I will have to leave early to run to
another meeting at 7pm EST.

Just in case timing doesn't work out quite right for me, I wanted to offer
up my thoughts on a workflow for discussion. Hopefully I can catch up on the
discussions I'd miss via email / IM tomorrow.

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. ;-)


- Jonathan.





2008/5/7 Allison Bloodworth <abloodworth at berkeley.edu>:

> Sending this message to fluid-work alone since it had too many recipients
> and is awaiting moderator approval...apologies if you get it twice!
>  Begin forwarded message:
>
> *From: *Allison Bloodworth <abloodworth at berkeley.edu>
> *Date: *May 7, 2008 8:49:48 AM PDT
> *To: *jasig-ue at lists.ja-sig.org, Sakai UI UI <
> sakai-dg-ui at collab.sakaiproject.org>, fluid-work <
> fluid-work at fluidproject.org>
> *Cc: *Jonathan Hung <jonathan.hung at utoronto.ca>, Colin Clark <
> colin.clark at utoronto.ca>, Justin Obara <j-obara at rogers.com>, Kathleen E
> Moore <kemoore at bu.edu>, Daphne Ogle <daphne at media.berkeley.edu>, Gary
> Thompson <gary at unicon.net>, Tim Archer <tarcher at csu.edu.au>, Wai Chan <
> wlchan at mail.ucf.edu>, Emma Wibom <emma.wibom at it.su.se>, Judy Stern <
> jlstern at berkeley.edu>, Rachel Hollowgrass <rachel at media.berkeley.edu>, Eli
> Cochran <eli at media.berkeley.edu>
> *Subject: **Re: OSDPL Pattern group kick-off meeting postponed to
> Wednesday, May 7th 3pm PDT/6pm EDT*
>   Hi everyone,
> Just a reminder that the OSDPL pattern group's kick-off meeting will be
> held *today*, Wednesday, May 7th at 3pm PDT/6pm EDT/Thursday at 8am
> Australia Eastern on the Fluid Breeze server:
> http://breeze.yorku.ca/fluidwork. I will be posting an agenda on this
> page:
> http://wiki.fluidproject.org/display/fluid/Open+Source+Design+Pattern+Library+group+meetingslater today, and please feel free to add your own agenda items as well.
>  Hope to see many of you there!
> Allison
>  On Apr 16, 2008, at 5:38 PM, Allison Bloodworth wrote:
>
> Folks,
>  Although some of our stalwart pattern authors have told me they would
> definitely join us next week, I didn't get a huge response to this email
> from others interested in attending an OSDPL pattern authors group kick-off
> meeting next Wednesday. Due to the fact that I'll be speaking about the
> pattern library at the JA-SIG conference (
> http://www.ja-sig.org/jasigconf/popSpeaker.jsp?id=3d9f253f&conf_id=jasig13&name=Allison+Bloodworth)
> & uCamp, I'd like to move our kick-off meeting to the week *after* the
> JA-SIG conference to *Wednesday, May 7th* *at 3pm PDT/6pm EDT/Thursday at
> 8am Australia Eastern. That will give the folks hearing about the pattern
> library at the JA-SIG conference an opportunity to attend without missing
> the first meeting. If anyone has a preference about whether the meeting
> should be on a Breeze teleconference server vs. a phone line, let me know.
> *
>  And thank you Jonathan for your thoughtful response! Jonathan is also
> part of the Fluid Project, and has recently been working with the design
> pattern library. To reply:
>  1. I think this relates to the question of what purpose a design pattern
> library should serve. Is it a canonical collection of generally observable
> UI patterns (a la Christopher Alexander) across all or a certain area of
> software UI design, or is it a style guide for use by a particular
> community/company? I've seen both of these things done...however, most of
> the pattern libraries we have listed on this page are publically-facing and
> very general: http://wiki.fluidproject.org/display/fluid/Design+Patterns,
> with the exception of the Oracle Browser Look and Feel Guidelines. I was
> able to see the (non-public) updated version of Oracle's pattern library
> recently and though lots of the patterns were general, the content was
> somewhat company-specific--they did have links to their own UI components
> and had somewhat of a style guide-like feel.
>  I am hoping our pattern library can fulfill both of these goals to some
> extent, but think that in order for it to be as widely useful and long-lived
> as possible, we should probably should err on the 'canonical examples' side
> so that it can serve as a reference for anyone doing UI design &
> development. Yahoo!'s pattern library does this, is well respected and is
> often used as a reference outside of Yahoo!. I am hopeful that it will also
> serve as a sort of 'style-guide' by providing of example images for each
> community (for each pattern) as well as allowing folks to use tagging to
> find the patterns that pertain to them.
>  We could conceivably limit our scope to web applications, but with mobile
> devices becoming more and more important it may be important to consider
> different delivery methods as well...to some extent I think this will be
> determined by the community. I've posted a very interesting report by
> Patrick Stapleton of Oracle (who was thinking about developing something
> similar to what we are doing--an enterprise pattern exchange which would
> hold as many of the different UI pattern libraries as were willing to
> contribute) to our wiki (
> http://wiki.fluidproject.org/download/attachments/1707270/Developing+a+UI+Pattern+standard.doc)
> for anyone interested in more information. Here is what I find a helpful
> citation from this report:
>  *"**What this requires, of course, is to strike the right balance between
> too technology-centric, **short-lived patterns that essentially only
> describe what one particular (often graphical) user interface toolkit
> already implements, and "golden rules" that are always right, but never
> concrete and constructive enough to be of real value to the designer."**
> [1]<http://mail.google.com/mail/?ui=2&view=js&name=js&ids=1owfsmgj33lq4#119c472681eb16b4__ftn1>
> *
>   ------------------------------
>  [1]<http://mail.google.com/mail/?ui=2&view=js&name=js&ids=1owfsmgj33lq4#119c472681eb16b4__ftnref1> Patterns
> as a link between HCI and architecture - Jan Borchers
>  2. How to ensure a pattern library is a helpful, reliable reference that
> people can trust for good information in a community that values (and
> requires!) lots of community participation and involvement is still an open
> question. As you point out, Wikipedia is an interesting example, but I think
> it's a bit different since anyone can be an expert in the topics it holds,
> so it doesn't make sense to restrict contributions or even moderation to a
> small group. It is also such a huge reference that review of every article
> before they go live just wouldn't be practical. However, Wikipedia does
> still have editors, and perhaps we could learn something from their model:
> "The Wikipedia community is largely self-organising, so that anyone may
> build a reputation as a competent editor and become involved in any role
> they may choose, subject to peer approval." (
> http://en.wikipedia.org/wiki/Wikipedia:Editorial_oversight_and_control) I'd
> also argue that forums (and their moderation needs) are quite different from
> a pattern library since their function is to provide a place for people to
> discuss most anything, not provide guidelines or expert advice.
>  I'm going to go out on a limb here and say that perhaps the design
> pattern library is different, and we may want to have some sort of
> moderation to ensure that the patterns provided are vetted by design
> experts. Since a goal of OSDPL is is to help improve design in open source
> software, if design experts aren't ensuring the patterns added are based on
> solid design principles we could end up with applications with even more
> user experience issues than before. Conversely, I also want as much
> helpful content to be generated by the communities as possible and certainly
> don't want to set up a bottleneck. I'm hopeful that we could start with a
> group of moderators whose responsibilities diminished as the communities
> learn more about creating patterns (and perhaps as more pattern authors
> themselves became moderators), but would love to hear other ideas.
>  Looking forward to more discussion with everyone on all these topics!
>  Cheers,
> Allison
> On Apr 11, 2008, at 8:30 AM, Jonathan Hung wrote:
>
> 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
>
>  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
>
>    Allison Bloodworth
> Senior User Interaction Designer
> Educational Technology Services
> University of California, Berkeley
> (415) 377-8243
> abloodworth at berkeley.edu
>    _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>
 --
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/20080507/dde853f8/attachment.html>