Documenting visible/invisible fields?

Subject: Documenting visible/invisible fields?
From: "Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 21 Feb 2002 16:02:21 -0500

Rowena Hart wonders: <<I'm trying to think of a good way to document fields
that are visible or invisible, depending on the options
the user selects. For example: If the user selects Deal A, fields that are
specific to that type of deal are displayed. If the user selects
Deal B, fields that are specific to that type of deal are displayed. Some
fields may be common to both Deal A and Deal B, while other fields are
unique. In the reference manual that I have inherited, every field is listed
and described in detail. Given the changeable
nature of the interface, how would you document the fields? This is just a
reference manual -- there are no procedures, just table after table of field
descriptions and technical background info.>>

Given that this is a reference manual rather than procedural instructions,
you should list the invisible fields the same way you list the visible ones
(e.g., alphabetical, by dialog box, whatever). There are two main situations
you're designing for, and documenting the field so it's easy to understand
is equally important in both cases:

1. The reader isn't going to look up a field they can't see, but when they
do see it, they need to know what it does.
2. Somebody remembers a field name, but doesn't know where to find the field
and how to make it visible.

The latter case suggests that you should strongly consider adding a note to
the text for all (in)visible fields to indicate when they're invisible and
how to make them visible again.

<<I guess I'm trying to get suggestions about the best way to present the
fields to users, based on the user's own experience
with the fields.>>

Use my two situations (above) as a starting point. Whatever access method
you choose, you need to help users find the information. For example, the
first situation suggests that organisation based on each individual dialog
box would be suitable; the latter suggests that an alphabetical order would
be suitable. One simple way to reconcile the two approaches would be to
present the main information organized and grouped by dialog box, but
include an alphabetical index to field names so readers know which dialog
box to look under.

One thing you didn't clarify is whether the fields are truly invisible (not
even a close scrutiny would reveal their presence) or merely greyed out to
indicate they're not available for the current selection. My personal
preference as a user is the latter approach; knowing that the fields are
present leads me to infer that if I need to enter that information, I must
look for some setting that makes those fields available. I consider this
kind of approach good design; ymmv.

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at

"Any sufficiently advanced technology is indistinguishable from a
personality, and an obnoxious one at that."-Kim Roper

Did you know you can get RoboHelp certified?
To learn how, visit Be sure to also check out
our special pricing offers and promotions for RoboHelp 2002.

Have you looked at the new content on TECHWR-L lately?
See and check it out.

You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit for more resources and info.

Previous by Author: STC consulting and independant contracting SIG: contact informati on?
Next by Author: Questions about Doc to Help and RoboHelp?
Previous by Thread: RE: Documenting visible/invisible fields?
Next by Thread: RE: Documenting visible/invisible fields?

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

Sponsored Ads

Sponsored Ads