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.
I think the following from Lauren is awesome:
=============================
The active example leaves no room for how to light up a room, while the
passive voice alludes to what lights up the room and the reader is left
to figure out how to do it. What is hidden in the two contexts and why
passive voice is better for argument, is that in the active voice, the
reader is being told what to do while the passive voice empowers the
reader to find a logical solution. The logical solution for darkness is
hidden within the context, since there really is only one way available
in the context to light up the room and the reader is permitted some
satisfaction for having found this one way, but there really was no
other option. This is similar to how political ads sway voters to make
stupid decisions...
=============================
When talking about software documentation, the software is a finite state machine. When transitioning from one state to another, there is no question about who or what is the agent of that transition. The same is probably true of complex hydraulic systems (boilers, chemical plants, etc.), airplanes, radiography equipment, and so on. Or if there is a question, the transition is an error state. In that case, why should you leave any open questions when describing a transition? How does that speed the user along to a productive or safe experience?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
