Tools
HATs Off to CMSes?
by Neil Perlin
Does your company’s documentation group create online help for its software products? Online manuals for field service or tech support? If so, then the group probably uses one of the well-known help authoring tools (HATs) like Adobe RoboHelp, MadCap Flare, or Component One Doc-To-Help.
This type of tool has been with us since 1991. Since then, they’ve gone from being seen as new and exotic to seen as a familiar part of a technical writer’s toolkit. They offer numerous features, let writers convert almost any type of information from hard-copy to online, are inexpensive ($800 - $1,000 per seat), and easy to learn (three days of formal training is enough to get new writers going).
That’s nice… So where am I going?
We often hear about silos in IT. Consider the case of CMSes versus HATs, two different and unrelated technologies, right? Not necessarily…
Issues with CMSes
As HATs have become a familiar part of online documentation work, buzz has moved to CMSes. CMSes are cutting-edge. They support XML, DITA, multi-author development, single sourcing multi-channel publishing, and more cool things, and are being pushed hard at documentation groups. But CMSes also have some serious drawbacks for many documentation groups.
Expensive: Different studies and articles come up with very different costs for purchase, implementation, training, and maintenance, but they’re all at least one order of magnitude greater than a HAT. This can be a major issue for documentation groups that have to sweat bullets to get the budget for a few copies of a $1,000 HAT and now have to ask for $100,000 for a new tool to let them do basically the same tasks.
Technically demanding: Using a CMS can call for more technical knowledge than 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. (Although without at least a basic understanding of what they’re doing — “What is a CSS, anyway, and why do we need one?” — it’s easy for writers to make some really colossal mistakes.) CMSes can certainly 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 need to understand.
Workflow changes: Adopting a CMS can change workflows or formalize once informal processes, like reviews. People can have trouble dealing with change, and documentation has been swamped in recent years by the shift to HTML, then XML, DITA, structured authoring, single sourcing, multi-channel publishing, and “now what…?”.
Cultural misfit: CMS operations may clash with the culture of a documentation group or the larger company. It will take time for MS 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 fast will cause problems in companies with a history of telling writers to “just figure it out…”
These problems, and more, mean that implementing a CMS may be far harder than many documentation groups anticipate. 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 due to technical, workflow, or cultural problems.
Where do HATs fit in here?
Despite the name, HATs long ago moved past their help authoring roots. They’ve always offered content editing, the ability to import files created in Word and Framemaker, to customize content through conditionality, version control, and various output options ranging from Microsoft Windows Help to Microsoft HTML Help, JavaHelp, WebHelp, and more.
New versions of the tools offer or are heading toward CMS-style features:
- repositories
- review control
- content customization through variables (and variables that can call and nest other variables)
- centralization of project control files
- SWF integration
- etc.
These feature similarities between HATs and CMSes offer two benefits for documentation groups considering migrating to a CMS.
CMS simulation: A documentation group that uses a HAT can use it to create simulated, test-bed CMSes. This lets the group identify and correct gaps in writers’ technical skills, workflow problems, or cultural-fit problems before spending time and a lot of money on a “real” CMS.
CMS substitute: A documentation group might be able to use its HAT as a lightweight but real CMS.
The results? Creating a test-bed CMS will help documentation groups move to a CMS with open eyes. Using a HAT as a real CMS will help documentation groups stay in a familiar environment, but make better use of it, while minimizing cost and disruption.
If you’re using a HAT now, don’t give up on it until you find out what it can really do. You may be surprised.
***************
This article originally appeared in SD Times on 2 December 2008. is president of Hyper/Word Services (www.hyperword.com) of Tewksbury, MA. He has 30 years experience in technical communication, with 24 years in training, consulting, and development for online formats and tools like WinHelp, HTML Help, JavaHelp, CE Help, RoboHelp, Flare, Mimic, Captivate, and others now known only in legend. Neil is a member of IEEE and STC, an associate fellow of the STC, and the founder and manager of the Beyond the Bleeding Edge stem that ran at the STC annual conference from 1999 to 2006.