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.
Two of the three conditions Kay Robart provided best describe when a writer should use passive voice instead of active voice in technical writing:
2. You want to deemphasize the actor.
3. You want to conceal the actor.
I left off Kay's #1 because when there is a case in tech writing in which an agent is unknown, a diligent writer with enough time really should solve the mystery.
Regarding #2, "An alert has been posted" and "Your email has been delivered" are vastly superior to "The system has posted an alert" and "MS Outlook has delivered your message." The passive voice, in these cases, gives the user the critical information they need in the simplest and smallest package possible. In contrast, as soon as you include an agent, "The system", you add information the user doesn't want or need. You force the user to focus on the software instead of the task they were trying to accomplish.
Regarding #3, there are instances in my own writing in which my company does not want to reveal exactly which bits of the software are doing what and how. The information wouldn't help the user, but should it fall into the hands of competitors, it could put the company at a competitive disadvantage.
Regarding Chris' "Second" point ("this argument was settled by research back in the 80's or 90's"), if he can't produce the research, the claim is useless. Who found this to be true for what types of information for which populations under which conditions? Even were the answer to this question, "All information for everyone under all conditions," the claim is still of very limited value as enabling a user to recall information is not always the end of technical documentation.
-----Original Message-----
From: techwr-l-bounces+lporrello=illumina -dot- com -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+lporrello=illumina -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Chris Despopoulos
Sent: Monday, October 22, 2012 3:58 AM
To: sphilip
Cc: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Re: passive voice (was RE: Numbering paragraphs
Well, I'll try not to spiral into an endless argument about this. I'll just say four things.Â
First, active voice, when describing a person's interaction with a system, provides more information per word. The simple example, "An alert is posted" says less than "The system posts an alert." To say as much in passive voice requires "An alert is posted by the system" That's almost a 30% increase in words.Â
Second, this argument was settled by research back in the 80's or 90's as far as I can recall. Simply put, people retain active statements better than passive ones. And no wonder, when you consider the increase in verbiage (read increased cognitive load), or alternative reduction of information, coupled with the indirection of the statement.Â
Third, when documenting software for users or developers, I believe I never *had* to use passive voice once. After I finally broke the habit, I may have used it on occasion, but could probably count those instances on one hand... And would probably regret them if I saw them today.Â
Finally, while there might indeed be situations in which passive voice is appropriate for tech doc, I maintain they are rarer than its use. In my specific corner of the tech writing world, much rarer. And no, I'm not talking about pure instruction here. (For another whopper of a flame war, I'll say that what we call procedural documentation is brain dead and we need to pull that plug now. But save it for another thread.) I'm talking about setting context, describing states and settings, and the like. *Especially* for that kind of writing, active voice is superior IMO. In my experience, a manual loaded with passive voice is the product of an inexperienced or lazy writer. When the person writes "An alert in posted", in my experience that person cannot answer the question "Who or what posts the alert?" This is usually because the person never bothered to ask the question. While the example is trivial, this is not a trivial issue. This is about giving the reader a realistic understanding of the system so he/she can realistically think through situations you could never have documented. Most definitely, if you cannot answer that question, you have no business writing the statement at all. It's your job to know these things, and critically decide whether to share them with the reader. Defaulting to passive voice is too often just a way to sweep dust under the rug. This is my opinion, and arguing it will get us nowhere... I'll not change my opinion, and you'll not change yours.
So... We probably have to agree to disagree on this. I'll continue to red-line passive voice when I see it in review. If you're in love with passive voice, you'll probably never hire me.Â
cud
PS
I lied... I have one more thing to say. As a challenge, why not go back to your favorite passive passage, and see if you can name all the agents of the actions and states you describe? I bet it would take some effort on your part to do that. And so I'll ask you, don't you think the reader would have to put out the same effort (or more)? Why would you intentionally shift that cost over to the customer?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Writer Tip: You have more time to author content with Doc-To-Help, because your project can be up and running in 3 steps.
See the “Getting Started with Doc-To-Help” blog post. http://bit.ly/doc-to-help-3-steps
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com
