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:RE: active voice v. passive voice From:"Sella Rush" <sellar -at- apptechsys -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 23 Feb 2001 14:06:46 -0800
There's a difference between using passive phrases and creating a
construction that obscures the action.
> New: Two topologies are available in defining Cats: pedigree or moggy.
The sentence above removes the emphasis on the action, which is perfectly
valid if the focus of what you're writing is on the nature of the data
itself rather than on the task of entering or viewing data.
If, however, you're writing tasked-based instructions or otherwise informing
users on what they need to do, you need to emphasize the action. You can do
this using either passive or active:
Passive: Cats can be defined as belonging to one of two types: pedigree or
moggy.
Active: > Old: You can define two types of Cats: pedigree or moggy.
(Actually, I would probably say: Cats can be defined as either "pedigree"
or "moggy". Assuming I've correctly interpreted meaning.)
But--I also think the use of the word "topologies" gives you a clue as to
the mindset and personal style of your co-worker. Assuming that the word
really should be "typologies", this is merely a high-falutin' way of saying
"types". There's really no reason for it. But we all know writers who
prefer the long and obscure over the short and obvious. It's tough to
change their minds. Maybe the best you can do is emphasize that different
styles of writing are appropriate for different situations, and pull out a
stack of user guides. Be sure to acknowledge that his/her style is
acceptable in the right circumstances (even if you don't believe it).
(Note: did this person actually make any improvements in the manual? Add
new info, fix incorrect info, clear up confusing passages? Or did this
person not have a clue about what to do, and fixate on something they could
keep busy on? If so, you've got bigger problems.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17) http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by ForeFront, Inc., maker of ForeHelp Help authoring tools
for print, WinHelp, HTML Help, JavaHelp, and cross-platform InterHelp
See www.forehelp.com for more information and free evaluation downloads
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
