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.
> In our design documents, we've called them "sticky fields," since the data
> stays sort of "stuck" inside... but I can't use this term in the Help.
It's
> too cute.
>
> I'd certainly like to know the actual term for this, but I'm more
interested
> in a any friendlier names you may have called such a thing,
Unfortunately,
> the best I've come up with so far, as far as official terminology goes, is
> "persistent attributes." That's just too ugly.
Why do you have to name them at all? In field descriptions, just say
"Defaults to XYZ." In procedures, just say "If X, leave the Foobar field set
to XYZ. Otherwise, change it to ABC."
Humans seem to have an innate need to name things, and it manifests itself
on this list from time to time. What's the narrow area between two panes of
a window? (stile) What do you call the resizing triangle at the bottom right
of the window? (grip) Is this a drop-down list, popup list, or... (who
cares?)
In interface design documents, such terminology is appropriate because the
readers of such documents are focused on creating and manipulating these
objects (or evaluating that task).
But _users_ of the interface don't care or need to know what every object in
the interface is called; their focus is on the task they're performing. In
most cases, you're just adding unnecessarily to their cognitive burden.
Before you name an interface object, ask yourself if knowing the name helps
readers with their task. I find that the answer is rarely yes.
"Less is more."
Richard
------
Richard G. Combs
Senior Technical Writer
Voyant Technologies, Inc.
richardDOTcombs AT voyanttechDOTcom
303-223-5111
------
rgcombs AT freeDASHmarketDOTnet
303-777-0436
------
---
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 http://www.raycomm.com/techwhirl/ for more resources and info.