January 9th, 2009
Back in 2006, I wrote an article called The Elements of a Design Pattern which has proven to be very popular. The interesting thing about popular articles is they regularly get good comments, long after they were written.
Fast forward three years and today we get a comment from Tessie asking:
I am currently designing a pattern library for my company. Can you recommend any pattern library systems which we can purchase which is easy to update and features a commenting system?
I didn’t know the answer, so I pinged Nathan Curtis, who is our go-to-guy on building pattern libraries these days. Here’s what he wrote back:
Good question. In my experience, I’ve not come across a pre-fab application for documenting patterns, components, or other libraries of reusable design assets that have the types of attributes (e.g., Use When) and other specific features. Instead, I’ve seen that teams have gone one of four routes to publish library documentation:
- Home-grown systems: This is expensive and time-consuming, but ultimately the most advanced and tailored solution for an organization. Yahoo has written (on boxesandarrows.com) and subsequently spoken extensively about the challenges and roadmap they’ve traversed. Sun Microsystems has also use a custom website as the cornerstone of their efforts; lucky for us, they expose it to the community too at sun.com/webdesign/.
- Collaboration tools: One team effectively used Jive Software’s Clearspace tool that includes a well suited three-prong feature set: wiki (articles per pattern & component, including editing permissions for team & individual, commenting and ratings), discussion boards (new requests, general discussions), and blog (publish ongoing notifications and articles about the overall library).
- Basic tools: Other teams have set up a wiki or tried to transform a basic collaborative tool to publish patterns. This may be a good short term fix, but isn’t really a tenable long term solution unless you can really start to customize it.
- Documents: For better or worse, some teams don’t have access to web-based solutions for publishing a library, and this really hamstrings their efforts. That said, they’ve gone to great lengths to compose documents (like a “Component Guide”, “User Experience Guide”, or “Pattern Library”) that become a versioned document managed over time. Additionally, with a modular documentation system, they can architect their guides in such a way that pages can be linked to project-specific documents as appendices or even key pages to scale changes or overlay annotations.
Hope this helps!
I think it does! What do you think?Tweet