Managing Content Another Way

Lawd – I is churnin’ it out today!

Why is content not treated in the same way as page designs and HTML?

On most projects, one of the primary deliverables is a set of HTML “templates” to be integrated at some point into a CMS. The CMS then uses these templates to render content loaded into it. This represents a transition from an initial set of page designs (usually developed with a graphics package) into a format (HTML) generally suitable for “decomposition” in some way.

So why doesn’t that happen for the content that those HTML templates display via the CMS? The content is, after all, dependent on the page designs. Whether a news article has a title and a sub-title on some pages, or an image and a box-out on other pages are all consequences of the design of those pages. For that matter, whether text is too long for a particular part of the page, or an image is inappropriate for that part of the user journey, are similarly determined by that design.

On every project I’ve worked on (or heard about), the job of managing the content in any detail has to wait until almost the very end of the build, when it can be “loaded” into the CMS. At that point, all sorts of things come out of the woodwork: missing content, unsuitable style, too many words, and other issues. All these things, if not corrected, will impact on the experience of the web site as surely as broken images or script errors. Yet it’s always a mad copy-paste rush followed by a mad QA scramble and much post-launch fixing. The pressue is even more acute when final sign-off for copy has to wait until that copy is in situ in finalised page designs.

It doesn’t have to be like this. What if content was treated in the same way as other build artefacts? What if a framework for the content of a site was constructed at the same time as things like the HTML or wireframes?

Well, it can. Bwhahaha!

Stand by for either a cracking follow-up post on this some time, or deafening silence.