DITA is not the answer

Single sourcing is good, I’m sure most of us can agree on that, but I’ve recently been wondering if perhaps DITA isn’t quite good enough?

The thing is, I’ve been looking at DITA as a solution for our single sources needs for a while now. I’ve attended conferences, read whitepapers, listened to vendors and everything else that goes with it and I’ve got a pretty good handle on things. If applied correctly the benefits you can gain are very large, although the same can be said of any other single source project, yet what seems to be consistently missing during all of these wonderfully theoretical discussions is the cost and impact of getting such a solution “applied correctly”.

A key part of planning to move to single source, of which DITA is only a part, is understanding the business needs and technological requirements of all of the content producers in your organisation. Traditionally that means Technical Communications, Training, Pre-Sales and Marketing, with perhaps other flavours to be considered depending on how your company is structured.

However, if those parts of your organisation aren’t yet ready to move, then the business case changes. At present this is the situation I’m in, so I find myself looking for a short-term (2-3 year) solution that won’t lock us in to a proprietary format and that can give us benefits as soon as possible.

Re-use is our main reason for moving to single source. We don’t (yet) localise, and there is only one other team that has any interest in re-using our content (and even then, they are likely to use it as an source of verification, not a source of content). With that in mind, and with the proviso that I’ve used it previously, we are looking at AuthorIT.

Yes it does mean we forego a lot of the power of DITA but as it will allow us to tag topics accordingly (in keeping with the DITA model) and it does have an XML DITA output option, then it shouldn’t lock us in. I’m willing to put up with a little pain further down the road to get the benefits now.

I’m still not entirely sure what else we are missing. We publish PDFs, HTML and Javahelp, all of which AuthorIT handles, and as yet we don’t have a need to dynamically publish information based on metadata. If that changes in the near future then we’ll handle it appropriately but it isn’t on anyone’s radar.

I am concerned about the versioning capabilities of AuthorIT as we maintain the last 3 versions of all our publications, but I know there are ways to achieve this in AuthorIT. I doubt it will work as well as our current system (FrameMaker files in an SVN repository) but, as is always the case, I do expect we may need to make some compromises to get ourselves moving towards single sourcing our publications. This is our main pain point and so becomes the focus for any possible solution.

DITA remains the long-term goal but, and I’ve said this before, until there is an all in one solution that is easy to rollout it remains marginalised as a viable option. Most of us need to produce some form of business case to justify such purchases and, at present, DITA is still too costly an option. I’m always happy to learn new things, and whilst I would love to be able to invest time and resource into creating and maintaining a DITA based solution, I just can’t justify it.

All of my research suggests that, rather than being a simple installation and conversion process, creating a DITA solution requires a lot of technical know-how and a not insubstantial amount of time and resource. We can handle the first, the latter is (I believe) not yet at a level which makes it cost-effective.

Ultimately, for the moment, DITA costs too much.

Do you agree? Can you prove me wrong? I’d love to hear your thoughts on this, particularly if you have implemented DITA already. I’m keen to hear just how more productive a DITA solution can be if you aren’t involved in localisation. Have you recouped your costs yet?

Perhaps DITA is only really applicable for those with large budgets and the chance to invest heavily upfront. Alas I’m not in such a position. For the moment.

Comments

  1. It sounds like we haven’t quite gone to the same length as you and merely dipped our toe into DITA – yet our conclusion was the same: Ultimately, we couldn’t make a (business) case for moving to DITA.

    Instead, we moved to MadCap Flare which suits our single sourcing needs just fine, thank you: We produce primarily online help with PDF (via Word) as secondary deliverable and may localize by simply translating the individual Flare projects.

  2. I’m waxing agnostic about single-sourcing and DITA today, probably mostly because I’ve seen some terrible implementations that sucked all the life out of the documentation.

    When the form becomes too rigorous, the documentation starts to resemble machine-generated instructions, and users zone out. Until we have really smart AIs, the human touch is needed. Some forms discourage much of that.

    So far, keeping data in an SGML-based format like FrameMaker has been highly useful, but even without that, data can be extracted from many formats using scripts in an OS-based language or an SDK. When we look at lengthy, expensive projects, sometimes the thought of a week crafting scripts is less daunting that converting to a format whose utility remains unproven in most cases.

  3. Not sure what you mean by “Perhaps DITA is only really applicable for those with large budgets and the chance to invest heavily upfront.”

    What costs are you referring to for an open-source project such as DITA? Dita-friendly editor? XXE by XMLMind is available for $250/user. Dita-friendly CMS? XDocs by Bluestream is well under $10K.

    Regarding technical know-how, yes you’d benefit by having a DTD/XSLT/FO expert to handle customizations, but if you’re sourcing in XML or SGML, seems like you’d need that person on your staff anyway.

  4. Mark, I’m primarily talking about resource costs, how many people and for how long?

    And as you say, we’d need to hire someone with more XSLT/FO knowledge. The CMS cost is much larger than the editor costs as well… it all stacks up.

    I’ve done hard figures for a Business Case around this and the off-putting part is always the cost of the implementation, not the software.

  5. Gordon, re MadCap’s lack of JavaHelp:

    I talked to Mike Hamilton of MadCap in November about this. He said that the addition of new output formats was up to review in January 08 and suggested I send an email around that time. So the MadCap guys know about it – and maybe can be swayed… From what little I know the step from WebHelp to JavaHelp isn’t that large…

  6. Spot on analysis! I’ve been deep into DITA and DocBook since 2004 and came to a similar conclusion some time ago. While the benefits of DITA are clear, organizations looking to DITA should steel themselves. Unless they intend to keep the effort small scale, they should be prepared to play the “DITA for Dollars” game. The vendor and consultant community smelled blood in the water in early 2005, and they’ve been in a feeding frenzy ever since. Meanwhile, other mature and viable low-cost solutions rarely get a mention. While my client’s business requirements drive my recommendations, I’ve yet to encounter a situation where DITA was the best answer. In nearly every case, my clients balked at the costs associated with implementing a DITA solution.
    I remain very impressed with the power of DITA. With every release of the DITA OT, things seem to get simpler, and so much credit is due to the DITA TC and the folks at IBM. Nevertheless, I believe we’re still at a point where the costs of implementing DITA limit its viability to those organizations with pockets deep enough to hire the talent and purchase the tools needed to make things work.
    All the best,
    Tony DaSilva
    Antonio DaSilva Associates

  7. I really enjoyed this post and the comments exchange. I’ve explored DITA a bit but was turned off when I realized there was not webhelp output. My main two deliverables are user guides and webhelp, which Flare does a pretty good job with.

    As far as pushing the same content out to other formats, such as mobile devices and quick cards, I couldn’t just use the same text anyway (the writing space is so different), so using DITA to single sourcing beyond these two main deliverables isn’t what I need.

    Also, I once saw a PowerPoint that was created with DITA, and it was extremely plain and unimpressive.

  8. I think we need to be careful Tom, not to tar DITA too early because the outputs aren’t any good. That’s not really the fault of DITA (separate of content from layout and style after all).

    And you’d specialise topics for mobile devices and quick cards… but that’s my point. All of that, the specialisation and ‘nice’ output templates and engines take time to hone, and time is money unfortunately.

  9. Pingback: WriterRiver.com
  10. Pingback: | one man writes
  11. Reading this thread has made me jealous of all the Flare users out there. I’ve wanted to get it but can’t. I make do faking single sourcing using RoboHelp X5. This approaches the statement in the above post about single sourcing onlne help to a printed manuals, which is something I do but a good deal of massaging of the printed output in Word is needed and then a PDF print utility is used to create the final draft of the manual.

  12. I have never seen single sourcing work. Maybe a single author who knows the topics thoroughly enough to reuse, or a tightly knit group of writers synched up at the same level.

    But mostly, I have been with companies that trumpeted topic based writing and reuse during the SGML Docbook phase of the early nineties. And I just left a company that uses Vasont CMS and XMetaL where all writers worldwide author on a single db. It doesn’t matter. Content reuse, even when requiring a single search and reference by a writer to another’s topic, rarely happens.

    And forget about getting training or anyone other dept to reuse–even when fully localized. I just requires too much coordination. Some companies tout content reuse to justify localization–sometimes MT–but I would like to look at the books to see if it is really viable.

    The only place we are going to reuse content is in web mashups using semantic markup once the content is in the cloud. How does semantics come into this? I’m still thinking that through. See Dbpedia.org for more questions.

  13. Interesting discussion. I could both agree and disagree with many of the points raised. My company has implemented single sourcing with DITA. It works–for example, I can update a set of topics and by doing so update 5 different manuals. Our “reuse magic” is mostly accomplished by ditamaps and conditional content. But after 1.5 years, I’m the only writer on our DITA project. One of the writers here made a good point–if there were 10 writers and 1,000 topics, would the writers know the content well enough to know what information to reuse? For 5 manuals, our cost was pretty high–i.e., the cost of a DITA-aware XML editor and CMS software. For us DITA has been a success, but it doesn’t solve all our problems either.

  14. Gordon,

    I enjoyed reading your thoughts on DITA and at the time you wrote this article I think you were spot on. (Have you used DITA since?) Since then though, the market has tried to tackle this problem with the growing number of tools to help lower the barriers to DITA.

    For the past two years that has been exactly what my company has been doing in developing easyDITA (http://easydita.com). I’d love to give you a demo sometime and get your thoughts on our shot at an end-to-end “easy to rollout DITA” solution.

    Cheers,

    Casey

  15. Casey,

    Switching publishing systems is not a simple matter so, unfortunately and entirely due to the timing, I have not looked at DITA in any great detail since.

    As I tried to suggest, I’m sure the vendors will start to get easy to rollout solutions but, for at least the next couple of years, it’s not something I’d be looking at.

    My post was more to flag this for others, DITA is a great idea in principle, but in practice (at the time of writing) is was, IMHO, too resource intensive for most technical writing teams.

Comments are closed.