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.
RE: [BULK] Re: On the value of glossaries containing terms the audience should already know
Subject:RE: [BULK] Re: On the value of glossaries containing terms the audience should already know From:"McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com> To:Robert Lauriston <robert -at- lauriston -dot- com>, Julie Stickler <jstickler -at- gmail -dot- com>, techwrl <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Mon, 23 Dec 2013 10:41:07 -0500
On the third hand, if you are describing setting up networked equipment for a medical practice or a clinic or lab, you might be crossing boundaries where it could be useful to have a section (a glossary) to confirm what YOU mean when you use the acronyms and initialisms. Otherwise, the Deviated Nasal Septum server might be improperly referenced. :-)
I think "It does not hurt..." is a reasonable approach. It covers the bases at negligible cost, and anybody who doesn't need it won't even see it, on their way to what they [know they] do need.
Also, if you have been doing your bio computations in PERL and C, and are just now looking at switching to Java, you might have both those books on your desk, and might appreciate a glossary.
-----Original Message-----
From: Robert Lauriston
Sent: December-20-13 3:03 PM
To: Julie Stickler; techwrl
Subject: Re: [BULK] Re: On the value of glossaries containing terms the audience should already know
I think that's wrong when you're writing highly technical documentation for products that are used only by people who use those acronyms all day long.
At my last job I was documenting a complex enterprise product that was usable only by very experienced networking professionals. Anyone trying to use it who did not know what RFC, ssh, LDAP, DNS, and IP mean would have to hire someone who did. The jargon is so standard in that realm that I can't even remember what all of those acronyms stand for, even though I know exactly what they are. Nobody reading my docs would think they had anything to do with a deviated nasal septum.
The more general rule is that when the audience is only advanced users, you don't write the same way you would for beginners. It's like the difference between "Java for Dummies" and "Advanced Java Programming Techniques for Computational Biology." There are prerequisites.
On Fri, Dec 20, 2013 at 11:26 AM, Julie Stickler <jstickler -at- gmail -dot- com> wrote:
> It does not hurt to define your acronyms, no matter how common you
> think they are in your industry. I can guarantee you that someone,
> somewhere uses the exact same letters to mean something totally
> different that what you're expecting.
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
