WebReference.com - Chapter 1 of Content Management Systems, from glasshaus (3/9)

[previous] [next]

Content Management Systems, Chapter 1: Foundations of CMS

The Litany of Pain

Let's take a look at the main problems that plague web sites and, by extension, their authors, web professionals, and users. The effects are often cumulative and may follow the course we'll outline here.

Bottlenecks

First, there are bottlenecks caused because each new page of the web site has to be touched by someone. Say, the page is manually coded into HTML. Templates help, a little, but the number of new pages being asked for guarantees that the HTML coder runs the risk of becoming a bottleneck, falling further and further behind schedule.

Unintended Responsibilities

These bottlenecks create an unintended and undesirable social side-effect. As content contributors wait for you to update their content, they begin to understand that they don't control the site; you, as the site manager, do. They begin to perceive the web site as your sole responsibility and not theirs. Once they begin to identify the site as "Somebody Else's Problem", they become less inclined to contribute to it, or help fix it. Suddenly you, as the site manager, are not only responsible for the technical development of the site, but for its content.

This has disastrous consequences. If you are micro-editing/correcting the content of the site, you'll never get through the backlog of page production. You'll never have the breathing space to think strategically and tackle the more interesting, compelling problems. Worst of all, your authors will feel isolated from the site, and you'll lose the interest and support of the group of people you most need in order to make it a success.

Stale Content

As the backlog of HTML pages grows, the content that's already up on the site gets old and "stale". Updates to the home page become less frequent, so people stop checking it. Information never gets updated, so the data on the web site is deemed unreliable. People start bypassing the site altogether. You find HR sending out the new vacation policy to everyone in the company as a Word attachment because it's easier than waiting for a web page to be updated.

When the marketing folks want to change the design of the site, the web team will tend to dig in their heels. They're behind as it is, and don't have the time. Even simple site design changes can be painful, requiring a couple of weeks of overtime from the team. Of course, during that time, it's nearly impossible to do regular site updates. Your Perl guy is laboriously tweaking the script he wrote, changing "Register" to "Sign up" on every page of the site.

Inconsistency

The Perl guy is worried because he knows the site is inconsistent. There's been a succession of programmers, who all preferred their own tools and have their own coding styles. Different areas of the site handle navigation slightly differently and the site doesn't feel cohesive.

There's always one person on any team who can recite the history of their web site. "This," they may say, "works weirdly because we hired that one contractor before the Christmas redesign two years agoÂ" There were 'good' reasons at the time why short cuts were taken, and corners cut, but the team just never had the time to go back and clean up. So the site struggles on, somehow working, but underneath it's a patchwork of hacks.

The inconsistency isn't always hidden behind the scenes. A company's brand identity often suffers online. Without a web-oriented style guide and a template system that enforces it, the presentation of the company brand can be distorted by business users whose expertise is in content, not in managing and protecting the brand.

There is another reason for inconsistency. Often the site grows piecemeal, with different groups within the organization publishing subsections in an ad hoc manner. Little fiefdoms of power emerge, and there is a lack of clear leadership.

Low Quality

The inconsistency ultimately manifests itself as a low quality site. This has two separate effects:

The site just doesn't look good or work well Â reflecting poorly on your team and your organization. It's not fulfilling its potential to communicate, and this translates, in the language of the bean counters, into poor return on investment (ROI).
The site is no fun to work on. Low quality hurts the morale of your web team. If they don't feel that they are working on something that is inherently worthwhile, then it is hard for them to care about it, and if your web team doesn't care about the quality of the site, who will?

Inefficiency and Inflexibility

All the above problems add up to a site that is difficult to maintain. Its fragility makes its owners (rightly) fearful that it will break, so they hesitate to make improvements. Time is spent fixing broken links and tweaking design, page by page, that could be better spent elsewhere.

A brief example: I once consulted with the web team of a large, high-profile web site. Posted on the wall was a chart where they tracked the number of broken links (found using third-party link-checking tools). They had a campaign to scour the site and fix these links by hand. I took this to be a bad sign. While they should be applauded for doing their best to fix problems on the site, it was a terribly inefficient way for the team to be spending their time. Yet without a content management system in place, this is what they had to resort to.