breeze.yorku.ca/fluidwork. I will be posting an agenda on this page:
> 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@...> 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@...
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> Allison Bloodworth
>>>> Senior User Interaction Designer
>>>> Educational Technology Services
>>>> University of California, Berkeley
>>>> (415) 377-8243
>>>>
abloodworth@...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> ---
>>> 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@...
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Jonathan Hung /
jonathan.hung@...
>> 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@...
>
>
>
>
Some parts of this message have been removed.
Learn more about Nabble's security policy.
