WebPatterns

Recently, the excellent web standards group mailing list had a discussion on reusable HTML chunks, which also included a little discussion of webpatterns. I posted a shortish comparison of how patterns compare with reusable code snippets, which I’ll repost here, as I think the issue is important.

Probably the biggest problem with web patterns is the term “pattern”. Most of us think about persian carpets or something visual when we hear the term “pattern”. But it has a precise technical meaning in this context, so I decided to go with it, despite the potential for confusion.

Originally, when I was first thinking about this whole issue (years ago now), I was thinking in terms of “templates” or reusable chunks. This is something which Doug Bowman and I chatted about a lot in the aftermath of WE04, and more recently Russ Weakley and I spoke more about, which took me more in the direction of patterns over more simple “templates”.

The drawback with shared templates is while these are immediately useful, they are also trivial. In the sense that they can be unthinkingly used, and by using them, no one gets anything other than the short term benefit of a shortcut to a quicker page. In real world situations, while little reusable chunks are very useful, the whole idea does not scale up well. One you reach even major page fragments, they tend to become limiting, so people would start bending them to suit their needs, and all of a sudden you don’t actually get the benefits of reusable chunks anymore.

How do patterns differ? Well, a pattern (such as “login box”) certainly should include an example implementation, even a “canonical” one, but more importantly, would also outline the

• typical use cases for the pattern
• 
  
• other patterns which work well with this pattern
• 
  
• patterns which this pattern plays a part in
• 
  
• when NOT to use the pattern (simple example, radio buttons and checkboxes are often used interchangeably – but they are separate patterns, radio buttons should not be used when you want to choose more than one option out of three)
• 
  
• Semantics – the pieces of the pattern all have usable semantic names – in the login example, the whole chunk itself would have a name, then each of the individual pieces may have names – so you get common semantics for “free” – that way you can all of a sudden reuse CSS as well as HTML. Cool eh?
• 
  

So along with resuable code, you a whole wealth of knowledge which has been acquired by developers over time (an important thing about patterns is that they aren’t novel inventions, rather, they capture and formalize well established current practice – they “pave the cowpaths”)

Hope this helps make more sense of the aim of web patterns – at https://webpatterns.org and with the patternquiz there, I started in a top down way – but the bottom up way would work well too.