Orthodoxy versus nuance
Simple answers are appealing and are easy to remember. [Refrain from gratuitous political joke here, mostly.] But the real world is full of complex issues that are not easily reduced to soundbites. This also applies to technical communication and XML adoption.
Here, in a nutshell, is why we need content strategy:
[Person A:] “What made you want to choose DITA in the first place for your project? ”
[Person B:] “Everything I read about how DITA will facilitate single-sourcing, content reuse,
etc. I’ve used RoboHelp and Doc-to-Help in the past. I have no budget for purchasing
software.”
dita-users group, November 8, 2011
DITA (and for DITA you can substitute Any Tool in the World) is not a magic cure-all that will solve your technical communication problems, cook dinner, or do your laundry. It may be free, but it’s not cheap.
If you have zero budget for software purchases, I hope that you are extremely technical and have unlimited time. Because that is the software bargain: you spend money to save time. There are valid (!!) reasons to favor open-source software over commercial software, but you must recognize the tradeoff.
DITA discussions seem to devolve into two basic camps:
- “DITA is awesome and everyone should use it.”
- “DITA sucks and nobody should use it.”
The truth is much more complex. Here are some things to consider:
- DITA is XML. XML supports structured authoring, which is a fundamental shift away from desktop publishing.
- DITA implementation is a complex and usually expensive undertaking. If you don’t spend money, you’ll spend time.
- If you localize content, moving to XML or DITA can save you money.
- DITA provides support for reuse, which can save you money.
- The DITA Open Toolkit provides rudimentary output to PDF, HTML, and other formats. Getting production-ready output is a significant investment.
More facts:
- Not all organizations should implement DITA.
- Some organizations should use XML but not DITA.
- Some organizations should not use XML at all.
It is inexcusable to advocate DITA implementation without considering whether the organization has a business case for implementation. This business case may center around content management, reuse, localization, or other issues. It is equally inexcusable to dismiss DITA solutions outright.
If the business case for DITA is compelling, the next prerequisite is technical talent. This can come from employees or consultants. Organizations that do not have DITA expertise available to them should not implement DITA.
I am seeing a lot of frustration around the DITA Open Toolkit and how difficult it is to configure. Yes, the Open Toolkit is a challenge. However, this issue should be factored into the business case. If the challenges of the Open Toolkit come as a roadblock and a surprise during implementation, then somebody didn’t do their homework.
Your business case must be sufficiently compelling to overcome the implementation effort.
About the author
Michael Müller-Hillebrand
How true, oh so true!
Mark Baker
Bravo Sarah,
Very well said. Every tool is an implementation of a method, and every method optimizes for some property or properties at the expense of others. This is universal and unavoidable. You can’t optimize for everything.
Desktop publishing optimizes for the lone artisan model of work. The up sides are low tooling and setup costs and linear scaling — adding capacity is as simple as adding seats. But there are few economies of scale and little opportunity for automation or collaboration.
Structured writing methodologies make content processable, and therefore introduce opportunities for automation and realizing economies of scale. But they can have high tooling costs and other overheads.
There are different approaches to structures writing, and they optimize for different things. DITA optimizes for highly granular reuse, but at the cost of high content management overheads and complexity in other areas. Other models optimize for other things, and have different cost profiles. Which one is best for a particular application depends on what problem you are trying to solve.
As Alan Houser recently tweeted: “DITA wants to be Esperanto, but for most orgs, meeting unique business requirements trumps universal interoperability.”
DITA is the right solution for some organizations, and the wrong solution for others. Other structured writing approaches are right for some organizations, and desktop publishing remains the right solution for others.
What DITA did well was to take a particular model of structured writing and package it so that people could adopt it as a unit. Other models exist, and have long and successful histories in individual projects, but they have not been similarly packaged.
The problem today is that when people are sold on the virtues of XML, they don’t have the opportunity to examine different models and figure out which one best suits their business. (Docbook, it sees, is rarely considered.)
What we need today is the development of similar packaging of other models of structured writing — something I am working on. This will be good for DITA as well, because ultimately it is not good for DITA’s long term viability to have unsuccessful or inappropriate implementations.
Despite the desire of some DITA advocates to have DITA become the lingua franca of all corporate content, it is better for DITA if people only use DITA when it is genuinely the best solution for them.