Re: Conditional statements in instructions

[DURL <durl -at- BUFFNET -dot- NET>]

        Thanks for a thoughtful reply. I've thought about this a lot since
I'm in the minority in a group whose collective opinion I respect. Two
ideas:
        1 - In the case you cite, my fear is that when people see those
cautionary statements, they skip over the whole step. With a caution on
*everything* including candleholders, who bothers to read them? Not a
rhetorical question...
        For that reason, I'd rather put the caution statement as a "Note"
(or marked visually somehow)
        I'm not (or at least I hope I'm not) being merely pigheaded about
consistent structure in procedure steps. I'm going on the assumption that,
in a manual, you want the reader to get the rhythm/feel of the info you
present, which is easier
 if you make the info subliminally self-evident. A number is
always followed by a "Do something" statement. A shaded box labeled "For
Your Safety" contains *meaningful* safety info; a plain box is my cue to
readers that this info is irrelevant but their mgmt wanted itin.
        2. I realized there are procedures and procedures. If I'm reading
an MS Word manual, where I want to learn info relating to other tasks as
well as to do the task at hand, I'll read it
differently than I will instructions on "Installing Your Answering
Machine."
        Thanks to you all,  I will loosen up on my conditional statement
stance in an
operations manual I'm working on now, where the users are educated and
experienced professionals learning the procedures in a particular company.
This is different from other manuals I've done, where we wanted the steps
simple and standardized in a union environment, partly to give mgmt a tool
for objectively  measuring performance.
        I wonder if anybody knows of any research that looks into the way
people read/use procedures, taking into account the following variables:
work environment; education level; general reading habits; kind of job
(office, lab, assembly)...
        Thanks again,
        Mary



Mary Durlak  Erie Documentation Inc.
East Aurora, New York (near Buffalo)
durl -at- buffnet -dot- net

On Tue, 26 May 1998, Barb Philbrick wrote:

> 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.
> =46or 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
>
>
>
>