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: Documenting enabled/disabled items From:"Jeanne A. E. DeVoto" <jaed -at- jaedworks -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 13 Dec 1999 22:25:44 -0800
At 9:12 AM -0800 12/13/99, Christina Tolliver wrote:
>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?
Does the user need to know which fields are enabled and disabled in order
to do the task? If so, it needs to be documented...but if not, it's a
distraction at best. The user will need to figure out what this information
implies, will try to keep it in mind in case it's needed later, and may be
confused about *why* the information is presented here.
Remember that users generally read procedures to get the task done, not to
learn about how the program works for its own sake. In this type of
documentation, the less cognitive load you dump on the user the better.
(For what it's worth, I agree with the people who've said this sounds like
a user-interface issue that needs to be brought up with the developers. It
*ought* to be visually obvious whether a field is editable or not. But
that's a separate issue.)
