2009-01-23-where-i-stand-on-dita.html

---
layout: post
title: Where I Stand on DITA
date: 2009-01-23 23:28:02.000000000 -08:00
categories:
- wordpress
tags:
- author-it
- authoring
- codex
- dita
- doc-to-help
- docbook
- Flare
- latest trends
- Notes
- XML
status: publish

published: true
---

{% include toc.html %}

<p><figure><a href="https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/2009/01/dita_finch.jpg"><img class="alignright" title="DITA" src="https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/dita_finch1.jpg" alt="DITA" width="264" height="120" /></a><figcaption></figcaption>DITA (Darwin Information Typing Architecture) is an XML standard in technical communication</figure></p>
<p>For a blog about the latest trends in technical communication, I've been conspicuously silent about <a href="http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture">DITA</a>, the XML standard for technical documentation that is rapidly becoming the norm in the industry. Tonight I realized that I need to examine more closely where I stand on DITA. Several events prompted this.</p>
<p>At my work we have a small authoring group that is tool independent. I use Flare, another colleague uses RoboHelp, another colleague has no need for a robust help authoring tool, another department uses UPK (Oracle's help authoring tool), and we don't really have a unified approach. Adobe just released its new Technical Communication Suite that includes the latest version of a package of tools. Flare continues to move forward, as does Author-it and Doc-to-Help. But I'm feeling a bit fatigued by these proprietary tools. Rather than choosing another tool, I would rather choose a standard format and let individuals choose their own tools to create documentation in that format.</p>
<p>The WordPress Docs mailing has also been heating up. Apparently WordPress has come to the realization that its <a href="http://codex.wordpress.org">Codex</a>, a giant wiki that would kill all trees in the world if printed, does not satisfy the beginner's need for a basic "handbook."</p>
<p>WordPress' wiki has been, in my opinion, a fascinating project of community documentation. From what I understand, a previous wiki held WordPress documentation but was abandoned to create the Codex. Now the developers are considering transfering the core information from the Codex to a DocBook format, which they would maintain in a Subversion repository (SVN) so they can manage quality control and branching. If you want to see in to the heart of Web 2.0 and documentation, look closely at WordPress.  The Codex has grown beyond itself, become chaotic, redundant, outdated in parts, maze-like and unnavigable. Still, nuggets of essential information are spread throughout, making it indispensable. Maintained almost entirely by volunteers, the wiki proves to be a problematic format. It can't sustain long-term, massive amounts of information before people feel the need to start fresh again.</p>
{% include ads.html %}
<p>According to the WordPress leaders, the wiki's main problem is its inability to support branching. You can't easily separate documentation for version 2.2 from 2.3 to 2.4, 2.5, 2.6, and 2.7. On the wiki, it's all the same page.</p>
<p>Fed largely by user-generated content, wikis will inevitably contain stale information. For example, the <a href="http://codex.wordpress.org/WordPress_Quick_Start_Guide">long page I contributed</a> to the WordPress Codex remains dated to version 2.5 or so, whenever I wrote it. (I'm not inspired to update it.) There's no ability to impose quality control, to have a systemic way of sorting and verifying and organizing updates, changes, and other modifications.</p>
<p>Most importantly, though, the wiki doesn't support flexibility of deliverables. There's one product, one massive mountain of information. Each user has to make his or her own path through it. In all the documentation I've delivered, the long manual -- the massive wad of information -- has always been met with disgruntled looks and resistance. Users want condensed, short chunks of information specific to their role and situation. They want information without inundation. This brings me to DITA.</p>
<p>DITA provides the ability to chunk information, to deliver selected topics in a variety of compilations and output to various formats. It allows the passing back and forth of this content among authors regardless of tools.</p>
<p>My hesitation with DITA has only been that it's too early to adopt. But I believe the turning point has come. There are, now, enough plugins, transforms, authoring editors, and other supporting technologies that writers can begin to use DITA successfully, without setting themselves too far back.</p>
<p>DITA has even made headway into WordPress. <a href="http://zed1.com/">Mike Little</a> says he has built "an importer which will take the XHTML generated by DITA and import it into WordPress as a<br />
hierarchical set of pages." He  "even have a version for WPMU [WordPress Multi-User Edition] that supports populating each mu blog with separate areas of content."</p>
<p>I've kept my eye on DITA for the past two years, but I think it's finally time, at least for me, to look more seriously into adopting and implementing it.</p>