Martin Burns
Since the first suit told the first web designer 'Update our site faster,' content management has been vital for professional sites. Why does it matter? What do you need to be doing about it?
It started small, like so many things. I was developing a wee site for a company, and suggested a press releases page. "Sure," they said, "but how do we get press releases up there." I really didn't want to be a typist for them, adding each release as it came along. So I put togther a simple CGI which took in the content of a form - with fields for headline, summary and body - and wrote a new file for the release, and added the headline and summary to the main releases page with the date. And because you don't want any Tom, Dick or Harry adding releases, I added the most basic security there is: a password field which had to match the password hard coded into the script.
This scored me a fair lump of cash (to my very, very small freelance bank account), and made me a guru to the client. Not bad for half a day's work. Even better, I now had a working system I could apply to any CGI based site with a minimum of work, but for the same fee. So even at this basic level, a CMS can make your life less boring and better paid.
But there were significant problems with this system which will become evident:
there was no system for approval of new content, just a one stop shop
It only applied to a small section of the site (I never did get the call "Can you make the whole site like this", but worrying about it kept me awake nights for a long, long time)
security was erm, less than ideal
While writing static files is good for performance, filling your filesystem with auto-generated filenames is never going to make life easy for you
It didn't do images. At all.
Spin forward a couple of years
I was working for a large corporate, with an extensive intranet. We'd been a bit sensible about this. Instead of having a central team dedicated to updating every department's site, we'd devolved the content production to each department. It's their content; they understand it better than us, right?
Being a corporate, we'd had FrontPage imposed on us. In this environment, it almost made sense - the FP extensions on the server and clear publishing path from development to production made it harder for the business units to screw up. But not impossible. We'd provided full FP training for anyone involved in the process, and given very, very clear instructions on design guidelines (see Palyne's excellent article about why this matters). However, there were still some users who insisted on using magenta text, adding useless hit counters and so on.Worse, there was nothing to prevent any of the following gotchas:
Content was rarely reviewed by many departments, and just sat there even when it was no longer true
Anyone in the department with rights to publish material could do so unsupervised - there was at least one incident of defamatory content hidden away
If Alice went to publish her content, Bob's content could be 1/2 finished, but still went live (at least we separated publishing by department, but it was still very difficult)
There was no way to prepare content in advance and schedule its launch automatically, which made it harder to schedule work to an even flow; work had to be done the day before its launch, no matter what the other workloads.
Each department still had staff who wouldn't dirty their hands with publishing material, instead relying on the admin staff who didn't necessarily understand (or even care) enough about it to get it right.
As with all static HTML sites, content is hardwired to presentation., particularly for navigation. The weekend I worked 22 hours to merge two sections because I had to hand-edit the navigation in every single damn page is unlikely to ever leave my memory.
So it clearly wasn't good enough. We went out into the market to see if there was any off-the-shelf product which would resolve these issues. But there wasn't (or if there was, it didn't work sufficiently robustly on our NT/ASP infrastructure).
Spin forward again
When the same client's senior management finally woke up to the fact that their site - while up to date in content - looked a bit tired (it had been designed 2 years before), we took the opportunity to save the client large sums of cash. Rather than every business area of the client (maybe 30 of them) faxing or emailing changes to a central web team to put in the publish queue, then have it sent back for checking, each business manager would be able to make their own changes, and pass them through their own internal signoffs automatically.
Here were some of the key requirements:
Content must be able to be edited without knowing any HTML, using a standard browser interface
Meta-content such as launch and expiry dates, content owner etc must be captured
Changes must go through an automatic signoff procedure - the system should notify each person in the workflow by email. This is not only real content but meta-content also.
Changes must only go live at launch date, and content owners must be notified of upcoming expiries
Changes to site structure must automatically update the navigation structure
Images must be uploadable
Each change must be independent of all other changes.
We quickly realised that none of this was going to happen without a database & template based site, otherwise the content would be too hard-wired to the presentation. As the site really did need solid reliability, we weren't going to mess about with toy databases; we chose Oracle. We also needed a product to do all of this - writing one from scratch was a non-starter as we wanted it to be good, affordable and delivered quickly. The choices were narrowed down to Allaire Spectra and Interwoven TeamSite. Both would do the job, but TeamSite was thought to be a better strategic choice as our Tech Strategy people wanted greater flexibility of application server (Spectra needs ColdFusion). See the review section below for more on these and other choices
