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.
On 12/13/99 12:12 PM, Christina Tolliver (christina_tolliver -at- hotmail -dot- com)
wrote:
>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
fields.
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
uses
the values you entered in the New Year's Eve Party Preferences dialog
box.
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.
