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.
#. (User action: From the Edit menu, choose Line Name.) The Line
Name box appears.
#. Select the seismic line you want to edit, then press ENTER.
(Part of this step may have to describe how the selection process
takes place in the user's environment.) The seismic line
is highlighted, and the Edit screen appears.
I think this one-action-one-result works well for procedures. Any
thoughts? Have I opened up a major can o' worms?
No can of worms here! That's exactly what I do. In fact, part of my editing
process is to check my procedures and make sure I'm not lumping more than one
step together. Although it may seem "retentive", it is in fact much easier for
a user to scan, even if it takes up space. Even with the extra length, I
think it looks less intimidating, too. Experienced users (experienced both in
the software and your document style) will know what to expect, and just skip
over the steps they know are next, for example:
1. Select junk from the closet menu. The junk dialog box will appear.
2. Select the junk you wish to discard from the selection list...
The experienced user won't bother to read Step 2, and the novice/first-timer
will not have the "selection list" information, which describes the complex
object he's looking at on screen, buried in a dense-looking and perhaps
complicated-looking procedural paragraph.
And, although it's no longer a thread, I _like_ the word "appears". It
completely fulfills the user-centred approach all documentation should have,
not the program-description-centred stuff developers love to write!
Finally, anyone have any opinion on "want" vs "wish"? I just re-read my posting
before SENDING (looking for sp's, typos and....Netiquette faux pas...) and
noticed that Chuck says "want", I say "wish". I spent the last two weeks
editing developers' functional specifications, and changed all the "wants" to
"wishes". Now I wonder why.
Gwen (To "want" is too assertive, I can only "wish"?) Gall
(ggall -at- ca -dot- oracle -dot- com)