Binders vs. books

Subject: Binders vs. books
From: geoff-h -at- MTL -dot- FERIC -dot- CA
Date: Thu, 6 Mar 1997 11:29:02 -0600

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


Previous by Author: Reading postscript
Next by Author: Decompiling Win3.1 help files
Previous by Thread: Re: Binders vs. Books
Next by Thread: Distilled wisdom: OS2 screen captures...


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads