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: Conditional statements in instructions From:Barb Philbrick <caslonsvcs -at- IBM -dot- NET> Date:Tue, 26 May 1998 13:21:54 GMT
On Mon, 18 May 1998 12:35:43 -0400, you wrote:
> I don't think that conditional statements should precede the
>imperative verb. (When done, press return.)
> As a rule, I try to put the condition as a "desired result" of the
>previous imperative. Example:
> (step #). Press Alt + 4.
> (some visual, like an arrow) You are done.
At one of the STC conference sessions, the presenter reported that,
based on his observations at many usability tests, people read the
first three words of a step and only four steps in a procedure.
He gave an example of "1. Install the _Modem Installation_ disk." His
users read, "1. Install the modem." They installed the modem, then
didn't understand why the modem didn't work -- they had followed the
instructions.
Based on this. I would place important information -- "to prevent
electric shock," "to prevent losing data" --- before the imperative,
in hopes that the potential danger will prompt the reader to continue.
For safe steps such as those you list, I think you're right -- tell
the users what to do; the curious can read on if they want. I'm not
sure about the advantage of consistency here. I would lean toward
consistency within these two types of steps: the "warning step" and
the "safe step."
The other food for thought (and revamped procedures) I got from this
session was that people read manuals when they become stuck and only
stay in them until they become unstuck. It was a good reminder that
people are likely to come into procedures at the wrong place, so give
frequent "signposts" in the procedure to tell the user where he or she
is at. In addition, they are likely to start at step 1, even if
they've successfully completed the first few steps, so make sure
toggles won't be reset to something harmful.
Regards,
Barb
Barbara Philbrick, Caslon Services Inc.
Technical Writing. caslonsvcs -at- ibm -dot- net
Cleveland, OH