13 April 2015
Have you ever noticed that when a web site is hard to manage, the Content Management System (CMS) almost always gets the blame?
Why do we blame the CMS? What did it ever do to us?
If you had a spreadsheet that was really hard to use, would you blame Microsoft (OK, sometimes it’s fun to blame Microsoft, but you see where I’m going here) or would you ping the guy / girl who created it?
There are a lot of CMS products on the market, ranging from high-end, all singing-all dancing enterprise systems that do everything short of making your coffee, through to low / no cost open source beasties.
But essentially they all do much the same thing – allow the separation of code and content in a managed environment. In other words, let the coders build code, templates, search pages, navigation, style sheets, applications etc and let the content girls and guys write content – without anyone stepping on anyone else’s code (I mean toes).
When you take a CMS “out of the box” it’s a pretty plain, vanilla kind of creature. No templates, well maybe one but it will be very basic, only one login and no actual content.
Do we all remember “Hello World”?
For a CMS to get out of that box (or downloaded application) and become a fully working website, takes a lot of work from a fair number of people. If any of those people decide to take shortcuts, or are told to do so by management to save time and/or money (a more likely scenario), the end result will be a website that is harder to manage in some way.
Let’s look at the steps needed to ‘stand up’ a CMS. (For those playing at home, stand up means to get a CMS up and running and hosting a working website).
1. First, set up the CMS for your site. What this means is creating an environment for each stage of the site:
and connecting each instance to a database to contain the content and code.
If these connections aren’t made the right way, you might not be able to move code and content from one environment to another easily.
2. Next, define and create roles for each person-type you need to run your site, e.g. Authors, Approvers, Designers, Developers and Site Managers et al. You’ll need to make sure these roles are the same in each environment.
Without these roles, or ones like them, you won’t be able to give your web team the right access to the CMS to do their jobs.
For instance you won’t be able to let content author write and edit content, while keeping them away from the code. Nor will you be able to give your site developers free reign over the templates and site functionality while making sure they don’t rewrite the content.
3. Now you have your base system set up, you need to decide what content and functionality you need on your site.
Most CMS systems I’ve worked with use a database to store the site content – text, images, videos etc – and all the code that defines the site. You will need a taxonomy to define all that content and code. This is your metadata structure and can be a major stumbling block for CMS driven sites.
Get your metadata right and your internal site search (and your CMS search) should be a lot easier to use. Get it wrong and your site authors and managers won’t be able to find anything in the site – they may even end up creating duplicate content or pages because they can’t find the original.
Not to mention, if you don’t have a clean, clear metadata structure, you won’t be able to build dynamic content into your site. Examples of dynamic content are menu pages that automatically update with new content is published and News pages that always show the latest news.
4. You’ll need a good information architect to define your metadata structure and build it into the CMS. Using this and your roles, you can start to create workflows to make sure each kind of content is viewed, approved and published by the right roles in the right order.
5. Now, and only now, you are ready to actually start building things in your CMS.
Ideally, your information architect and senior site developers should already have spec’ed out how the site will be structured and what templates will be needed.
This is one of the points where you can set your site up for success or failure. Most web teams will create a navigation structure and page templates to display content as required for Go Live.
Good web teams will go the extra mile and design and build a structure and templates that are flexible enough to cater for future needs. Extensible is the new black.
6. Once your developers have created all the templates, navigation code, style sheets and other back end components, your content authors can start populating the site.
7. Now you start the ‘real’ phase of the site build – creating pages.
This is another success / failure point. Your main focus at this point is on creating pages. Each content author is usually responsible for a specific section of the site. Their job is to make sure the right content is put in the right place in the navigation, using the right template.
They are all about the site navigation, page layout, content accuracy and (with any luck) usability.
What they are less likely to think about is those pesky Review Date and Content Owner metadata fields in the CMS. Those fields that seem irrelevant now but, if filled in properly, will be invaluable 6 – 12 months down the track.
This is where keeping your content fresh is made either possible or impossible. If each piece of content is tagged with a review date and the name of the Content Owner, you can set up automatic reminders to those owners to review and amend the content when it ‘expires’.
If they aren’t – content will linger on your site, untouched and slowly going out of date.
Two other fields content authors are unlikely to get excited about are the Page Title and Page Description. Again, two fields that seem fairly unimportant compared with getting the content right, but if you want your site search to deliver results, not to mention a good SEO ranking – your Page Title takes on a whole new importance.
The Page Description may not be important for your SEO or site search but it can be really useful in your search results – if it has unique and well written content in it.
This is a fairly high level description of how to build a website in a CMS and it skips a few steps but I think you get the point. All CMSs may not be created equal, but they really do work better if the people setting them up stop to think about how they might need to be used over time.
So the next time you find yourself complaining about your CMS and how hard it is to use, don’t blame the poor thing, it’s only a dumb application. The peopel you want to talk to are the ones who set it up.
© Copyright F-Two 2023
