Why developers will never adopt DITA
Ever wonder why developers resist DITA so much? Take a look at this comparison. Here are two ways to describe a simple task of printing a page.
DITA syntax
<task id="task_mhs_zjk_pp">
<title>Printing a page</title>
<taskbody>
<steps>
<stepsection>To print a page:</stepsection>
<step>
<cmd>Go to <menucascade>
<uicontrol>File</uicontrol><uicontrol>Print</uicontrol>
</menucascade></cmd>
</step>
<step>
<cmd>Click the <uicontrol>Print</uicontrol> button.</cmd>
</step>
</steps>
</taskbody>
</task>Markdown syntax
## Print a page
1. Go to **File > Print**.
2. Click the **Print** button.Conclusion
Granted, I'm simplifying things a bit. DITA allows you to re-use text, apply attributes, and process your content into more than just HTML.
But if you're just publishing to the web, and you don't have a lot of complex re-use requirements, isn't it just extra work adding all of these DITA tags?
What it means for tools
A lot of vendor energy has been spent in simplifying DITA. For example, there are ways to create DITA using interfaces that look just like Microsoft Word. However, simplifying DITA through easier authoring interfaces isn't really the problem. The problem is that developers build tools that accommodate simple authoring models. Nearly every developer tool for API documentation, such as Slate, API Blueprint, Doxygen, Nanoc, Github, and Docco all use Markdown instead of HTML or XML for authoring.
I don't foresee developers going out of their way to accommodate DITA processing in the API doc tools they build. Instead, DITA will most likely need to provide transforms that allow content to be pushed into these API toolsets. That may mean creating a DITA-to-Markdown transform, which isn't something any XML professional is going to want to do given that Markdown would remove much of the complexity and power in publishing.
The divide between tech comm tools and API doc tools will continue to be difficult to bridge.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.