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: 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.
[SNIP...]
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.
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-
