Distributed authorship or a central web content team?

When I began my journey through the wide world of web management, websites belonged to the IT department. They were hand built creations, coded in HTML, JavaScript, SQL and harder codes.

In those days websites were mostly online versions of the company’s marketing brochures, product catalogues and other printed material.  The actual ‘web’ stuff was functionality – early ecommerce engines, online forms, mailto addresses that let a customer send a message to the company with one click.

Actual ‘web’ content was an infrequent after-thought, sometimes added in after the developers had done ‘the real work’.

Then a few plucky souls managed to convince the devs that they could code basic HTML, without breaking anything. They started writing more web-specific content in between the chunks of code.

The Web Content Writer was born

These early web writers soon realised that people don’t read content on a computer screen the way they do on paper. They started editing copy down to make it easier to read on the screen.

About this time, some other very clever folks were working on the concept of Document Management Systems. A way to store documents in databases, using metadata instead to folders to save and find them.

It didn’t take these clever people very long to realise that the same thing could be done for web content. It took them even less time to realise that web content could be stored and served up in bits – images, codes, text, bits of functionality – rather than whole pages.

Now the content of the website could be separated from the code. Devs could write code to create page templates, control the navigation structure and create cool functionality.  Content could be added in afterwards, by non-technical people.

This separation of code and content is the definition of web content management.

Web Content Management was born

This opened up a whole new way of managing websites and brought them out of the IT department.

Website usually ended up being looked after in one of two ways:

  1. Content being added by – the Marketing team, Sales, Corporate Communications – whoever had a stake in the message.
  2. Dedicated web content teams, responsible for the site content and structure.

These two models of site content management are known as Distributed Authorship and Centralised Management. The question is, which one works better?

Over the years, I’ve worked in both models and they each have their strengths and weaknesses.

Distributed Authorship – lets content owners or subject matter experts write content directly into the site. You can be pretty confident that what they write will be factually correct.

If your distributed authors also write content for other media in your company, you can also be confident that the message will be consistent across those media.

What you can’t be so confident about is consistency across your website.

Even though most of the site design and formatting is locked down by the content management system, the authors still have to format their content – bold, italic, tables etc. If different authors across your company all format in subtly different ways, you site starts to look a bit, well, inconsistent.

And that’s just the formatting. What about the content itself? If you have different authors writing pages for your site, how confident can you be that your site will speak with a single voice? Or even a similar accent?

This is true, not just for the words on the page, but the headings, links, page name and the page title (the one in the HTML – it appears as the page name in your browser window). You know, all that webby stuff that sites like Google use to find your page and rank it higher than everyone else’s?

The average distributed author is probably not going to understand just how important these pieces of content are. Even if they do understand, will they know the right keywords to feature, and how to integrate them with all the other pages on your site?

Centralised Management 

OK, you say, distributed authorship has some problems. So why doesn’t everyone use a centralised management model?

The simple answer is time. Even the best web content teams end up being bottle-necks for content getting onto the site.

Enforcing all those site standards takes time.

Depending on the size of your company, and therefore the website, a centralised web management team could be handling 100s of page updates a week (or day if the company is really big). Each update needs to be:

  • checked against the company’s web standards
  • assessed for usability, SEO and other optimisation requirements
  • made in the pre-production site
  • reviewed and approved by the content owner
  • scheduled for publish

That is a lot of work.

The number one complaint I’ve always heard about web content management teams is that they take too long.

So which one’s the best model?

I’d love to have a simple answer for you. But it really depends on your priorities.

If speed and technical accuracy are key, distributed authorship is the way to go. If site consistency and standards are paramount, a central team is more likely to deliver.

My preference will always be centralised management. Given the growing pressure for web sites to be usable, optimised for search, optimised for smart phones, tablets and desktop and accessible. I just don’t believe distributed authorship can deliver a quality website.

But if your company has a large website and a high number of daily updates, you may have to use distributed authorship just to keep up!

If distributed authorship is your model, my advice is to build as much quality checking into the content sign-off process as you can.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s