Re: Documenting enabled/disabled items

Subject: Re: Documenting enabled/disabled items
From: Mike Stockman <stockman -at- jagunet -dot- com>
To: "Christina Tolliver" <christina_tolliver -at- hotmail -dot- com>, "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Mon, 13 Dec 1999 19:54:20 -0500

On 12/13/99 12:12 PM, Christina Tolliver (christina_tolliver -at- hotmail -dot- com)

>If this kind of information is helpful to users, it's worth the maintenance
>effort for us writers to keep up with what fields are enabled when. But if
>this is just a case of stating the obvious, maybe it's not worth our effort.

Any time you feel that you're stating the obvious in a manual, look for
value to add to that obvious information. "Why" is the most often omitted
piece of information you can provide to users about enabled/disabled

Whether the field is editable, or whether a control is enabled, should be
clear from the interface. The statement "The Calling Feature box is not
enabled" prompts the user to ask "Why not, and how can I enable it to
change the setting I want to change?"

Try this:

2 Click the Add Party Stuff button.
The Host, Switch, and Equipment boxes are disabled because this form
the values you entered in the New Year's Eve Party Preferences dialog
Choose Preferences from the Edit menu to change these defaults before
adding a New Year's Eve party.

As you say, if it's stating the obvious, it's not worth the effort. Your
best option, then, is to find out the part that's *not* obvious, and make
sure you tell that to the user.

Hope this helps,

Internet: stockman -at- jagunet -dot- com AOL: MStockman
AOL Instant Messenger: MStockman

Previous by Author: Documentation on Solaris
Next by Author: RE: Tracking off
Previous by Thread: RE: Documenting enabled/disabled items
Next by Thread: Re: Documenting enabled/disabled items

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

Sponsored Ads