Following up on part one of the Design Patterns conversation, I recently had the pleasure of speaking with John Allsopp about Web patterns. John is the lead developer of the Style Master CSS Editor and founder of Webpatterns.org, a site focused on the intersection of design patterns and Web development.
In John’s own words: “The purpose of identifying patterns is to use them in our work as designers, information architects, and developers.” We chatted about doing just that.
Q: You've pointed out that HTML has a long way to go to support the semantic structure Web developers and designers need to build today's generation of Web applications. As evidence you pointed to the myriad of CLASS and ID attributes in use across the Web. Are there any particular components or structures that really stand out as recurring needs that HTML is not addressing?
A: A combination of my -and others- empirical research as well as more qualitative research like that of François Briatte would suggest that to a significant extent, Web design is gravitating to a number of strong patterns, at least at the page and site architecture level.
Multi column layouts with headers and footers, breadcumb trails, tree-like page and site navigation, skip to content, search site boxes and other common elements recur frequently.
But, beneath this, at the level of the code, there is little if any consensus as to how these patterns should be coded, to the extent that in no case has a consensus emerged as to what to call these page components -as reflected in the various class and id values used to identify and classify them.
Now, in one sense, HTML addresses the need for all these components and structures, because they can be implemented with HTML and CSS. The question is should HTML provide any or all of these commonly used structures? I'd argue no. HTML is a low level language for creating more complex structures.
HTML also provides a generic mechanism for adding rich semantics to documents - the class and id attributes - which works in all browsers going back the best part of a decade. So HTML, in a sense, does address the need for these components and structures. It's really up to developers to form some kind of consensus regarding semantics and implementation of these components.
The key idea here is consensus. Individual approaches to rich HTML semantics are unlikely to gain widespread adoption. Projects like microformats show what a collaborative and cooperative approach can achieve. We need something similar which focuses on architectural semantics rather than data semantics, which is the prime focus of microformats.
Q: To what extent are these omissions tied to the fact that HTML is a mark-up for pages and, as a result, focuses on defining components like headings, paragraphs, lists, etc.? Surely this becomes problematic when building robust applications online that do a lot more than present information?
A: Certainly, the fact that HTML has its origins in analogues with the printed page means there is a tension between the kinds of patterns emerging that are unique to online use, and the built-in patterns of HTML -headings, paragraphs and so on.
Ideally, HTML would be a more generic language, with semantics added in specific domains -more like the XML model. But HTML is here to stay for a very, very long time. Fortunately, there are well-supported, non-hack mechanisms for extending its semantics -primarily id and class, but also the rel attribute.
So yes, the legacy of the printed page looms large with HTML, and potentially this causes difficulties when adapting its use to more sophisticated online applications than we typically saw over the first decade of the web. But HTML is also a reality we have to deal with for at least the best part of the coming decade.
Q: So what's the right way to address this lack of semantic definition present in HTML? Microformats? Shared CLASS and ID conventions? A user interface mark-up language like XUL?
A: Yes, Yes and Yes. In the near term, microformats (which rely heavily on id and class, as well as the rel attribute of link elements) illustrate a more general solution “for today’s web”. XUL (and XAML and XForms) point in the direction of potential future ways of building web-based user interfaces - declarative languages - but realistically, it will be the best part of a decade before these are widely supported.
Q: Seems like you've settled on patterns as a good way to build an extended Web vocabulary and your Pattern Quiz seems to be helping you work through that vision. What have you learned to date from the Pattern Quiz? What are the things folks seem to agree on and where has there been the most discussion or divergence?
A: Patterns are a widely used way of capturing problems and their potential solutions in a variety of fields, not least of all in many facets of IT.
In my discussions on this issue with many people over several years, it seems that when people initially think of ways of solving this problem of standardizing page and site architectures they think in terms of "templates". The idea being that if you can only capture the best possible solution for any given problem, then standardize its implementation, then everyone can use it and its a win for all.
What people soon realize, even in quite controlled environments like a single organization, is that a one size fits all approach doesn't work, it is far too inflexible - so people customize, "polluting" the one true solution, and you quickly return to the chaos you had earlier. Patterns offer far more flexibility, and as a result, potentially a workable way of solving the problem.
The idea behind pattern quiz was to get people to start thinking about what they do in terms of patterns in a more formal way. The weakness of most pattern language approaches to web development I've seen so far is that they are idiosyncratic - they rely on the work of an individual or small number of people, often in a close knit team. In this context it is reasonably easy to see consensus and a common way of working. This doesn't necessarily scale.
For standardization to work, it needs to work across the web of developers more generally. So pattern quiz was also an attempt to glean how this broader web of developers thinks about the common problems they are solving.
The quiz has not progressed as far as I would have hoped, which is largely my responsibility. My daughter was born shortly after the quiz started, somewhat curtailing my ability to keep several balls in the air at once. But one thing that did emerge was that people commonly think in terms of content, when it comes to patterns.
For example, when asked to classify the kinds of sites people could think of, I was thinking in terms of "blog", "search engine" "portal" and so on (largely content neutral), whereas many people suggested sites for a band, or a gallery or a bank (which to my mind could use different patterns to solve their problems - a band site could be a blog, or a more traditional static site, and so on.)
Another thing that emerged was a not uncommon attitude that by codifying patterns, somehow a developer's creativity would be stifled. This is an argument I hear commonly against the adoption of web standards. In the case of patterns, it comes in part from a misunderstanding of what a pattern is supposed to do. I put this misunderstanding down in large part to my inability to articulate what a patterns is and how it is useful more clearly.
Patterns are not supposed to dictate solutions, or suggest "one true way" of solving a problem. Rather, in Alexander's famous formulation a pattern "describes a problem which occurs over and over again ... and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice ".
But hopefully we'll learn a lot more in the coming months and more.
Q: How about flexibility? Have you found patterns to be flexible enough to accommodate the rate of change in typical Web applications?
A: To tell the truth I don't know. Patterns are meant to capture emergent behavior - not possible or tentative solutions, but problems which developers actually face, and the core of a solution to those problems.
So in theory, and I guess the longevity of patterns in other fields suggests that in practice, a pattern language approach does have the ability to adapt to the changing problems and solutions a profession encounters in its practice.
Q: Jenifer Tidwell has argued that we shouldn't tie design patterns to any particular technology or code-base:
"I worry about the longevity of technology-specific patterns. If patterns are closely tied to current technology, won’t they become obsolete really quickly?"
You've taken steps to ensure integration between Web patterns and semantic mark-up. What's the life cycle of a system like this? How long can it stay relevant?
A: I think that is a really good question, with a number of dimensions.
Firstly, if a particular methodology, like a pattern language, is going to be widely useful then it needs to be widely adopted. Wide adoption requires wide understanding of the methodology and its benefits. Technology neutral methodologies are a very hard sell, because in my experience as an educator, many people learn through concrete examples within a problem domain they understand. Hence "Web Patterns" focusing on patterns in the sphere of web development.
But there are two not so theoretical reasons why I think patterns are probably to a reasonable extent technology specific. As mentioned earlier, patterns capture problems and their solutions in a specific domain.
Patterns become obsolete when the problems they capture aren't problems anymore. For example, having a low resolution and high resolution image for fast loading slow connection pages isn't really a problem so much any more, so the pattern is obsolete.
The second thing is that patterns are not theories or conjectures - they are actual problems and their solutions. Right now, HTML and CSS are more or less the only technologies relevant to solving web problems when developing for the web. S its inevitable they ill be to an extent technology specific.
Above all, I think it’s a matter of giving it a go, then seeing what happens. Pattern languages have proven very useful in a number of domains. I have a gut feeling they'll also prove useful on the web. But I think in order for them to do so, any such project or projects need to be well explained, and have broad developer buy in.