What are DITA‘s biggest benefits? Its greatest challenges?
The Content Wrangler is surveying DITA users, and last week Scott Abel — joined by DITA cognoscenti Rob Hanna,Mark Lewis, and Keith Schengili-Roberts — presented some preliminary results.
I’ve listed the rankings here, along with some thoughts of my own. Each numbered item is from Scott’s presentation; the commentary between the numbered items is mine.
(The survey is still accepting responses. If you haven’t yet weighed in, you can do so right now.)
What benefits does DITA provide?
This section was open to all respondents.
1, Consistency: content reuse/single-sourcing
Yes: when I think of single-sourcing, I think of consistency. But I also think about flexibility — of being able to publish the same content on the web, as integrated help, as PDF, and in other formats. For me that’s a big benefit, just as much as — and probably more than — consistency.
2. Usability: structure provides predictability
3. Translation: savings from reusing translation
The panelists remarked that they expected this one to score higher, and theorized that many of the survey respondents were content creators but were not the people actually responsible for translation. I think they’re probably right — and I’d also point out that a lot of organizations simply don’t translate their content. It would be interesting if the survey asked how many are currently translating DITA content.
4. Customization: segmentation, personalization
Nice to see this one crack the top 4. I think we (the community of DITA content producers) are just beginning to take advantage of features like metadata and keys. There’s so much more we can do to adapt content based on the audience’s geographic location, experience level, and so forth. (Key scopes and branch filtering in DITA 1.3 hold out even more promise.)
Rank the biggest challenges associated with using DITA
This section was open to respondents who said they use DITA.
1. Reuse: determining reuse strategy
Conref or keyref? What taxonomy to use, and where to put the metadata (in topics or in maps)? Who “owns” the library of reusable content? There doesn’t seem to be much consensus on best practices when it comes to developing a reuse strategy. Maybe, like the consultants always say, it depends — on what the writing team is
used to, on which groups are collaborating to produce content, and on what the corporate culture will support.
2. Usage: making DITA do what we want it to do
3. Training: equipping staff with skills needed
There’s a ton of training out there — in the basics of structured authoring, in DITA itself, and in the various tools. So I’m not sure what the problem is, unless it’s that companies don’t want to pay for training and want simply to hire people who already know everything (see #7 below). Even if you could hire fully-capable DITA writers off the street (and that’s a big if), they still need to be trained in how to use your local style, transforms, and so forth.
4. Technology: understanding software
5. Formatting: developing stylesheets and rules for content
This isn’t rocket science, but it is serious, hard work. It’s often not considered when companies plan a transition to DITA — which makes it even harder.
6. Governance: enforcing the rules
See number 5 above.
7. Staffing: finding experienced talent
8. Creation: understanding how to create DITA content
9. Measurement: what to measure, how to decide
Let’s be honest: rather than what to measure, don’t we really mean making the business case? We still struggle to quantify the cost savings and revenue enhancement associated with structured authoring and DITA. Translation savings, of course, are a big part of the story. But increased usability, customization, and brand consistency have value too. We just have a hard time quantifying their value.
10. Translation: issues associated with DITA content
So there you have it. What do you think? Do any of the rankings surprise you? Is anything missing from either list?
Do you agree with my take?
Thanks to Scott Abel for conducting the survey. Like so much of what he does, it’s of great value to the technical writing community. Thanks to Rob, Mark, and Keith for their contributions as well.