Documenting enabled/disabled items

Subject: Documenting enabled/disabled items
From: "Christina Tolliver" <christina_tolliver -at- hotmail -dot- com>
To: TECHWR-L -at- LISTS -dot- RAYCOMM -dot- COM
Date: Mon, 13 Dec 1999 12:12:32 EST

Techwr-lers,

After procedure steps, do you document which fields are enabled and which are disabled? What are the advantages and disadvantages of doing so, or not?

My question pertains particularly to software that is not consistent in appearance or behavior. In my company's software, fields with a white background are not always editable, and fields with a gray background are not always read-only. The current user documentation indicates when fields become disabled or enabled. Here's an example.

2 Click the Add button.
The non-editable fields are disabled.
The editable fields are enabled.

Whether or not you would _word_ things this way, do you think such a statement helps users? (Our users are familiar with Windows but are not computer whizzes.) Would this example be more helpful if the specific field names were listed? Then, the example might read this way.

2 Click the Add button.
The Host, Switch, and Equipment boxes are disabled.
The Calling Feature box is enabled.

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.

What do you think?

Christina Tolliver

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com




Previous by Author: Re: to be versus ing
Next by Author: RE: Is there an "official" term for this process?
Previous by Thread: RE: techwr-l digest: December 09, 1999
Next by Thread: RE: Documenting enabled/disabled items


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

Sponsored Ads


Sponsored Ads