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: Use of Optional in instructions From:Lauren <lauren -at- writeco -dot- net> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Tue, 15 Sep 2009 00:18:27 -0700
Boudreaux, Madelyn (GE Healthcare, consultant) wrote:
> Richard Combs wrote:
>> RIGHT: "To accomplish X, do A."
>>
Ewww...
>> WRONG: "Do A to accomplish X."
>>
I would not write an instruction like this either, but it gets rid of
the non-committal sound of the "right" option. The instruction for
accomplishing X should already be in a section for accomplishing X, so
there should not be a need to soften the fact that an action will
accomplish X. So in the section for accomplishing X the instruction
should be, "Do A."
> Interesting. I've always preferred the other route, on the grounds that
> Richard's method buries the lede.
>
I agree with Madelyn here, although, I have never thought of technical
writing as having a lede, although I guess it is nice to think of
enticing readers while writing.
> Can you give me insight on why you do it your way, or, if you prefer,
> why my reasoning is wrong?
>
> Oh, and to return to the original question, how about:
> I like using a repeated, semi-visual cue, like adding [Optional] at the
> beginning of those steps, because it adds to scanability -- the user can
> quickly pick out the required and optional steps, without wasting much
> thought.
As a writer, I find parenthetical or bracketed terms, like "[Optional]"
to be a bit awkward, but as a reader, I find them very helpful. I like
scanning documents for necessary information and I think that signposts
such as this are helpful. When I want the important stuff, I do not
want to spend time reading optional pieces that I may not need. I
certainly do not read a section and then find out later that it is only
optional.
Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices. http://www.doctohelp.com/SuperPages/Webcasts/
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-