Re: A reminder: visual and other indexes

Subject: Re: A reminder: visual and other indexes
From: Stuart Burnfield <slb -at- westnet -dot- com -dot- au>
To: Techwr-l <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Mon, 11 May 2009 13:46:07 +0800 (WST)

Here's a step in the right direction:

Robert, I don't think Geoff is arguing for more screenshots of menus. I guess he's talking about this sort of thing:
- an icon or control that can't be identified until you hover over it and which may not have an obvious menu equivalent
- an option that's buried several clicks deep in a series of menus, dialog boxes and tabs
- a feature that you accidentally hide or move, and there's no obvious way to "put it back the way it was"

Some examples would be:
- the middle-click scroll feature in Firefox, Word, etc.
- the Hide White Space feature in Word (click between pages in Print Layout View)
- dragging or hiding views in Eclipse (very easy to do by accident)
- the Resize control in the Word vertical scroll bar (which only has a tooltip once it's already been used!)
- the Ctrl Alt Hyphen feature in Word, which I regularly switch on by mistake when trying to insert an em dash

Some things that would help users to learn about and deal with these features:
- A visual index of controls and pointer icons, as Geoff suggests
- A heavily annotated master screen shot giving labels to unnamed controls
- A way to look up keyboard shortcuts (you use the right shortcut in the wrong application--the screen flickers and you think, oh dear, what did I just do...?)


"I thought logorrhoea was an affliction of lumberjacks,
till I discovered";

Robert Lauriston wrote:
> Yeah, it's very annoying when docs don't tell you how to navigate to
> the command / dialog being discussed, but screenshots of menus just
> clutter up the doc and waste the writer's time.
> My negative attitude about that sort of thing was probably exacerbated
> by having inherited so many docs that contained nothing but a useless
> narrative of the UI.
>> The second is that most documentation provides no way to
>> look up things you can see on the screen. I've occasionally had
>> problems with Adobe documentation, for example, because
>> they'll write something like "to fram statically, use the
>> framistat tool" without showing me what that tool looks like
>> or where it's hidden.

ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals.

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: Amazing what you can do with paper prototypes
Next by Author: Re: Bug tracking and documentation
Previous by Thread: Re: A reminder: visual and other indexes
Next by Thread: Acrobat 9.0 Professional text edits a no-go

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

Sponsored Ads