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.
A lot of conceptual and background information is a waste of
everybody's time & money and almost guarantees--heck, guarantees--that *no
one* will read it, unless they have a need-to-know the conceptual &
background info. I'd argue that an indepth inclusion of such info makes it
no longer a manual, but a textbook, an entirely different animal.
Background isn't so much the problem of the textbook aspect of an
encyclopedic info dump (to me that suggests an orderly, systematic, but in
this case excessive amount of info); for me it comes down to the difficulty
of dissecting away the background to allow a clean presentation of the
necessary information. (dogma alert!)
The water plant worker doesn't need to know how how much concrete went into
building the spillway, or the velocity of water in the valve s/he's going
to open. S/He just needs to know how to divert the overflow so the plant
doesn't flood.
I think that doing the backgrounder along with the technical manual is, as
you say, a different animal. I encounter these critters in material that
has been elaborated by engineers and then handed off to me for "writing".
And, I come up against these critters when the target audience is diverse.
A few places where backgrounders could be important: writing a manual that
targets business analysts and product managers--one needs excruciating
technical detail, one needs the bottom line. Or, for an audience that
includes programmers and end-users. They are hardly capable of the same
vocabulary! A little background would be necessary....
That's why audience analysis is so important. I could easily write for
analysts and programmers (they share a vocabulary), but not so easily for
programmers and end user (they don't). Rather than depend on the
backgrounder to reconcile these audiences, why not write for each one
separately, do a separate backgrounder too?
As a technical communicator, I want to tell you about a procedure. I want
to present an unambiguously and predictably systematized collection of
information that you need to know. I want to concentrate on weeding out
the distractions, whether they result from weak writing, poor organization,
or digressive information. If the sme has managed to become the context of
the information, then I want to dissect it away enough to expose the
structure of the information. I don't want it all tangled up in his nets
of learning and background. I don't want important meaning to be lost when
I cut out some wandering passage of background. If you're building your
specifics up on a structure of deep background, then it isn't going to
stand if a piece of the background is missing.
This also isn't just about background, by the way. Getting the reader to
the point is surprisingly important to them, and anything that obscures or
clutters what they need to know can be unwelcomed. I've worked on medical
technology manuals where the user/reviewers resented the hell out of my
having written complete sentences using articles (the, an) in the
instructions. They crossed the articles out! They're busy, technically
informed people, and they are occupied with complex tasks, and they can't
afford to be distracted. They want you to know what you're writing about,
so that you don't waffle when you should be direct, They want you to
telegraph instructions to them in economical ways. Background material
would thwart good communication in cases like that.
