Frame versus Word. Robohelp versus Flare. DocBook versus DITA. Coffee versus green tea. Those are some of the debates that many of us in the technical communications field take part in regularly. OK, maybe not the last one …
But I think that the DocBook versus DITA debate is one of the biggest ones going on right now. This article at The Content Wrangler looks at the DocBook and DITA’s strengths and how to make the choice. Teresa Mulvihill (with whom Aaron and I will be doing a podcast interview at DocTrain West) also wrote an excellent comparison of these rival XML schemes.
My take? DocBook and DITA both have their places. They’re both excellent for single sourcing. DocBook is better for what I call monolithic single sourcing, while DITA is better suited for discrete single sourcing. If you don’t have a lot of reuse of content in your organization, then DocBook is a good choice. If, on the other hand, if there is (or you anticipate) a lot of reuse then consider DITA.
Thoughts? Feel free to leave a comment.
In many ways, technical communications is just like any other field. When it comes to the people doing the job, the level of skill, dedication, and competence varies from person to person. You have outstanding practitioners and those who are in the job only for a pay packet.
I recently read an article at CIO.com that looks at the problems you might face when trying to hire a writer. Some of the advice is old hat; some of it useful.
Charles Cooper at The Rockley Blog has written an interesting post on the need to think lke a user when developing a document.
Cooper makes one cogent point:
The fact is, most people, especially those who are new to our product (or concept, or service) just don’t have the background they need to ‘instinctively’ find what they’re looking for. So much of what we think of as ‘instinctive’ is really backstopped by prior knowledge.
After another unintentionally long hiatus, we’ve posted a new episode of the podcast. In it, we discuss what we’ve been up to and what we plan to do in the coming weeks. Then, we discuss a topic that is very important to Aaron: usability.
You can listen to the podcast here, or use the embedded player below.
Regardless of what we’d like to believe, technical communicators aren’t perfect. Neither are the development and project management teams with whom we work. Sometimes we get things wrong and that makes it into the final release of the documentation. Or, for whatever reason, something gets missed.
Nowadays, most documentation is distributed electronically — as a PDF, HTML, a help system, or all of the above. So, it’s a lot easier and cheaper to issue updates to documentation. In a number of shops in which I’ve worked over the last few years, updates and changes and corrections have been slipped in rather stealthily: replace the old electronic version with the new.
The other day, I was browsing the documentation at the Web site of Red Hat. I noticed something interesting while I was there: a link to documentation errata. I haven’t seen something like that for a while, and it’s a nice touch.
The errata page links to updates for various guides. There are also detailed instructions on how to submit corrections using Red Hat’s Bugzilla tracking tool.
How do you deal with errata? Feel free to leave a comment.