Skip to end of metadata
Go to start of metadata

This document may not be current

For the latest information on the development of the OSDPL, visit the OSDPL Roadmap.


  • The primary goal: introduce design patterns as a way to design usable, high-quality user interfaces in specific contexts ("a proven solution to a common problem in a specified context").
  • Be practical. Intended mostly as a useful tool for junior/new designers as well as developers. It will not focus on creating a complete pattern language, or describing patterns in a more academic sense.
  • Be inclusive. Advocate the importance of accessibility in good design.


  1. Junior designers & designers who are new to the communities - they will likely both want to peruse the library to learn best practices as well as look for specific design solutions to problems.
  2. Developers who need to design the UIs they build - will most likely be looking for specific design solutions to problems, want more concrete solutions, and even code samples, pattern comparisons, demos, or components related to the pattern.
  3. Experienced designers - will probably browse the pattern library for inspiration, or to come up with innovative solutions to complicated problems.
  4. Creators of patterns, which may fall into any of the 3 categories above.

Logistical Details

  • Name: "Open Source Design Pattern Library" (OSDP Library)
    • We'd like to be co-branded by all the contributing organizations (e.g. Sakai, uPortal, OpenCollection, Moodle, Kuali Student), indicating that it is a cooperative effort of all these communities, and not exclusively a Fluid library.
  • Provide space for communities to grow their own design patterns libraries, and contribute to a larger library at the same time.
  • Designed so target audiences (see above) can quickly find needed information without feeling overloaded or overwhelmed. This can be accomplished various ways including clear organization, searching, and tagging.
  • Will initially use the UC Berkeley Web Patterns Library design/framework, likely implemented in Drupal. Continuously improved to include additional features, increase usability, and maintain proper focus.
  • Each community will be able to add and edit the patterns to create a collaborative working space. Perhaps use a system similar to the Sakai Design Pattern Library's to progressively graduate patterns to completed / finalized status?
  • A strategy for presenting examples to each community must be worked out; perhaps at least one general example will be shown at the top of the page, along with examples from each community which has chosen to add one. These examples could (at least initially) be hidden behind a closable panel.
  • There will likely need to be some coordination to:
    1. determine whether patterns are general open-source patterns or community-specific patterns
    2. determine whether patterns need be combined or separated
    3. to ensure the communities work together cooperatively on shared patterns.
    • A moderation process, either community-driven or led by a single volunteer, may be helpful here.  
    • However, because of the nature of design patterns, the hope is that most patterns are generalizable across communities. It may take coordination to come up with a final version of each pattern which makes sense to all communities.
    • In the future we'd like to use tagging as a filtering mechanism, e.g. to show which patterns apply to which communities, as some patterns may be community-specific (e.g. certain patterns relating to portlets may not apply to Sakai).
  • Foster a community to advise and assist with the creation of patterns. We'll create design patterns for each Fluid component.
    • help encourage and give guidance on the use of Fluid components, but could have direct links to other (e.g. libraries') components as well.
    • How tightly Fluid Components are integrated into the library is to be determined, as one pattern usually has multiple different implementations.
    • The library should include links components, code examples, mark-up primitives, HTML/CSS templates wherever possible.
  • We believe the OSDP Library will link to or incorporate Fluid UX Toolkit & Component Library in some way.
  • We'd like to find a way to represent or link to already-created patterns in other pattern libraries which would be valuable to the Fluid communities (so we aren't re-inventing the wheel). More thought has to be given to the best way to do this.

Relationship to Style Guides

  • The library may incorporate some elements of a style guide, though likely nothing as specific as fonts, sizes, colors, or editorial style. It would be the type of style guide which suggests best practices or guidelines, e.g. "this is what a Fluid component looks like in the Fluid communities."
  • Many things in the current Sakai style guide are components, implementations of patterns, or combinations of patterns. We may want to try to find a way to represent this information into the library so users have a "one-stop shop" to use when designing components for their community. Sometimes this is done in a design patterns library by showing this "best practice" as the visual (or code) example. Alternatively, we could determine which items should be in a separate style guide, create that style guide, and determine how to link or connect to that information most effectively.

Relationship to Sakai Design Pattern Library

We'd like to bring Sakai design patterns into OSDP Library because it will:

  1. offer a better presentational framework than the wiki
  2. allow Sakai patterns to be shared with the other Fluid communities as appropriate
  3. allow the Sakai community to leverage the pattern & component creation work of Fluid and other Fluid communities

OSDPL Requirements

  1. Make the OSDPL look and function like the Web Patterns library as possible, with the exception of branding (my current thinking is that it should retain some Fluid-esque branding)
  2. 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 or group of reviewers. This is to ensure the pattern library remains a very high-quality reference for its diverse users. Again, community ranking and tagging may play a role here.
  3. User Roles: give users different levels of access to add or edit patterns based on administrator-defined roles
  4. Versioning: ability to view and roll back to previous versions of patterns (this comes for free with Drupal)
  5. 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
  6. Personalized Tags & Tag Clouds: allow all users to create their own personalized tags which have meaning to them to filter the patterns
  7. Ratings: enable users to rate patterns (and potentially pattern authors) - likely a future feature
  8. 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
  9. 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)
On this Page


  1. 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.


  2. 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 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. (smile)


  3. 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.

    I'll try to draft some ideas and post them to this page in the next couple of days.