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.
Well this is neither
Just to say that I was in a three-hour meeting today where we discussed the issue of how best to specify a re-design for one of our clients. I can see this “content framework” thing has the potential to fry people’s brains if I give it to them unvarnished, so I only really hinted at it to test the water. People were thinking about working out a way of capturing the page designs and process flows, then hoping that something magical would happen to allow the content to populate that. I didn’t disabuse them of this notion as I need to see how things pan out on the project first. It’s a bit like Quake III: you don’t always want to use the BFG.
Hotting up
Right – things are getting interesting. I’ve been gently selling in this idea and people are beginning to see the light. We’re doing a mini presentation to the client this week to see if they’ll give us a slice of their content budget to deliver them a “framework” for the content that can then be populated independently of the CMS and content load stage. This is one of our main clients, so if we can pull it off I’m sure it’ll become a significant plank in our offering around site design and build overall.
This article is good to read as background to why I think this approach is good.
This is interesting.
This is interesting. Is the “content framework” actually another technical artefact, ie a piece of software, or a set of guildelines or specifications? Maybe in my usual idiotic fashion I’ve not been reading properly and you have already answered the question in the posts above, but yes, this is a common and latminute problem for me as well, and I’d be interested in learning how your theory in practice makes things better.