After recently reading DITA 101 by Anne Rockley, Steve Manning, and Charles Cooper, I’ve been wondering how DITA fits with other approaches to creating structured information, what roadblocks there are to its adoption, and how well the tools I’m already familiar with support it.

Awhile ago, I tucked aside Neil Perlin’s March 2009 Intercom article, “Pulling DITA Out of Your Hat,” and in the almost year that’s passed, his article still helps clarify DITA, in this wider context.

{Neil Perlin, available at nperlin@concentric.net, is president of Hyper/Word Services of Tewksbury, MA.  He has 30 years’ experience in technical writing, with 24 in training, consulting, and developing for online formats. He is a member of the Boston STC Chapter and founded and managed the Beyond the Bleeding Edge stem, at the STC annual conference.}

The following notes capture some of Perlin’s key points.

Structured Information Is Good

Perlin describes the benefits of structured information.

Structured information helps readers because it’s easier for them to get and keep a mental picture of the information in a document when that information is written consistently. Structured information also helps technical communicators, because it’s easier to write chunks of information when there’s a consistent structure to use rather than having to decide, or remember, what structure to use with each new chunk  (p. 41).

Ways to Create Structured Information

Perlin explains that there are many ways to create structured information. Three of these methods are as follow:

• Using DITA
• Using Structured FrameMaker
• Using a Mix of Templates and Style Sheets

According to Perlin, “DITA has significant advantages over the other two approaches because it’s vendor- and -tool-independent, unlike Structured FrameMaker, and it programmatically enforces document structure, unlike the templates-and-style-sheets approach” (p. 41).

Obstacles to Adopting DITA

So, why isn’t DITA more widely adopted to produce topic-based, structured content for single sourcing and multichannel publishing? According to Perlin, here are the most often-cited reasons:

• The need to buy a new tool, with associated training costs and lower productivity during ramp-up.
• “The DITA open source toolkit is free, but it’s more technically demanding than a GUI-style tool, so tasks can take longer and have a greater risk of errors.”
• Moving to DITA isn’t just a tools issue. It requires moving from a document orientation to a topic orientation.
• “DITA tools offer many outputs (PDF, Eclipse Help, HTML Help, and JavaHelp) but don’t seem to offer a web-oriented output like WebHelp, offered by help authoring tools.”
• If you are not translating, it’s difficult “to derive the concrete data needed to test whether adopting DITA is cost-justifiable.”
  (p. 41).

Help Authoring Tool Support for DITA

With both Adobe and MadCap coming on board, Perlin predicts that help authoring tool support for DITA presents two possibilities:

• “They increase use of DITA by making it easier to cost justify and to create the content. DITA simply becomes one more output created by an authoring tool that you already have and know” (p. 42).
• “They decrease the use of DITA by making it easy for rueful early adopters to back out. Companies that moved to DITA early on only to regret the decision have not had an easy way out. Being able to import DITA content into a help authoring tool and convert it to some other format provides that way out” (p. 42).

Likely Increased DITA Adoption

In Perlin’s opinion, the “first possibility is the most likely” (p. 42).

Structured documentation is useful, and DITA is the most widely known standard for creating structured documentation. By lowering the barriers to entering DITA and making it easier to back out, I expect that the help authoring tools’ support for DITA will spread its use (p. 42).

If you are considering switching to DITA and moving to another tool to do so, Perlin advises talking to your help authoring tool vendor first. Moving to DITA might be easier than you think.

Your Take?

Have you used your help authoring tool to create DITA output? or to back out of DITA? Do you recommend any of the other approaches to structured information? What about using Structured FrameMaker? In the comments, I welcome any comparisons between these approaches, especially from those in the trenches.

Update: In a free webcast yesterday (1/19) on Madcap Flare, Version 5’s support for DITA, Sarah O’Keefe of Scriptorium Publishing recommended using Flare, Version 5 to import DITA content (authored somewhere else, such as in Structured FrameMaker, XMetal, or  oXygen) into a Flare project. This is an important feature because the  DITA Open Toolkit does not provide WebHelp output. Once you import DITA content into Flare, you can generate your WebHelp output. In the same webcast, O’Keefe’s demo showed that exporting Flare content as DITA output does not at this time seem as viable, due to mapping issues. 

About This Blog: Copyright Information

Contacting the Author: Content for a Convergent World – Peg Mulligan’s Blog