Topic-based authoring is old, say going back to Ed Weiss' "How to Write a Usable User Manual" and STOP back in the 60's. But, if you knew how to do that, English majors would cringe and not hire you.

Coverting to non-linear, topic-based authoring should have been the norm back in WinHelp, but of course, single sourcing back then meant ignoring media specific drivers of information architecture.

Apparently, the hardest thing about DITA isn't teaching English majors how to write it. It's getting the junk to run. The consultant can't do it. The vendor can't do it. So it will be deadopted by our shop. I think the savings gained in reduced translation expense is more than made up by vendor and consulting costs. As I remember it, my last DITA shop had two production people whose job it was to make the junk work.

I came late to the implementation here. Be absolutely sure to write up the requirements including the things you think should work like page numbers on TOCs, and indexes, cross references, conditional text, figures that are not enlarged or shrunk, and the page layout you want. And, the bigger time wasters like an application that can't keep the graphics filepath and the xml file filepaths separate, or the labels in the editor that should show up in text, but don't. Then, run an acceptance test against all the vendors. The software they install for training isn't what you'll install in production. Your production install won't work. Don't go fast. They want to sell you stuff beyond DITA. Skip them. Take your time. It will take you a year to get the junk to work.

Topic-based authoring is easy. Getting output is hard.

David Locke