What to look for in a Web Content Management System

Of all software purchase decisions, choosing a Web content management system (CMS) can be one of the most bewildering. Most estimates put the number of commercially available CMS packages at more than 8000, and these packages range from freely available downloads to enterprise systems with license fees that run into the millions of dollars. Clearly many different kinds of software and levels of functionality are lumped together under the content management system label, and choosing between them involves understanding where your needs fit relative to the broad spectrum of solutions offered. 

Key benefits of implementing a CMS

Two core benefits of any well-implemented Web content management system for both marketing/sales and IS departments are broadly accepted and most often discussed:

  • Lower maintenance costs through leaner content update processes because content owners can publish directly without costly help from Web designers.
  • More current and correct Web content because the delays associated with marketing to IS to marketing handoffs during the content development process are eliminated, which translates to a better site and more traffic.

But just because these are two key benefits that you should get from any CMS implementation does not mean that all CMS systems on the market will deliver them in your environment --- or even that they are the most important benefits that you could achieve. Below we will outline some of the key kinds of functionality you may want to look for in a CMS package, and we will give two examples of sample CMS implementations (each drawn from the experiences of multiple companies) in order to relate these functions to actual business benefits.

Functionality to look for in a CMS

First, here is the list --- key functions that you should consider in evaluating a Web content management system include:

  • Search engine compatibility: Internet search engines are the most important way that users find information on the Web, so any content that you publish must be compatible with the indexing programs (bots) that search engines use to build their database of results. This is a particular concern for dynamic systems that store content in a database and build pages “on the fly.” Many commercially available packages --- including enterprise systems with six figure license fees --- generate pages with URLs that search engines will avoid, which means that Web surfers will likely never find those pages. Look for a package that allows search engine friendly, custom URLs to be assigned to pages and lets users set individual Titles, Descriptions and other Meta tags for each page.
  • Multilingual capability. The Web is a global medium, and an increasing number of sites are finding that they must present content in at least two languages in order to serve their target market. Many CMS systems say they are multilingual capable, but what they actually mean is that they capable of displaying information in any single language. True multilingual support requires a content management system that supports multiple languages within a single site and facilitates translating and sharing content between different language versions of the site.
  • Publication without I.S. help. Some file-based CMS systems allow non-technical users to create content, but deploying the resulting files to production Web servers still requires help from the IS department. This requirement negates much of the timeliness and workflow benefit of a CMS.
  • Security management. It may be that not all information published to your website should be publicly accessible, and --- even for public content --- only designated users should be able to make updates. Most CMS systems allow for at least simple userid and password security, but the reality is that not all users who can update something on a website should be able to update everything. Security should be granular, multilevel and manageable by non-technical users. Ideally, even “read” level access should be controlled to allow for members-only content.
  • User-configurable workflow management. Just because authoring is distributed to multiple users does not mean that approvals must be. Look for a system that supports and automates workflows by routing updates to appropriate people for approval. Be careful of systems that offer “workflow automation” but really just automate one simple author -> approver -> live workflow. This may not work in your environment. Instead look for a flexible, user configurable workflow model.
  • Publication of documents, not just HTML. Most organizations have a great deal of information in the form of published or internal documents that never makes it to their Website because they do not have a practical way to put it on the site in an easily findable form. Look for a system that allows for publication of documents in addition to HTML, and ideally one that includes a search function for all site content in any format. This ensures that the content of relevant documents will be found.
  • User configurable content types and templates. Many basic CMS packages --- and even some midrange commercial ones --- allow for publication of only a few basic types of content such as a Webpage, a news release, and an event notice. Adding content types, or displaying content across multiple pages or with a unique look and feel requires extensive and costly modification

Sample CMS Business Requirements

Let’s look at two sample CMS implementation scenarios (each is a composite of several actual companies) to see how the core CMS functions outlined above can become important to achieving real world business improvements.

Multinational eCommerce Website

Worldwide Widgets, Inc. manufactures and distributes widgets in the United States and several European and Asian countries. Their Web site was originally available only in English, but the company invested in translation management technology that enabled content to be easily extracted from English pages files and translated. Once translation is completed by human translators, copies of each Web page are generated in each language. This is a better solution than having translators work with HTML pages as many multilingual sites do (called “trans-coding”, this method requires translators to be programmers), but it still requires heavy IS involvement. Changes take a long time to be made in English and much longer to ripple out to the other language sites. Because they follow a strict translation model, site content cannot be localized to each language and market.

Worldwide wants to implement a CMS in order to simplify content creation. They want English-language content to be developed by marketing resources at the US headquarters and published to the website in English. Marketing managers based in other countries will then select content to be translated to the languages for which they are responsible, arrange for its translation, and publish to the website in their language, all without IT involvement. Local country managers should also be able to localize content as appropriate for their market and even create new content and, after appropriate approvals, publish it to the Web in their language.

This business scenario suggests several requirements. Clearly a mono-lingual solution will not work. Furthermore, in order to speed up and automate content flowing between the various individuals that will be involved, the CMS they choose will need user-configurable workflows that allow approval and translation workflows to be configured independently for each site/language. The number of languages and the amount of content involved dictate that this solution must allow users with appropriate authority to publish content directly to the Web without IS help, and in order for this content to be found, it must show up in search engines.

Looking deeper at Worldwide’s business requirements, we can uncover one additional requirement. The process of publishing and translating print documents is as complex and slow as the Web content process. If Worldwide implements a system that allows them to upload and manage non-HTML document content, to create custom content types and associated workflows, and to output content to print formats as well as the Web, the could also solve their offline content management needs.

Community Portal Websites

Oakville Publishing, Inc. is a firm that publishes community newspapers in a number of small to mid-sized communities over a three-state area. Two years ago, they decided to supplement their newspapers with community portal websites in most of their markets. The websites serve as a clearinghouse for community news and events, and provide an online supplement to the newspapers. Revenues come from the sale of advertising on the site by the same commissioned outside salespeople who sell print advertising.

However, this online endeavor has not been able to make a profit, and was to be discontinued. While the websites provided a valuable service to the community and enjoyed good traffic volumes, the expense of maintaining the sites was too high to be supported by advertising revenues. Site updates required the efforts of not only the usual editorial staff, but of two individuals who specialized in web design and maintaining the web server. Staff regarded the web publishing to be a distraction from the firm’s core competency – publishing newspapers.

For customer advertisements, salespeople wrote copy working with the customer, and submitted it to the inside ad editors, who edited it and sent it to the web developer. The developer prepared an HTML “proof” page, printed it, and sent it back to the editor who sent it to the customer for approval. Edits or corrections started the process over. Finally the content was posted, but changes required a new cycle of authoring-editing-proofing. As a result, the site had to charge advertisers for changes. These update charges plus the time delay in putting up content made the sites inappropriate for any type of advertising that was not static in nature.

Oakville decided to “reinvent” the way business was being done, and see if the websites could be made viable by implementing a CMS. The workflow they designed is as follows:

  • Content changes should be edited and published to the site daily directly by the editors. Publishing to the website should be been seamlessly integrated into the normal publishing workflow.
  • Salespeople should author and publish customer advertising pages with their laptop computers with the customer at the point of sale. “Standard” image libraries and design templates should be available, and should be customizable on-the-spot with the customer’s logo and design elements. Once the customer approves the ad, it should be published to the web before the salesman leaves the customer’s premises.
  • The site should provide a granular security model that enables customers to edit their own advertising, using just a web browser. This will allow for update charges to be eliminated and also make the site available to new customer segments and new uses. Merchants will be able to announce sales. Restaurants will be able to change their menus. Realtors will be able to post latest listings.

This visionary workflow design implies some substantial requirements for content management. The system chosen will need to support:

  • A security model that includes end customers editing data and having the edited pages automatically forwarded for timely approval by ad editors.
  • An image and template library that allows users to select from stock images and look and feel templates for displaying their data.
  • Web based administration and editing.
  • An easy, readily-learnable user interface that customers can interact with.

Contact iData to learn more about our Web content management solutions.