Binders vs. books

[geoff-h -at- MTL -dot- FERIC -dot- CA]

 Ginna Watts asked for advice on using bound books vs.
 binders.

 <<Last year's software manual was the first to be 'perfect
 bound', as opposed to in a binder, and got rave reviews.>>

 Seems to me that you've just defined your question more
 precisely. Why go against the preferences of the users?
 Sounds to me like the losers in the holy war haven't
 conceded defeat just yet. If there's a compelling reason to
 change, then by all means, change... but don't piss off
 your audience just because someone's ego didn't get salved
 the last time around.

 <<The theory is that we will have several new modules of
 the software released throughout the next six months, and
 these could simply inserted into the binder.>>

 It doesn't cost much more to produce small, saddle-stitched
 books for each module than it does to produce them with
 holes punched... and the larger the module, the less
 (proportionally) the cost difference. I still don't see any
 reason to go back to binders.

 <<Currently, we produce oddball module docs in a small
 saddle-stitch booklet.>>

 Have your users given you any reason to suspect they don't
 like this approach? If not, don't mess with success.

 <<Is it possible to update sections of an existing manual
 that is numbered in one flow, or will it have to be
 reformatted to chapter numbering?>>

 Chapter numbering (e.g., 1-1, 1-2, etc.) could make this
 easier, but I wouldn't bet on it. If you have to insert a
 page between 1-1 and 1-2, what do you do? The answer is the
 same as for linear numbering (1, 2, 3 etc.): produce an "A"
 page so the insert becomes 1A (and subsequent inserts would
 become 1B, 1C, etc.), or reprint the whole module. But
 releasing updates is a problem if the book is bound,
 because there's no way to add pages. If you expect _lots_
 of updates, you either need to go with a binder or find a
 way of reprinting entire modules cheaply. If you're going
 to do that, chapter-based pagination might save you
 considerable hassle.

 <<I am having trouble seeing how it can be done without
 breaking pagination, indexes etc., but I will bow to your
 knowledge.>>

 Well, the index is automatically broken when you add a new
 page simply because the contents of the new page don't
 appear in the index. The big advantage of reissuing the
 whole module is that you can redo the index too. Of course,
 you could reissue an updated index along with the change
 pages, but that's going to be costly.

 <<Has anyone had any experience sending out change pages?
 Do users actually insert them? Are change bars or some such
 necessary?>>

 I have a love-hate relationship with binders and change
 pages. I've done the "insert new and throw out old" routine
 enough that I really don't like it. And I find that
 frequently used binders chew up the holes in the pages and
 pages start getting lost. So in that sense, I don't like
 binders. But for material that changes regularly, binders
 may be the only alternative. I've heard plenty of anecdotal
 evidence (and have seen examples personally) that users
 simply don't bother inserting revised pages. It's going to
 depend on your audience, but don't assume that people will
 do the updates just because you provide them.

 One big question to ask up front is why the changes occur
 in the first place: are you trying to fix a problem in your
 development process by reprinting? Should you fix the
 problem _instead_ of reprinting? Questions worth asking...
 And another suggestion: for documents that change
 regularly, this might be a strong hint that you need to put
 the information online. This is both economical and a
 courtesy to your readers, which makes it a win-win
 proposition. One excellent strategy is to issue in bound
 form only information that you expect to have considerable
 longevity, and to release other changes only online with
 the updated software.

 <<Harder to maintain change in a binder, or update
 booklets?>>

 Harder for whom? The inconvenience is probably about the
 same, just reallocated between you and the users. I don't
 consider it good customer service to make the users do the
 work for you, but it may be the only option in some
 contexts.

 From what you've said, it sounds to me like you need to get
 a much better grasp of how people are using your
 information and why you're revising it so frequently before
 you can choose among the options I've discussed. Several of
 my options will change if your picture of the user needs
 changes.

 --Geoff Hart     @8^{)}     geoff-h -at- mtl -dot- feric -dot- ca
 Disclaimer: Speaking for myself, not FERIC.

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html