Patterns are big business in IT. You can't get far in OO programming before hitting a book about design patterns, stressing the need for standardized solutions to particular problems. When it comes to web development though, design patterns never really hit off. Maybe because of the chaotic nature of the so-called web standards, maybe because we as an industry are just not ready for them yet. That's no reason to ignore their potential though.
define: design pattern
A design pattern is a standardized and well-defined solution to a recurring problem.
The word "problem" in this context is quite loosely defined. For example, navigation is a solution for getting from one page to another, a breadcrumb is a solution for lack of orientation within a site, a sitemap is a solution for getting a grip on the site's complete structure, and so on ... Once we're talking about a recurring problem, we can look for a standardized solution and turn that into a "design pattern". Before it becomes a real pattern though, it's key to look at it from as many angles as possible, defining the pattern as extensively as possible.
To give you a good idea of what kind of angles we're talking about here it's probably best to use a real-life example making the article a little less abstract. One such simple and easy to understand web pattern is without a doubt the confirmation message. A simple message that appears every time a user completes an action successfully. So let's go from there and see how such a trivial element can be defined.
how to look at patterns
It's best to keep a broad view when defining a design pattern, considering all aspects and all situations where such a pattern might be used. Following are some common angles that keep popping up when examining a pattern from up close:
- functional angle: where should the message appear (close to the action element or on top of the page), should it be shown on a new page or through an AJAX call on the same page, how long should it remain visible when implemented with an AJAX call?
- graphical angle: red is probably not the best color to use, green the most obvious one, could other colors be used, should we add an icon and if so, what icons are best?
- copy angle: does the message need a title, should we address the user personally?
- front-end angle: can we write a standardized html structure, can it be visualized using a whitelabel css, are there accessibility concerns?
All these questions need to be answered in order to define the boundaries of this pattern. Then it's interesting to see if the pattern is not part of a broader whole. A confirmation is just a variation on a generic feedback message. There are errors, alerts, help messages and you can probably come up with a few others. So grouping patterns according to type might be a good idea, often leading to new insights.
so what, I'm a developer
Remember how I always go on about structure and components? Well, design patterns are the perfect way to start building towards standardized code. Once a pattern is defined it's pretty easy to write a fixed html structure that can handle all requirements made for that particular pattern. And if you have the time and/or means, why not add a whitelabel design. You can have a live prototype up and running in a mere day.
The only thing to note is that while a design pattern library gives you easy access to a set of standardized solutions and a wealth of knowledge, the web is ever changing and if you have defined a pattern one or two years ago certain things might have changed. A few years ago the tag cloud was the biggest hype, now almost nobody uses it anymore. So make sure you keep questioning the patterns you are using while at the same time enjoying the benefit of all the work you (and others) have done in the past.
While at first this topic might seem a little out of place on this blog, I figured a little introduction to web design patterns would still be useful. They are absolutely crucial in changing the way you think of html. Because html isn't a mere means to apply semantics to a single element or to structure a single page, it's a means to define components and to reuse these components throughout a whole site, even multiple sites.
If you want a good starting point, you can check the Yahoo library or Welie library. Both are pretty extensive and free to roam around in. These libraries don't feature html examples or css snippets, but once you have the functional (and sometimes graphical) requirements, writing up some structurally solid html for each pattern shouldn't be too hard.