OSDPL Requirements 0.1

Allison Bloodworth abloodworth at berkeley.edu
Thu Apr 10 17:50:22 UTC 2008


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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080410/51911964/attachment.html>


More information about the fluid-work mailing list