Neil Perlin, Hyper/Word Services
In October 2008, MadCap Software announced that Flare 5, which would appear in 2009, would add support for DITA. Soon after, Adobe announced that the upcoming RoboHelp 8 would also support DITA. The DITA features in these two tools, two well-known HATs, or help authoring tools, so far pale next to those in “real” DITA authoring tools. However, in my opinion, these features represent a big strategic shift in the DITA space. That shift is the subject of this article/opinion piece.
Before I go on, three postulates:
- Structured content is good. The consistency of structured content helps readers develop and maintain a mental model of that content in and across documents. That consistency also helps technical communicators write efficiently by providing a consistent structure within which they can write, rather than having to decide how to structure each new piece of content.
- We can create structured content in various ways—DITA, structured Frame, and a mix of templates and style sheets.
- DITA has significant advantages over the other two approaches in the previous point:
- Vendor- and tool-independence, unlike structured Framemaker.
- Programmatic enforcement of document structure, unlike the template-and-style-sheet approach
So DITA should be widely used in technical communication to produce structured content in topic form for single sourcing/multi-channel publishing. But it isn’t. My experience with companies in high- and low-tech is that most avoid DITA. (The 2009 WritersUA Skills and Technologies Survey (www.writersua.com/surveys/skillstech09/skillstech_skills.htm) found that only 17% of technical communicators used DITA, up from 14% in 2008.) Why the resistance?
I’ve heard many reasons for not using DITA, but the relevant ones for this article are:
- Need to buy new tools. This concern includes the costs of buying the tool, plus getting trained to use it (or the hidden cost of not getting trained), and lower productivity while ramping up on the new tool.
- Free tools aren’t. Freeware DITA tools based on the DITA open toolkit are free, but they are more technically demanding than GUI tools so tasks can take longer and have more risk of errors. You may also need several freeware tools to do what an integrated, GUI tool will do, which takes longer and raises the risk of errors. Finally, if you ever need to hire contractors, there are fewer who can work at the code or technical level than there are who can use GUI tools, so they’re more expensive.
- It’s not just a tool issue. Creating DITA content requires changing how you structure and write content and how you think about structuring and writing that content—to move from a document orientation to a topic orientation.
- No web-oriented output. DITA tools offer many outputs, such as Eclipse Help, JavaHelp, HTML Help, and PDF, but don’t offer a web-oriented output like the WebHelp offered by help authoring tools. (This may have changed by the time this article appears.) Several vendors noted that the absence is due to the costs of providing such an output. They noted that the outputs offered by the DITA tools are mainly pre-defined by other companies, like HTML Help from Microsoft or JavaHelp from Sun. This makes it easy for the DITA tool vendors to offer these outputs. Creating a “WebHelp” output would be harder because each DITA tool vendor would have to create its own. A web-oriented output would also have to be tested on each new release of each supported browser, also an expensive proposition.
- Hard to justify if you’re not translating. If you create material destined to be translated, it seems to be fairly easy to derive concrete data needed to determine whether DITA is cost-justifiable. But if you’re not translating, cost-justification seems to be a lot harder.
So DITA offers some major benefits, but also has some problems significant enough to deter its adoption. How might HAT support for DITA affect this situation?
Impact of Help Authoring Tools’ Support for DITA
As I write this column, in early February, I know of two HAT vendors whose tools support DITA—MadCap and Adobe. Other HAT vendors may have followed by the time this article appears, so what follows are observations on HAT support for DITA in general.
If your HAT offers DITA support:
- You may not have to buy a new tool but can keep using your regular HAT, eliminating the cost of buying a new tool and the cost of lost productivity during ramp-up. (This assumes that the HAT-generated material meets DITA standards. If it doesn’t, you may be able to use the HAT to generate web-oriented help by creating DITA content in a regular DITA authoring tool, then importing it into the HAT for output to the web-oriented format.)
- You eliminate the complexity of using more technically demanding tools or multiple tools. There will also be more contractors available since you’d be looking for a contractor who knows how to use the HAT.
The previous two points make it easier to cost-justify a move to DITA just because you’re not spending as much money.
- You still need to switch your orientation from document to topic, but not having to learn a new tool at the same time reduces your cognitive burden.
- You’ll be able to output your material in a web-oriented format.
So how might these factors affect DITA? Two possibilities:
- DITA use rises because it’s easier to cost-justify and create content. DITA becomes just one more format created by an authoring tool that you already have and know.
- DITA use falls because it’s easier for rueful adopters to back out. Companies that moved to DITA early on, only to regret the decision, haven’t had an easy way out. Being able to import DITA content into a HAT and save it as XHTML provides that way out.
It’s hard to say which possibility is most likely, but I vote for the first. Structured content is useful, and DITA is a well-known standard for creating such content. By lowering the barriers to trying DITA and making it easier to back out, I predict that the HAT support will make people more open to trying DITA in the first place. If you currently use Flare or RoboHelp but are considering using DITA and having to move to another tool, talk to your HAT vendor first. It might make DITA more convenient than you expect.
About the Author
Neil Perlin is president of Hyper/Word Services (www.hyperword.com) of Tewksbury, MA. He has 31 years experience in technical writing, with 25 in training, consulting, and developing for online formats including WinHelp, HTML Help, JavaHelp, CE Help, RoboHelp, Flare, and some now known only in legend. Neil is a Fellow of the Society for Technical Communication. You can reach him at firstname.lastname@example.org.