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 assume that all of them are applied only in a situation where the user is
doing something until he runs out of things to do, then needs to exit. If
any of these are used to replace the simple "Press the End button" at the
end of a predictable sequence, I'd get rid of all of them.
>1) When finished, press END.
>2) When done, press END.
These are functionally identical. It's a style judgment. You could go on to
add "When you're done doing things, press End" and so on.
>3) Press END when finished.
>4) Press END when done.
These are also functionally equivalent. Cue the style judge.
Actually, whenever possible I'd rather make this into a conditional:
7. Are you done doing stuff yet?
If Yes...press End.
If No...return to the top of this sequence.
This eliminates all the uncertainty and makes the whole problem academic. If
you can't do the step this way, then you have a problem, for sure.
In general, the user action should come first, especially if the instruction
is simple, clear, and requires little interpretation. The resulting system
response comes second:
Press the A key. The A screen appears.
If the action implies a decision by the user, then the user can be
momentarily baffled. The thorniest problem is when instructions are written
high-level, and the user has to interpret a lot. For example, this is a
high-level set:
1. Click on the appropriate choice.
2. Press the desired key.
To my mind, the problem with the stated four steps isn't whether the action
comes first or not, but that the user has to interpret the instruction as a
high-level parse. This creates the need to combine the instruction with the
result, which raises the problem of which comes first. If the instruction
set could be split into predictable steps, then the problem vanishes. The
command comes first, the result second. End of problem.
However, if the set must remain high-level for some reason, it introduces
the question of whether the implied conditional ("when done"..."when
finished"... implies a conditional branching) comes before the command. In a
strictly logical sense, it does. The user has to first make a decision, then
act. Therefore, logically options 1 and 2 are preferable. But I still have a
problem combining a decision and an action in a single step. I'd split 'em.
As to done versus finished, why not compromise on "When all tasks are
completed, press..."
>
>There's a raging debate here on my technical review team as to which is
>the correct construction. Some don't like "when done" as it makes them
>think we're baking a cake, others don't like "when finished" and are
>adamant that "when done" is perfectly acceptable. Some want the action
>to be taken at the front of the sentence, others want the time to take
>the action at the front of the sentence.
Tim Altom
Simply Written, Inc.
317.899.5882 http://www.simplywritten.com
Creators of the Clustar Method for task-based documentation
