Guest View: HATs off to content management

December 1, 2008 —  (Page 1 of 2)
Do software documentation groups really need a content management system (CMS), or is there a simpler, cheaper, better alternative?

Does your company’s documentation group create online help for its software products, or online manuals for field service or tech support? If so, then the group probably uses one of the well-known help-authoring tools (HAT), such as Adobe RoboHelp, MadCap Flare or ComponentOne Doc-To-Help.

Such tools have been with us since 1991 and are now a familiar part of a technical writer’s toolkit. They let writers convert almost any type of information from hard copy to online; are inexpensive, averaging US$800 to $1,000 per seat; and are easy to learn, with three days of formal training generally sufficient to get new writers going.

By now, you’re likely thinking, “That’s nice, but where’s he going with this?”

We often hear about silos in IT. Consider the case of CMSes vs. HATs—two different and unrelated technologies, right? Not necessarily.

As HATs have become a familiar part of online documentation work, the buzz has moved to CMSes. CMSes are cutting-edge. They support XML, the Darwin Information Typing Architecture (DITA), multi-author development and single-sourcing, multichannel publishing, among other cool things. They are being pushed hard at documentation groups. But for many such groups, CMSes have serious drawbacks:
  • They are expensive. Different studies and articles come up with very different costs for purchase, implementation, training and maintenance, but they all estimate that a CMS costs considerably more than a HAT. For documentation groups that had to sweat bullets just to get the budget for a few copies of a $1,000 HAT, requesting $10,000 or $100,000 for a CMS tool that supports basically the same tasks can be a deal breaker.

  • They are technically demanding. Using a CMS can call for more technical knowledge than is required for other documentation tools. Writers don’t need to understand HTML or XML to create hard-copy documentation in Word or online help in a HAT. CMSes can be set up to spare the writers from seeing most of the technical details, but there will still be some new and unfamiliar features and concepts that they will need to understand.

  • Adopting a CMS can alter workflows or formalize once informal processes, such as reviews. People can have trouble dealing with change, and documentation has already been swamped in recent years by the shifts to HTML, XML, DITA, structured authoring and multichannel publishing. Cries of “Now what?” might accompany CMS adoption in some groups.

  • CMS operations may clash with the culture of a documentation group or the larger company. It will take time for Word shops or groups that are just going online to adapt to the new environment. The need for authoring standards will cause problems if writers resist being “boxed in.” The need for training to get writers up to speed might be problematic for organizations with a history of telling writers to “just figure it out.”
Such hurdles mean that implementing a CMS may be far harder than many documentation groups expect. On several occasions, I’ve talked to clients who spent almost $150,000 on a CMS, only to see it become “shelfware” in the CTO’s office because of technical, workflow or cultural problems.

Related Search Term(s): content management, documentation

Pages 1 2 

Share this link:

Preflight builds spread wings for smoother projects
Developers are increasingly turning to preflight builds, allowing them to experiment with code before moving on to the full production build cycle. Electric Cloud and Urbancode already use them in their build management products Read More...

News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>



Download Current Issue

Need Back Issues?

Want to subscribe?