Sherry McMenemy, Sandvine
Only recently has the XML-based, DITA-compliant Content Management System (CMS) become the tool of choice for managing and publishing technical content. There are a myriad of vendors in this space, and sorting through them can be overwhelming.
There are resources available to help you get started on requirements, but many of them focus primarily on the technical aspects of content creation and management. The key differentiator among vendors really lies in the “people and process” part of the evaluation. Like anything else, CMS is just a tool you use to achieve a goal.
If you are getting ready to purchase a CMS, here are some considerations:
Do some research
Understand the basics of XML and DITA, even if you haven’t used them before. There are many free resources available, including thedita.xml.org resource directory, the w3 schools XML tutorial, Comtech’sIntro to DITA, and Rockley’s DITA 101 Guide. It helps if you have some experience with HTML. From a people perspective, this pre-training will help you assess the baseline level of those who will be working with the system, including how easily they can learn XML and in terms of “comfort”—not everyone is gonna love it, or even like it. If you can’t change the people, then you’ll need to look hard at ease-of-use as part of your evaluation.
Know your XML needs
You can transform XML data into different outputs but you may find that one system is better suited to your needs. Be aware that an XML CMS doesn’t have anything to do with DITA. If a system is DITA-compliant, it may be a better choice. Knowing your XML needs is related to knowing your XML/DITA training requirements. Ask all vendors if they include training in their implementation package and if the training covers XML and DITA as well as the tool itself.
Include technical and process requirements for content creation
Online resources such as dita.xml.org cover technical requirements well: be sure to cover dictionaries, language support, tables, find/replace (local and batch), as well as the editing environment. For example, many vendors offer “built-in” WYSIWYG editors and you’ll want to evaluate those for ease-of-use and integration. If content creators are new to XML, then a system that allows them to easily manipulate tags and also corrects/blocks incorrect tags is essential.
Editors are not created equal
The popular ones will give you a text view and WYSIWYG view, but may not allow you to toggle between the two during a session (in other words, if you make changes in text view and then switch views without saving, you lose your changes). In addition, people have personal preferences about editors. What works well for one person may feel “weird” to another. However, I wouldn’t recommend allowing people to use whichever editor they choose—you can better manage the editing process and troubleshooting if everyone is using the same editor. Test any editor plug-ins for the CMS—a good one allows you to manage files directly from the editor without having to go to the CMS, streamlining your process.
What can be imported and exported from the system?
Know ahead of time what you need to pull in. Consider what you might need to get out later. These features may impact your requirements and your implementation budget. You will need to import content, and the content will need to be mapped and converted to XML. Even structured content will probably need to be changed, especially if you are worried about DITA compliance. The export features are something you may need long term. If you want to change the CMS system or if some new technology comes along, it’s best to have options.
Budget for a consultant
A consultant is a requirement. A consultant prepares your files for import and he/she must be an XML/DITA black belt. They also train your staff as part of the implementation process. It’s best if they are with you during the vendor selection process to provide additional input and analysis. One thing to watch out for: some consultants have strategic relationships with one or two vendors, so check before moving forward with their recommendations.
Look closely at file management
If file management is unfriendly, then no amount of training will make your people happy. Remember, in the non-CMS world, file management is as easy as drag & drop, with basic versioning control. Anything more complicated will feel like an imposition, especially now that your writers are working on topics or snippets instead of managing a whole “book.” Find out how other assets are managed as well, such as images. How will multimedia files be handled? If you have localisation requirements, make sure you understand how translation workflows and file locks are managed. I’ve seen a few cases where teams had to resort to branched repositories (something you want to avoid in single sourcing) or painful conditional text requirements to support their translation process.
Have requirements related to interoperability and workflow management
A CMS is about file management. A good CMS offers you ways to integrate with other systems (editors, publishing management, translation tools, other file management systems) and to build and support workflows. The publishing workflow is probably the most important one. You absolutely must see it in action before you buy. The review workflow is also key, especially if you will have non-technical reviewers and approvers involved. For non-technical reviews, ask if reviewers work in the system (and need licenses), or if reviews are done outside of the system.
Ease-of-use and troubleshooting are overlooked requirements
I’m sure you’ll have a checklist item that says “easy to use,” but it’s better to break that down into more specific requirements. If possible, complete a proof-of-concept session where members of your team create and manage a file using the editor, through to publishing. Find out how and when validation is done—in the editor, at file save, at file check-in? Are errors highlighted and corrections offered? Is there an XML and/or DITA reference built into the system?
Serviceability and support
Ask questions about the support hours and support channels (phone, online, IM). Multi-language support may also be important. Make sure you review the service agreement thoroughly and negotiate penalties that kick in if agreed support milestones are missed. Your CMS system should be considered a “critical” system—meaning full failover, backups, and as close to 100% uptime as you can get. The details of your system maintenance agreement are important too: how often do receive major or minor updates? Do you get any free “professional services” hours? Does the vendor move quickly on external updates, i.e., to be compliant with the next DITA OT release?
What does your gut say?
Aside from the system, it’s people. You have to be comfortable with the vendor. They can be (free) resources who help you to set up a system that best meets your needs.
About the Author:
Sherry McMenemy has been working in enterprise knowledge management and related roles for 14 years in Kitchener-Waterloo, ON, currently as Director, Knowledge Management & Technical Communications at Sandvine. She is a co-leader of the Community Management Communitech P2P and she has a background in usability, content management, internal communications and enterprise communities. Solving communication problems makes her giddy.