Communications from DMN

That’s a question which has been on my mind for a while now. With all the talk about Web 2.0 and the attendant technologies, I’m wondering if our readers are actually being better served by documentation now than they were 10, five, or even two years ago.

Building what we think is the perfect beast

Reading this space and elsewhere, it’s not hard to see that the way in which technical communicators are creating and disseminating documentation is changing. More and more, we’re using technologies like XML and wikis and screencasts to deliver documentation. In the future, I can see there being more use of portals like SharePoint and technologies like Adobe AIR being used to get our words to the people using the software and hardware that we’re documenting.

But do readers, the people who are actually using the documentation that we’re authoring, really want or need this? Or is it a case of us being too clever by half, becoming enamoured with the latest tools and technologies, and embracing our inner geeks?

Some in our community sneer at so-called old school methods of authoring and delivering documentation. FrameMaker and DocBook don’t cut it any more. Dead trees manuals, PDFs, and HTML based help are old hat. Not everyone in our profession thinks that way (I sure don’t!), but I’ve encountered more than a couple of technical communicators who do.

The right deliverable for the job

What is that? That’s always been something hard to pin down. There are a number of factors that affect the choice of deliverable, and those factors vary from project to project and product to product.

Technical communicators have to remember that we’re not creating documentation for ourselves. We’re creating it for an audience who wants to learn how to use an particular piece of software or hardware. They want to find out how to get things done, and they don’t care how the documentation was created. They just want something that embodies what I refer to as the five Cs (yes, the list has expanded):

• Clear
• Concise
• Consistent
• Complete
• Correct

So, the documentation could be in a wiki. It could be in a set of inter-linked knowledge base articles. It could be online, built from a set of discrete XML files. It could be an installation and getting started guide, which is accompanied by task-based documentation. Or, it could be an HTML Help file or a monolithic PDF.

Conclusion

To be honest I haven’t come to one yet. I know that documentation is important, and I’m intrigued by the possibilities of new technologies and methods. We definitely need to balance our passion for the technologies that we use to create and distribute documentation with the needs of our readers. Just because we build it with the latest and greatest doesn’t guarantee that people will come and use it.  Or that the documentation will be better in any way, shape, or form.

I’m not saying that we ignore new methods and tools for building documentation. On that other hand, we shouldn’t dismiss older tried and tested tools and methods as being antiquated.

But I also realize that there’s no one-size-fits-all solution to documentation. Each product and each audience for that product will always demand something slightly different in the way of documentation.

Thoughts? Feel free to leave a comment.