Guest View: HATs off to content management

By Neil Perlin

December 1, 2008 —

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.

So where do HATs fit in? Despite the name, HATs long ago moved past their help-authoring roots. They have always offered content editing; the ability to import files created in Word or FrameMaker; customization of content through conditionality; version control; and various output options, ranging from Microsoft Windows Help to JavaHelp, Microsoft HTML Help, WebHelp and other formats. New versions of the tools offer or are heading toward CMS-style features, such as repositories, review control, content customization through variables (including ones that can call and nest other variables), centralization of project control files and integration of data files.

The similarities between HATs and CMSes open up two options for groups considering migration to a CMS:

CMS simulation. A documentation group that uses a HAT can deploy it to create testbed CMSes. The group can identify and correct gaps in writers’ technical skills, workflow problems or cultural problems before spending time and money on a “real” CMS.

CMS substitution. A group might be able to use its HAT as a lightweight, but real, CMS, staying in a familiar environment but making better use of it.

Don’t toss your HAT until you find out what it really can do.

Neil Perlin is the founder of Hyper/Word Services, which provides training, consulting and development services for help-authoring tools.

Related Search Term(s): content management, documentation

Share this link: http://www.sdtimes.com/link/33078

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.

Guest View: Lowdown on virtualization hype Everybody loves virtualization nowadays, but a lot of the supposed benefits of virtualization come from misunderstandings as to what it can do. Don MacVittie lays out the limitations to the technology.

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST