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:Acronyms--How often do you spell them out? From:Geoff Hart <ghart -at- videotron -dot- ca> To:TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>, Katherine Darges <katherine -dot- darges -at- defensegp -dot- com> Date:Mon, 31 Jul 2006 15:36:24 -0400
Katherine Darges wondered: <<I am editing a multi-section document,
with each section 50 to 75 pages. The document was written by the
Government for the Government. Phrases that get turned into acronyms
are spelled out when they are first used, followed by their acronyms in
parentheses - most in the first section. Appendix A is a complete
acronym list - about 300 all ogether (this IS the Government, after
all). Would you re-identify the acronyms in each subsequent section as
well as adding the new ones? Or, is once really enough, based on the
fact that the readers of the document have all been involved in the
project of which the document is a record?>>
The standard convention for defining acronyms is that they should be
spelled out the first time they appear in each discrete section that
readers can be expected to read so that readers will understand them.
So in a single-author book that you can expect readers to read from
cover to cover, once will suffice. In a multi-author collection such as
a symposium proceedings, once per submitted paper is the rule of thumb;
this same approach applies for reference material (once per chapter).
Where you don't have any clear idea of what readers are going to read,
or where they will enter the text, your solution of providing an
acronym list is a good one--though I'd expand this into a full glossary
to cover any other non-acronym technical terms that might stop readers
in their tracks. This is equally true for things like online help, and
for the same reason: you can't guarantee that anyone will encounter the
first definition, and rather than throwing up a roadblock, it's better
to provide such a resource to ensure that they can find the meaning and
keep reading.
However, forcing someone to stop reading just so they can look up a
definition takes them out of their current task, which is understanding
the current sentence. (Also, a good proportion will never realize that
you've provided a glossary. <g>) Thus, you should provide the
information "just in time"--once per section, where they have a chance
to read it. That's particularly true for material that will be
extracted from the main document and stored separately on the bulletin
boards and bookshelves of individual offices--which happens more than
you'd expect based on my tenure as a federal wage slave. This does
create a certain amount of redundancy, but isn't that better than
preventing comprehension?
You state that readers have all been involved in this project, and this
may be true _now_. But any document of continuing interest will attract
many readers who weren't part of the project. For them, and for people
like me who take a long time to memorize all the acronyms used in a new
project, it's a kindness to provide definitions on the go, where
readers need to see them.
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at http://www.DocToHelp.com/TechwrlList
