8 Features to look for when choosing a CMS
At this yearâ€™s @media conference in London, I presented on the subject of Content Management Without the Killing. The slides alone donâ€™t tell the full story, so I am aiming to serialise some of the main themes as articles here. This is the first such article, and focuses on the features you should look for when choosing a content management system.
Clean URL Design
One of the key features to look for when evaluating a CMS is its ability to publish content with clean URLs. Not only because you want to be publishing content with nice clean URLs, but because this tends to betray the manufacturerâ€™s underlying understanding of how the web works.
Being able to write software and having a good grasp of how the web works are two different skills. All too often you find that content management systems – even big commercial ones – can be written by teams with an understanding of the former, yet not the latter.
So why is this important? In his 2006 presentation Native to a Web of Data, Tom Coates talks of the importance of URL design, summarising by saying:
â€œUse readable, reliable, and hackable URLs.â€
URLs should be readable – a visitor should be able to get a good idea of what the page is about simply through the component parts of a well structured URL. This can be hard to achieve if your content management system constructs its URLs using obscure article or category IDs – the visitor canâ€™t get a sense of the pageâ€™s content from numerical IDs. Whatâ€™s more, descriptive, readable URLs index better for search engines and therefore make your content more findable.
URLs need to be reliable. Once released out into the wild, a URL should continue working, ideally forever. Itâ€™s a lot easier to ensure that if your URL is an alias and not a direct representation of the underlying technical infrastructure.
URLs should be hackable – and by that we mean a visitor should be able to intuitively make changes to a URL to get to other content without the need to follow links.
If you need a content management system, itâ€™s because youâ€™re publishing a lot of data to the web. If youâ€™re publishing information to the web, you should be making that information easy to find, read and track. The best way of doing that is to publish your information in RSS or Atom format at the same time as publishing to HTML.
By having your content management system publish feeds for the content on your site, you not only enable customers to subscribe to your site and receive notification when new items are published, but along with appropriate licensing, you simultaneously enable people to take that information and add value to it in ways youâ€™d never expected.
Data Stored in an Open Format
No CMS is forever, and at some point you will find yourself needing to get the data out of your CMS and into something new. Most content management systems store data either in a relational database or as XML, and itâ€™s important to have an overview of how that information is stored so that you can be confident that when the time comes it will be possible to practically move that data out and into something else.
I always suggest that data is stored in an open format, or at least in a very common format. To say â€˜openâ€™ I mean that the format is not owned and controlled by a single commercial entity, but rather a freely usable standard. This helps to ensure that the storage format you are using isnâ€™t going to be discontinued and become inaccessible in the future. XML is a good example of an open format. If storing data in a relational database, MySQL is a reasonable choice as it is both an open source product and also uses a reasonably straightforward dialect of SQL.
I worked with clients in the past where the only method of getting data out of their proprietary format database was to invest thousands of pounds in upgrading to the newest version of the product – simply to be able to move away from it. That sort of surprise is never much fun, and often comes just at the time when your budget has been allocated to putting the new system in place, never mind removing the old.
Customisable and Accessible Administration Interface
Whilst your site visitors will spend their time with your siteâ€™s front end, those who are responsible for administrating the site, editing content and so on will be stuck working with the administrative interface. Depending on the scale of your operation, that can be a lot of time for a lot of people. Therefore, the admin interface should be easy to work with.
A lot of the time this means having the ability to customise the interface to your specific needs, being able to turn off unneeded elements to clarify workflows and make life easier. Youâ€™ll probably want the ability to brand the interface appropriately, too.
Search is a feature that’s often easy to implement, but really hard to get right. This is especially true if your site contains varied types of data. For a straightforward articles-based site, a general full-text search across articles can work well, but do the results accurately reflect the context of the results in a way that guides the visitor to the most relevant articles?
If your site contains, for example, event information or perhaps office or store locations, can the search results page display those data types in a meaningful way so that a visitor can be confident theyâ€™ve found what theyâ€™re looking for before clicking through to the results?
As the volume of content in your site grows, search becomes an increasingly important method of navigating that content and so it is important to provide a good user experience.
If you run, or plan to run, multiple content managed sites it can be really useful to have a single CMS that can handle multiple sites rather than multiple instances of a single-site system. Not only can it save on cost, but also in the administrative overhead of needing to manage, upgrade and maintain multiple systems.
There are also great gains to be had if sharing any content between sites, with the ability to maintain and repurpose content centrally. If your sites require user accounts, and your visitors are likely to use more than one of your sites, it can be extremely beneficial both to you and the visitor to have those accounts shared across all sites.
Whilst it can be unwise to over-anticipate future requirements and buying into them before the needs are real, there are some elements that are important to think about early and be forward-looking on. One such element is the need to support multiple languages on your site.
Even if you donâ€™t implement the technology to deliver your site in multiple languages (and itâ€™s logical not to if you donâ€™t have this need), it is prudent to make sure that your content management system is storing and handling data using Unicode the entire way through the process. Provided that data is stored and handled as Unicode, future expansion to include support for multiple languages becomes much, much easier.
A site requires content management because it has a large volume of content, or wants to control the way that content is handled, not necessarily because itâ€™s a busy site with a lot of traffic. However, even if a site isnâ€™t likely to be very busy with traffic right away, it pays to think of how it will cope with higher traffic levels sooner rather than later.
Caching is the process of saving the result of expensive operations for reuse the next time that same operation is needed. For example, instead of piecing a page together by going back and forth to the database for each item of content, that process can be performed just once, with the resulting page being stored in a cache. The next time the same page is requested, it can very quickly be retrieved back from the cache without the need to rebuild the page. This reduces the demand placed on your server and therefore enables a site to cope with higher traffic levels more easily.
Many content management systems have multiple levels of caching to help with performance, and it really pays dividends to have the facility to do so available.
Recent and Emerging Technologies
With Web 2.0 taking firm hold, site visitors increasingly expect to see a range of more interactive features. Technologies like Ajax are easy to implement on the front-end, but can your content management system service the requests for data that are needed?
Can it output JSON easily?
Most content management systems have the facility to categorise content, but can content also be tagged if needed? Can those tags be searched easily to expose related content? Do your user accounts support OpenID authentication, and are names, addresses, events and the like stored as structured data so that they can be exposed using microformats?
Some of these are relatively new technologies now, but they are becoming more established all the time. If you donâ€™t have support for these features today, will your content management system feel like a dinosaur in a yearâ€™s time?
Of course, there are many features to look for when choosing a content management system, and many of them depend on the particular needs of your project. However, by spending time in evaluation and paying notice to some of the more core issues you can help to ensure that your relationship with your next content management system is not an unhappy one.