Fwd: OSDPL Pattern group kick-off meeting postponed to Wednesday, May 7th 3pm PDT/6pm EDT
Allison Bloodworth
abloodworth at berkeley.edu
Wed May 7 17:28:46 UTC 2008
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+meetings later 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]
>>
>> [1] 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080507/4cd98e6a/attachment.html>
More information about the fluid-work
mailing list