Driving Miss DITA
Over on the Adobe Technical Communication blog, Aseem Dokania compares DITA to transportation infrastructure:
Over on the Adobe Technical Communication blog, Aseem Dokania compares DITA to transportation infrastructure:
From Jon Bosak’s closing keynote at XML 2006:
Another ancient subject that seems to be popping up again is the idea of modular document creation. This is one of those concepts that comes through about once a decade, seduces all the writing managers with the prospect of greater efficiency, takes over entire writing departments for a couple of years, and then falls out of favor as people finally realize that document reuse is not a solvable problem in document delivery but rather an intractable problem in document writing — which is, how to retain any sense of logical connection between pieces of information while writing as if your target audience consisted entirely of people afflicted with ADD.
I don’t think I agree completely, but he does have a point.
I could go on at length about this, but instead I’ll simply leave you with the observation that my personal love affair with modular documentation occurred in 1978 and that I haven’t seen a thing since then that would change the conclusions I reached about it almost thirty years ago. This is not to say that I’m trying to discourage the technical writing community whence I came from their enthusiasm for the modular authoring technology du jour, since engagement in such efforts is virtually guaranteed to buy tech writers a few years in which they can act like software engineers and present themselves as engaged in cutting-edge informational technology development rather than plain old technical writing. That strategy has worked great for some of us.
I think perhaps the arguments for and against single-source publishing are a better place to look. There is a school of thought that argues that single sourcing results in inferior deliverables, both in print and online. But the cost savings from single sourcing are so compelling that nobody really argues for hand-crafting printed and online materials separately any more. (Based on my experience, I think that the quality difference between material that is single sourced (well) and material that is hand-crafted (well) is quite small; perhaps around 10 percent. But that last ten percent is extremely expensive.)
With XML/DITA/modular documentation, there is a similar cost argument. Document reuse and especially localization workflows benefit from modular documentation. For localization teams, getting content in topics rather than monolithic books can result in incremental localization and thus the ability to “sim-ship”; to ship the product in the source language and target languages simultaneously. This, in turn, means a global product launch and a shorter wait for revenue from the markets for which localization is required.
Thus, requirement to accelerate product deliverables and save money on localization (because of more efficient reuse) are going to drive implementation of modular documentation. The argument that non-modular documentation is better documentation will become irrelevant.
I’ve just posted a new white paper to our store.
Assessing DITA as a foundation for XML implementation
Like our other papers, it’s free. We do ask you to register to get the material.
I look forward to your comments.
Via Cafe con Leche (Elliotte Rusty Harold), the first public working draft of Best Practices for XML Internationalization has been released by the W3C Internalization Tag Set Working Group.
In a recent discussion on the STCCIC-SIG list, Mark Baker of Analecta Communications provided an excellent analysis of DocBook, DITA, and how they are not the same thing as XML. (The discussion is reproduced here with Mark’s permission.)
I have a pattern of learning things The Hard Way. That is, get a book, dive in, and just do it. Eventually, some order emerges from the chaos, and one day, it all starts to make sense. This approach has failed once or twice — my ill-fated attempts to learn Perl come to mind.
socaltech.com has an interview with Mike Hamilton, formerly of Macromedia/eHelp/Blue Sky, now with MadCap Software.