Re: Click X, or click the X button?

Subject: Re: Click X, or click the X button?
From: Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Tue, 27 Oct 2009 04:53:00 -0700 (PDT)

No argument here, Janice. Just more reason to cut the cr*p and make sure the documentation is worth reading. If users trust you to provide meaningful content that doesn't waste their time, you limit the urge to skim. And if you organize the presentation so they can categorize what's on the page and get to it immediately, so much the better. That's not skimming, it's ordering the content. I'm specifically thinking about presenting dialog box options as tables or lists, with option name followed by effect. You can think of a dialog box as a command in a programming language -- the options are arguments where control type takes the role of arg data type or command flag. Why does a dialog box need more than:
* Synopsis (including gotchas, tips, and warnings)
* Result (analogous to function return val, or output)
* Inputs
* Error states (usually unnecessary because alerts self-document errors)

Then a "task" becomes something like...
To configure your frazbot, set the following dialog boxes in the following order:
* <link>Hinkey</link> dialog, to specify which hinkies will run during frazbot initialization
* <link>Dinky</link> dialog, to assign the persistent hinky to the frazbot dinky state
* etc.

The *level* of task orientation jumps to a different electron orbit (releasing photons? light bulbs turning on?), and people can model how they approach the software as a whole, not how they approach a morass of individual tasks centered around which dialog box controls to modify.

If you have dialogs that serve multiple purposes (quite likely), then your "task step" expands to describe how to use the dialog for that special situation. But I maintain that keeping the task at a higher level makes it easier to distinguish when and how to use the same dialog for different results.

I'm not saying that readers aren't going to skim
anyway, just that I don't think that calling out
GUI items to encourage them to do so is a good idea.
I'd prefer not to lead them astray by implying that
they can just merrily click items and press buttons
without reading any explanatory information - sometimes
such behavior causes inescapable consequences so going
back to the docs afterward to find out what they did
is not always a solution.

-- Janice


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.

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!

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Please move off-topic discussions to the Chat list, at:


Previous by Author: RE: Framemaker Conditionalising Templates
Next by Author: Re: Click X, or click the X button?
Previous by Thread: Re: Click X, or click the X button?
Next by Thread: Re: Click X, or click the X button?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads