Rumor has it that when he was Director of Central Intelligence, Allen Dulles would judge the quality and validity of an analyst’s report not by reading it but by hefting it in one hand. The implication there, obviously, was that the heavier the report the more (figurative) weight it had.

When I started in this business, that idea seemed to apply to documentation too — here’s a good story about that. In fact, I remember one employer chiding me because I wrote something tightly and he was expecting about 40% more. That was despite the fact that I packed as much information in that space as the previous writer would have in a longer manual.

But does a manual need to be (in the words of a former co-worker) a tome? Do you need to document everything? Tom Johnson convincingly argues that you should, but not put every bit of information into a single place.

I agree with Tom here. The days of the monolithic tome — whether in print or online — are dead. We have so many ways of giving users what they want, in the way they want it. All it takes is the imagination and effort required to use them. It’s not easy, I admit, but it can be done.

Of course, there are times when a guide should contain everything. And those are more technical guides, like ones covering complex installation and configuration; operational procedures; troubleshooting; and API/programmer references. Once again, you’re not limited to a thick book that falls with a thud. And, once again, you have ways and means to deliver all of that information in a concise, easy-to-use form.

Thoughts? As always, feel free to leave a comment.

Related posts:

1. Style guides
2. Working with subject matter experts
3. A question and an answer about style guides