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.
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?
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.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include technical writing, authoring and publishing tools, API documentation, tech comm trends, visual communication, technical writing career advice, information architecture and findability, developer documentation, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here.