DITA – Bright Promise. Bumpy Ride.

© Ugur Akinci
DITA (Darwin Information Typing Architecture) is an XML-based structured authoring platform that I’ve been studying for the last couple of years. Sarah O’Keefe and her colleagues at Scriptorium Publishing Services have been a reliable source in my struggle to understand the landscape of this “brave new frontier” looming over our technical communication horizon.
The thing I like about O’Keefe’s approach is that, although she’s a highly regarded DITA consultant and her livelihood obviously depends on more corporations adopting DITA, she tells it as it is, with warts and all. Her books and presentations are balanced and honest. She takes care to present “both sides of the story” and does not give the impression that she’s holding something back. That’s why I regard her information very reliable indeed.
Today I took part in another one of her informative web presentations; this one was about “Extracting deliverables from DITA.” Again, as someone with an extensive background in unstructured authoring and print design, I could not help but reflect on the difficulties that lay ahead on the path to DITA glory. For most of us, the ride may prove to be a little bit more bumpy than expected.
First, I have to admit that DITA represents a bright promise since it offers a comprehensive way to divorce form from content, which makes single-sourcing and topic-based collaborative authoring not only possible but profitable as well. Yes, the transition to an XML-based approach will not be cheap or easy but perhaps it’s a matter of deciding whether to pay up now or later, as O’Keefe reminded us during her presentation. That’s certainly a fair way of looking at the whole enterprise from a corporate angle.
But then, there is that dreaded D-word: “difficulty.” Even in an issue as seemingly straight forward as generating an HTML or PDF copy from a DITA document, you need to jump through quite a few hoops.
One problem that won’t go away is our already-established expectations. We are so used to excellent looking print and web documents of all kinds, anything less than that will disappoint us (unless we decide to lower our standards). And generating a good looking document from DITA by using XSL style tools is not an easy thing at all.
Yes, there are powerful page-layout tools like Adobe InDesign and Adobe FrameMaker that come with built-in XML functionalities but still such things as “white spaces” need a lot of configuring and tweaking to yield acceptable results.
DITA Open Tool Kit (OTK) is of course available freely and is good at automating document structuring tasks but it’s not good at achieving good typographical effects. It’s like we are forced to make a choice between documents that look good (when InDesign is used) and those that are generated with a high degree of automation (when DITA OTK is used). FrameMaker provides a mid-point solution, O’Keefe reminded us.
The process of generating PDF deliverables from DTA code is further complicated by such factors as the need for and scope of localization (translation), or the kind and number of platforms on which the document needs to be presented, etc. The list of other factors that can complicate the DITA-deliverables effort is a sizable one.
Overall, I have two conclusions:
1) At the individual level, this is a career niche that needs considerable care and forethought since it’ll require considerable resources to become good at.
As O’Keefe noted frankly during the Q&A session, it is not sufficient just to be a good computer programmer in order to dive under the hood and configure a DITA system properly at the code level. On top of that, you also need to be a good graphic designer – a rare combination indeed.
So if you’re thinking “should I specialize in DITA as the next move in my technical communication career,” I’d say keep thinking a little more while reading everything you can on the topic.
2) On a corporate level, transitioning to DITA will require a lot of management buy in. The management team will need to arrive at a very clear cut cost-benefit analysis before mobilizing corporate resources and investing in the kind of change to structured authoring (whether on a DITA or another platform) that would justify the expense. At that point the services of experienced consultants like O’Keefe may of course prove to be very valuable indeed.

Resources

The recording of the webcast on Extracting deliverables from DITA:
http://www.scriptorium.com/blog/2010/08/extracting-deliverables-from-dita.html

Scriptorium white paper on creating PDF from DITA:
http://www.scriptorium.com/whitepapers/dita2pdf/index.html
 

To read further:

THE COMPASS: Essential Reading About XML, DITA, and Web 2.0
http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
(Public-domain photo courtesy of Wikipedia.)

2 Comments

  1. Larry Kunz on August 17, 2010 at 9:47 pm

    Good analysis, Ugur. Your writing is consistent with Sarah’s presentation style: balanced and honest. I disagree a bit with your first conclusion, though, because you seem to imply that all technical writers who work in DITA will need to know programming and design. In fact, the great majority of writers working in DITA won’t need those skills: they’ll focus on creating content while no longer having to worry about format. The programming/design skills are required only for the relatively small number who work at transforming XML-tagged content into formatted output.



    • admin on August 20, 2010 at 8:08 am

      Larry, you have a point but to me it looks like the real “high value-added” portion of this process is still in formatting. We have successfully divorced form from content and now we’re struggling to put the form back in again and make it as good as unstructured documents. Given the admitted difficulties of that in 2010, it’ll be a few years before DITA authoring takes hold.