Re: Binders or Binding?

[Robert Plamondon <robert -at- PLAMONDON -dot- COM>]

Ginna Watts writes:

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

Yes.  No.  No, because everyone ignores the updates.

I believe that sending out complete, updated manuals is more effective
than sending out changed pages, though the users tend to ignore both.

From the point of view of effective communication with the reader, it's
far better to get it right the first time.  Sending out documentation
in dribs and drabs tends to cause the users to tune you out, just as
you would tune out someone who sent you a jigsaw puzzle a few pieces at
a time.

From a document-management point of view, incremental updates are very
troublesome.  By taking a single product and chopping it into pieces
separated in time, many issued aren't revealed until the piece that
should be corrected has already shipped.  Maintaining quality and
cohesion is more difficult than in a monolithic document.

The updates themselves are very labor-intensive.  It's usual for incremental
releases to require vast amounts of manual labor to maintain page numbers,
tables of contents, indexes, and change bars.  All of this work would
vanish if the document were published monolithically, and most of it
would vanish if the entire document were republished, rather than issued
serially.  Few tech pubs departments are so far ahead of schedule that
this labor can be spent willingly.

In many cases, the money spent on binder-based documentation is greater
than that spent on simply reissuing the document a couple of times, once
you count the labor (which dominates almost every tech pubs project
budget).  And all you have to do to make the printing and distribution
savings vanish is to make a few changes in the early chapters, requiring
that the old pieces be reissued along with the new.  This happens more
often than not.

In my experience, binder-based documentation is very unsatisfactory.
I gave up on the concept before 1990, and have never regretted the
decision.  If it's absolutely necessary to ship incomplete documentation,
I prefer sending an edition marked "DRAFT," and indicating the missing
chapters.  Users are far more likely to discard a draft document in favor
of a completed one than they are to discard one production version for
another.  This also leaves the door open for the tech pubs department
to make necessary changes in any part of the document without raising
eyebrows.

In my experience, though, nothing will make users update their binders.
I once strolled through an engineering department to see what had happened
to an updated spec, which was allegedly the blueprint used by every
engineer to create the new project.  Virtually all copies were buried
and forgotten in piles of unread material, while the engineers were
relying on long-outdated editions that they preferred because of their
marginal notes.

Thus, I have acquired a disliking for "living documents."  Living documents
are too often dead on arrival.  If you get it right the first time,
you save everyone a world of trouble.

        -- Robert
--
Robert Plamondon, High-Tech Technical Writing, Inc.
36475 Norton Creek Road * Blodgett * Oregon * 97326
robert -at- plamondon -dot- com * (541) 453-5841 * Fax: (541) 453-4139
http://www.pioneer.net/~robertp

 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