OSDPL Pattern group kick-off meeting postponed to
Allison Bloodworth
abloodworth at berkeley.edu
Thu Apr 17 00:38:36 UTC 2008
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20080416/18572be7/attachment.htm>
More information about the fluid-work
mailing list