An important goal of a pattern library is to promote the reuse of design solutions. Pattern libraries should therefore consider offering artifacts that would make use of a proposed solution easier for both interaction designers and developers. For example, to facilitate reuse by interaction designers, pattern libraries can include sample site-maps, workflow diagrams, and wire-frames; these many be in the form of stencils or visual components (Figure 13.4).

Similarly, to facilitate reuse by developers, include code snippets in HTML, CSS, JavaScript, PHP, ASP, JSP, and so on, as appropriate for a development team, to make it easy for them to copy and paste snippets in their code when building the application (Figure 13.5).

When offering software components for reuse, it’s important to test them for necessary cross-browser compliance, performance, and interaction with other components before including them in the pattern library. It’s also important to emphasize that components may not be completely pluggable solutions and may require some tweaking and updates. As development team practices and technology change, review and retest components to ensure their continued usefulness.

By definition, patterns prove their merit by their use (Winn and Calder, 2002). Without clear evidence of successful use, patterns may have limited “strength.” Alexander’s patterns (Alexander et al., 1977) and a few user-interface design pattern collections (Bochers, 2001) usually indicate the strength of a pattern using a star-rating system (Graham, 2003). Graham (2003, p. 52) states:

Applying a star-rating system is difficult because it requires a judgment on the part of the pattern authors or the design team (one of the reasons for its absence in this book). In addition, applying a star-rating system in a corporate setting may be counterproductive, as it may appear to offer design teams leeway when they consider patterns with lower star ratings. Including several examples of usage of patterns is more effective because users can see instances of a pattern’s use and determine its appropriateness for their design problem. Furthermore, patterns are often derived from actual use rather than theoretical constructs or principles, making it important to include a range of examples that show the use of patterns in a variety of applications (Figure 13.6).

In addition to actual screenshots that illustrate the pattern’s use, consider showing users a list of applications where the pattern is used. This is particularly useful for corporate pattern libraries, where showing reference implementations of suggested patterns by even a few product lines within the corporation can both justify their use and allow designers and developers to explore different ways in which patterns are applied (Figure 13.7).

Many design patterns, especially for Rich Internet Applications (RIAs), are embodied in the user interaction. Such interactions can be made clearer if users can experience the interactivity suggested by the pattern. When such is the case, it’s useful to allow users to experience the interactivity as an interactive prototype, animation, or movie (Figure 13.8).

If accessibility and internationalization-related design patterns are not separately documented, it’s important to include relevant best practices with the patterns themselves; the necessary accessibility and internationalization hooks should be included in corresponding software components as well.

Although a few of the current pattern libraries include accessibility considerations (e.g., Yahoo! Pattern Library, UI Patterns, and Fluid Open Source Design Pattern Library; Figure 13.9), none currently include internationalization considerations. However, their inclusion is important for companies that plan to localize their applications (see Chapter 10 for details on internationalization considerations).

Antipatterns are inappropriate solutions that appear to be good solutions to a given problem; they are also referred to as pitfalls (Gamma et al., 1995). Although not mentioned by Christopher Alexander (Alexander et al., 1977), who proposed the notion of patterns, there may be some benefit to including antipatterns in the pattern library if the use of inappropriate design solutions seems to be a common practice.

A good example is the HOVER & COVER antipattern noted by Scott (2008), who described it as when the hover actually hides important contextual information around the object or gets in the way of other actions (Figure 13.10). Antipatterns observed by Scott also include MEANDERING WAY, TINY TARGETS, POGO STICK NAVIGATION, LINKITUS, ANIMATION GONE WILD, WINDOWS APLENTY, and MISSED MOMENTS, among others.

Because antipatterns are design practices that should be avoided, they should reference appropriate design patterns or suggest design practices to improve the design. An alternative to including antipatterns is to indicate the correct practice within the original pattern itself. For example, when describing a hover pattern, one of the best practices (or the “how”) can indicate that when using the hover method, the contextual information or actions around the object should not be occluded (i.e., covered).

To encourage use, pattern libraries must make finding appropriate patterns easy. This can be accomplished by allowing users to browse patterns in multiple ways such as by user tasks, design requirements, application type, alphabetical list, and so forth (Figure 13.11).

When listing patterns, include a thumbnail of the pattern to make it easy to scan patterns and identify an appropriate match, as well as discover other relevant patterns (Figure 13.12).

Designers would also benefit if they were provided assistance in selecting appropriate patterns based on one or more design goals; this is especially helpful when choosing from a set of seemingly related patterns. As with the FILTERING pattern (see Chapter 6), users can adjust their design criteria to narrow or expand their pattern choices (Figure 13.13).

To encourage participation from other designers and developers, enable users to rate patterns, post comments, and/or suggest ideas for new patterns (Figure 13.14).

Although not common, it helps to allow designers and developers to suggest and publish patterns in an open-source fashion. At a minimum, it should be made possible for them to submit examples and screenshots for existing patterns, which may be added as photo galleries. With each example, users may indicate how the pattern was used and their comments on the evidence of successful use or contexts in which its use was found to be inappropriate.

A good example is UI Pattern Factory. They allow users to contribute pattern examples using Flickr. Users can join the public Flickr group (UIPatternFactory.com), upload screenshots, tag them with the pattern name, and submit them to have them included with other examples for that pattern (Figure 13.15). In addition, participation from users should be acknowledged not only to recognize their contributions, but also to serve as an incentive for others to contribute.

To ensure that interested users can keep themselves informed of the changes, offer them the option to subscribe to RSS feeds (Figure 13.16).

Finally, and perhaps most important, pattern libraries should be managed just like any other software application. In particular, they should have a clear process around adding, updating, and archiving (or deprecating) patterns. It’s also important to determine the process around the approval of patterns before publishing them. The process should indicate how patterns move from a draft or proposed stage to the approved stage, how participants provide feedback, how disagreements are resolved, how each proposal will be voted on, and so forth (Figure 13.17; see Crumlish, 2008; Malone et al., 2005). If software components are included in the pattern, it’s important that the processes around code review and testing are included as well.

To ensure that the pattern library stays relevant and useful, it is important to monitor and refine or extend the patterns to ensure their continued efficacy and applicability. Some patterns may become obsolete because of improved design approaches. For example, the design pattern CAPTCHA (see Chapter 3), although appropriate now, may become obsolete as other technological approaches emerge to distinguish between humans and automated agents.Alternatively, some patterns may not change in how they work but have to be updated because of improved implementations. For example, forms that were once laid out using tables may now be positioned using cascading style sheets (CSS). Any such changes made to the patterns must be marked as “updated” to inform designers and developers of the changes; the changes may be sent out via RSS feeds as well. To ensure that changes to patterns are not made in an arbitrary fashion, it’s important to define and adopt some form of change control process.

A wiki should be considered for developing pattern libraries, since they make collaboration easier by allowing several people to add, change, and remove content (Figure 13.18). A wiki also maintains a history of changes and makes it possible to revert to a previous version, if necessary; such built-in version control makes a wiki useful for single-author pattern libraries as well. With features such as easy linking among web pages, a wiki also makes it easy to link related patterns. Finally, by supporting a discussion among its participants, a wiki makes participation easier.