Design Pattern Library Proposal (preliminary)

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