DITA, The Sequel: Refining your DITA workflow
The initial wave of DITA implementations is still building, but we are already seeing the early adopters move on to what I am calling DITA, The Sequel.
Sometimes, sequels are great and other times…not so much (warning: You’re going to wish you hadn’t clicked on that link…some things, you can’t unsee). The DITA maturity model provides a way to classify DITA adoption strategies.
Our customers typically implement DITA in order to recognize cost savings in localization. Simply shipping XML to the localization vendor and having the ability to render translated content into the required deliverables presents a compelling business case.
Now, we have DITA, The Sequel. Organizations are adding to their implementation and increasing their return on the original investment with smaller follow-on projects. For example:
- An organization that has successfully implemented DITA/reuse/localization management recognizes that the process of creating deliverables takes a significant amount of time from authors. We work with them to create a flexible build automation system that eliminates many hours of tedious manual configuration. Because making updates to the output(s) is automated, the organization now delivers information that is updated weekly or nightly instead of monthly.
- Another DITA-based organization recognizes that the current output formats being delivered do not meet customer needs, so we work with them to create a new plug-in for the DITA Open Toolkit with a new format. (Popular formats are currently HTML compatible with mobile devices and ePub.) Because the new plug-in just, er, plugs in to the existing DITA architecture, the risk of adding a new output is minimal.
- In yet another organization, DITA authoring is limited to a small group of technical communicators. In the second wave, the authoring process is opened up to subject-matter experts, who contribute content directly in DITA instead of sending over Word files that require laborious reformatting and reworking.
- Another extension point is finding ways to inject additional content into the DITA ecosystem. Often, this involves creating transformations to get non-DITA XML into DITA.
Organizations are moving beyond their initial DITA implementations into more powerful, more flexible systems. I’m looking forward to what we might see in DITA 3: The Rise of the DITA Machines.
Julio Vazquez (@juliov27612)
Nice.
Have you started integrating video into DITA? This area can help get complex topics or break down complex task steps into a show-me so I can do model if done correctly.
While it hasn’t gotten as much traction yet, I see this as an area of expansion that Sean Healy (http://www.wildbasinmedia.com) pioneered and has some great ideas about. The only inhibitor is video production itself, which is not for the faint-of-heart right now. However, as quality video creation becomes easier, I see more of it being built into content for delivery in any output format, especially with the rise of tablets and smartphones.
It’s not DITA that will drive the evolution as much as the consumers will… and DITA will be there to push content out to all.
Michael Müller-Hillebrand
Sarah, Thanks a lot. It is my impression that everything but the mentioning of the »DITA machine« is also applicable to all XML-based processes, if they are DITA, DITA-based or custom-XML. It is my impression that »DITA« just helps in discussion with the users to not change the DTD every other month…
Sarah O'Keefe
@Julio: I like the video idea in theory. In practice, our customers seem to be more interested in cost reduction than in better instructions. At least for now.
@Michael: Yes, I think this is equally applicable to XML in general, with the possible exception of the handy plug-in architecture provided by the DITA Open Toolkit (and perhaps DocBook stylesheets). That said, we’ve had to build some output that was pretty far removed from any DITA OT defaults.
Don Day
I smiled at your mention of The Rise of the DITA Machines! One of the not-deeply-explored uses of DITA is for describing content that can drive processes. In effect, the Syntax Diagram component of the programming domain is a mini Domain Specific Language, or DSL (I’ve got a dormant post about this topic). The DITA Open Toolkit currently only renders a human-readable form, but since it is inherently a BNF representation of an API, it can be used to generate test case syntax combinations for testing the software. Recipe specializations, taken a step further, could be loaded into a culinary robot for producing “the perfect chocolate chip cookies for SMEs.” (Please ignore the sounds of screaming in my basement; my test subjects don’t like ingesting angle brackets–yet.)
Sandra Durham
Would love to hear more about the flexible build automation. Our final deliverables don’t take hours of author-time to update, but we sure aren’t at a point where we can automate the updates so some script/process fires off every Friday night, for example, to update the website with the latest approved content…
Sarah O'Keefe
@Don: eeek. I guess the basement reference is in revenge for the Retinal Deathwish link above.
@Sandra: It’s possible to integrate an Ant-driven process into various build processes. The specifics really depend on the organization, but the general concept is to have a task list of deliverables to be built and then have the Ant scripts set up to build them and push to the appropriate web servers. Most companies do this on internal web sites; they don’t trust the tech enough to push to public sites. Yet. 🙂