[Design Patterns] UI/HCI Patterns, PLoP, and Forces

Wed Nov 5 17:55:57 UTC 2008

Oops! Just realized I didn't include the list on this email...

Allison

On Oct 30, 2008, at 8:59 PM, Allison Bloodworth wrote:

> Hi Christian,
>
> It's so nice to see you on the list! I've added my comments  
> below...I look forward to speaking with you further about these and  
> other issues soon!
>
> Allison
>
> On Oct 28, 2008, at 10:12 AM, Christian Crumlish wrote:
>
>> Howdy, folks. Not sure I've posted here yet.
>>
>> My name is Christian Crumlish and the curator of Yahoo's Design  
>> Pattern Library. I recently attended PLoP (Pattern Languages of  
>> Programming) in Nashville and ran a UI Patterns workshop/roundtable  
>> and really enjoyed connecting to the core software-architecture /  
>> Alexander-aficionado / Gang of Four patterns culture.
>>
>>
>> In our discussion it became clear to me that the HCI/UI patterns  
>> community has drifted somewhat from the computer science / software  
>> engineer patterns world and I think it would benefit us all to have  
>> stronger ties.
>
> I hear you. In some of my previous presentations on design patterns  
> I've touched on how these various types of patterns relate, and have  
> definitely thought about it. Whether we should include other types  
> of patterns in the OSDPL was one of our discussion topics early on  
> (see http://wiki.fluidproject.org/pages/viewpage.action?pageId=2883725#Phase1-High-levelOSDPLDiscussionQuestions%26Answers-designpatterns) 
> . Additionally, a while back when I was proposing that our central  
> campus IT organization maintain the Berkeley Web Patterns Library (http://groups.ischool.berkeley.edu/ui_designpatterns/webpatterns2/webpatterns/home.php 
> ), it was suggested by others that we incorporate software/ 
> programming and other design patterns into that library as well-- 
> however we never took on this project.
>
> As in all user-centered design, I think understanding your audience  
> is key. Curator(s) of a pattern library should think about and  
> clearly define who their target audiences are--then they can use  
> that information to decide whether it's appropriate to include other  
> types of patterns. At UC Berkeley, and at many universities, I think  
> that the reality is that there are lots of programmers who end up  
> having to do design work. If they were the audience for the Web  
> Patterns library, it may have made sense to first reach them with  
> programming design patterns, and while they were there to also  
> expose (and potentially connect) them to UI patterns located in a  
> different part of the same library.
>
> I think they key to combining multiple types of patterns in a  
> library is a user interface that allows different types of users to  
> easily find the patterns they want and need. We've thought *a bit*  
> doing this in the Open Source Design Pattern Library by presenting  
> customized views to different audiences--with ideas ranging from  
> different communities (e.g. Sakai, uPortal, Moodle) seeing pattern  
> example screenshots of their own systems, to having different  
> versions of UI design patterns for programmers vs. designers. This  
> could be expanded to having different collections of patterns  
> presented based on role (e.g. don't show the "designers" the  
> software engineering patterns) or letting users create their own  
> collections of patterns.
>
> I find it really interesting that the Yahoo! pattern library seems  
> now to be incorporating a few less (physical) user interface- 
> oriented patterns. In the "Social" section, "The Competitive  
> Spectrum" pattern (http://developer.yahoo.com/ypatterns/pattern.php?pattern=competitive 
> ) is more conceptual, and doesn't even have any examples to suggest  
> a user interface/implementation. Was it a leap for you all to decide  
> to include these different types of patterns?
>
>>
>>
>> One thing that came up is that, at least at Yahoo, we aren't really  
>> sorting through the forces idea that rigorously, but this is core  
>> to how patterns are mined in the PLoP world.
>
> I think that the forces are implicit in some of our data elements  
> (e.g. "Problem" and "Use When"), but I'd love to hear more about how  
> focusing more on forces might help us create better patterns. I  
> agree that we could be more rigorous in our thinking about them.
>
>>
>>
>> In my job I have to walk a tightrope between purism and scholarly  
>> rigor on the one hand and pragmatism and providing useful  
>> referenceable actionable tools to the designers at Yahoo. However,  
>> project that are founded outside of Yahoo might be freer to pursue  
>> a more academic approach. Perhaps the open project you guys have  
>> started working on is the place for that. Yahoo's patterns are  
>> Creative Commons licensed, and as long as there's attribution they  
>> can be reused in full or in part of a derived work.
>
> Jonathan touched on this as well, and I'll echo that we've certainly  
> struggled with the practical vs. scholarly dilemma but our goal (at  
> least with the patterns we create) as members of the Fluid Project  
> is to build a *practical* library that will help designers *and*  
> developers create better user interfaces. But other folks creating  
> and adding other patterns to the OSDPL could certainly take a more  
> scholarly approach. We'd definitely love to include Yahoo!'s  
> patterns if it made sense.
>
>>
>>
>> Lastly, I'm interested in resurrecting discussions of PLML (pattern  
>> language markup language). We've been discussing it on the http://groups.yahoo.com/group/ui-pattern-authors 
>>  mailing list, and Martijn van Welie uses an implementation of it  
>> at his site. I feel that if Yahoo could embrace that XML dialect we  
>> might be able to help stabilize it as a core common structure for  
>> pattern sharing and interchange.
>
> I've always been interested in PLML! I studied XML in grad school  
> and actually wrote a fairly complex schema for a public calendar  
> "Event, " so I'd definitely be willing and able to contribute to the  
> schema for PLML. We've also had some interesting discussions here  
> about pattern library data elements (e.g. see the "OSDPL Pattern  
> Format" section in these meeting notes: http://wiki.fluidproject.org/display/fluid/Open+Source+Design+Pattern+Library+group+meeting+-+07-30-08) 
> , and I've always used PLML as a starting point for my thinking.
>
>>
>>
>> However, in light of my first observation, I'd like to be careful  
>> we don't tune it solely to the UI patterns tradition and therefore  
>> exclude opportunities to interoperate with other pattern languages  
>> out there.
>
> Agreed!
>
>>
>>
>>     --xian
>>
>>
>> -- 
>> christian crumlish, curator
>> yahoo design pattern library
>> http://design.yahoo.com
>>
>>
>> _______________________________________________
>> fluid-talk mailing list
>> fluid-talk at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-talk
>
> 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-talk/attachments/20081105/bae69ac9/attachment.html>