Skip to main content
May 4, 2011

The devolution of DITA editors

Most of the DITA work that we do at Scriptorium is “full-on” implementation. That is, our customer decides to move their content from [something that is not DITA] to a DITA-based system. There are variations on the theme, of course, but nearly all of our customers are concerned about managing localization costs and increasing content reuse.
Perhaps this is why I find the recent flurry of “limited DITA” editors so puzzling. Companies are producing DITA editors that are marketed as easy-to-use, “Word-like” or even embedded inside Word, and generally less challenging to use than a dedicated XML editor.

The trade-off is that these editors do not support all of the DITA tagset or architecture. For example, I recently saw an announcement for Codex and downloaded it to take a look. Codex is an AIR application, so that’s fun.

Codex provides the basics. Only topics, no codeblocks or conrefs.

In the first 30 seconds, I noticed the following:

  • Codex lets you create generic topics. You cannot create task, reference, or concept topics.
  • I don’t think you can create codeblock elements, tables, or conrefs.

In short, although what you can create is technically valid DITA, it’s an extremely limited subset of DITA. Let’s call it babyDITA.

Here’s my question: Is there actually a use case and a potential customer base for editors that create babyDITA? If you’re going to restrict the supported elements to this level, why not just let your contributors author in (X)HTML and convert it to DITA later?

Meanwhile, there is also the category of “Word-based” DITA editors. (I’ll try to set aside my aversion to Word long enough to consider this approach.) These editors, such as Quark XML Author and Simply XML, are marketed as software that “lets anyone easily create XML in Word with no knowledge of XML and little or no training” (Quark) or “without worrying about mark up or learning complex new software.” (SimplyXML) These companies are trying to use Word as a sort of Trojan horse for XML—the authors get to keep authoring in Word, but now they’re creating DITA (or other XML) in their favorite (?) word processor.

I think there’s a market in there somewhere, but I don’t think it’s as big as these companies think. Implicit in the “keep authoring in Word” argument is that putting authors in a different tool is too hard or too expensive. It’s true that XML editors are more difficult to use, but this is only in part the fault of the tools and their relative lack of maturity. The second problem is that creating properly organized, high-value content is much harder than putting crap on a page. Word definitely encourages the latter. So even moving up from creating typical Word documents into Word-based DITA is going to be a huge leap. If you don’t understand the underlying DITA structure, you’re just going to continue to create badly structured information that is technically valid.

Getting from business documents to DITA is a huge leap

If your organization needs high-value content—information that is useful, accurate, and reusable—you will need to invest in the appropriate tools, technologies, and process. If you don’t need high-value content, you should continue doing whatever you are currently doing and ignore DITA and its brethren.

Finally, I think that the “Word-based” editor people are solving the wrong problem. The future is in the cloud with web-based editors, and you might want to take a look at two interesting products there: XOpus and easyDITA.

What are your thoughts on babyDITA editors? Do you see a need for them?