In it, he argues that the idea that content is first, that we always can know what our content is before we begin to design for it, is wrong. He seems to be suggesting that it’s really structure which must come first, because we can’t truly know our content. He sites newspaper design using CMSes as the kind of environment in which you simply cannot know your content first.
Although I agree with some of this, I think that he is making a philosophical argument about how you can’t truly know your content. I think this is a dangerous idea, as the principles of content first will help all of us produce better sites. To know something truly is a myth. To know what something is like is perhaps all we can do, and Boulton does suggest this. The more you know, the better. Start there. If you understand your content, at least a little, you’ll be able to structure it better. But that’s the point: content first, structure next – then design for your content and how it is structured.
The real argument from Boulton that structure comes first misses years of experience from other design fields (which is funny since so many design fields are now looking to web design for their inspiration). Many physical design fields will instruct you to begin with program. You need to know what is going to happen inside your site, inside your building, within the furniture etc. In architecture, you don’t begin with the structure without first understanding who will use the building and how. This splitting of hairs argument does not help us think better about our work. It confuses us. Structure does not come first. The information, the data, the content, which we are trying to put online must always come first, whether we know it really well or only a little. How else can we structure it?
I know I am reacting strongly to Boulton’s article, because this idea is extremely important to me. I named my first content management system, Content First. My system was inspired by the idea that when we start to build a site using a CMS, we need to have a much more informal process, especially one not driven by design. When we begin, we’re still trying to sort out exactly what our site does. However, this not-knowing does not prevent us from beginning to structure our content. We start with some content, structure it, and then continue to define our content and repeat. Even Boulton points out, trying defining your content helps to structure it.
Web design is not print – it is almost never static, which means it is always about structuring general kinds of content, but still, you begin with the content. To even talk about web design like it is a one off, perhaps misses the point. It reminds me of the ‘Under construction’ signs that used to litter the net. We finally killed that idea by openly acknowledging that all sites are always works in progress. The content you write today could change tomorrow. But there will be similar elements: headline, byline, article body. And if the content significantly changes, then the structure and the design has to change.
When talking about knowing something, we should talk plainly. After all, when you hire a designer, you’re not going to tell them what your content is like. Being vague about it doesn’t help. You’re going to tell them what it is (in so far as you understand it). When we try to know something, we should say so with conviction. This helps us to move forward and to build. It helps the designers. It helps the programmers.