TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Few monster books vs. Many smaller books From:Robert Busch <robert -at- FOCSYS -dot- FOCUS-SYSTEMS -dot- ON -dot- CA> Date:Thu, 2 Mar 1995 12:54:53 -0500
Greetings,
I'm interested in your opinions -- and if you know of any recent
research -- on the question of the usability of large, all-inclusive
manuals vs. smaller, modular manuals.
Our information development team feels that we should re-organize a
Programmer's Guide. Currently, it's a monster book (two volumes,
actually); we'd like to see a series of smaller books documenting
individual modules, instead. The product we're selling is modular --
out of around 12 possible modules, customers will typically buy about
six.
The problem is, our product manager disagrees with us. He likes the
"big book theory." His arguments:
1. It's more usable, because people won't have to worry about losing
individual books.
2. When people read about modules they don't have, they might buy
them.
3. Nobody else in the industry takes the modular document approach.
Of course, we have our rebuttals. Argument 1: a good point, but the
occasional search for a misplaced book isn't as inconvenient as the
daily challenge of sifting through unnecessary information. Argument
2: this book is for users, not potential buyers. Argument 3: the
documentation in this industry (machine vision) is notoriously poor;
developers complain about it all the time.
Of course, modular documentation would be cheaper to administer (time
and $$).
Because of unfortunate political circumstances in the company, we
can't make decisions like this without permission from the product
manager. And he seems determined to stay with the big book approach.
I'd like to support our ideas with usability research, if possible;
can anyone think of anything relevant?
BTW, I realize we should make this decision based on user research;
because of even more unfortunate circumstances, that isn't possible.
Sigh.
Thanks very much for any help!
Robert Busch
Information Development Team Leader
robert -at- focus-systems -dot- on -dot- ca
