RE: a question about writing instructions

[Alan Bucher <bucherino -at- yahoo -dot- com>]

Dick Margulis wrote:
> I'm mystified by your comment. I avoided saying anything about
> "field" vs. "text box" (other than rising to Kim's doggerel
> challenge) because I could not then imagine, nor can I now imagine,
> how choosing one over the other has any bearing on readability,
> usability, comprehensibility, or any other attribute of user
> documentation, as long as you pick one term and stick with it.

I agree that in the isoloation of your doc and your users, if you use
a term, the user understands that term, and you use that term
consistently, then you should have no *ility problems at all. The
issue is which term you should pick, and how that term fits into the
universe of other applications in which the user lives.

> I can see nothing inherent in the
> phrase "text box" that makes it clearer or more intuitive than
> "field."

Imagine showing new computer users a dialog containing various UI
objects. Ask some to point to the "field". Ask others to point to the
"text box". I haven't done this study, but my gut tells me that most
of the "text box" people will get it right, and most of the "field"
people won't. Because when you actually see the thing on the screen,
it looks like a box with text in it. But there's no general usage of
the word "field" that should make it easy for a new user to relate it
to that particular UI object. This to me is the definition of "more
intuitive". Though without an actual study, I suppose we can disagree
on the expected outcome.

> If the reader truly does not understand what is meant by
> whichever of those expressions is used, then the reader needs to
> look up the term in a glossary or "how to use this book" intro or
> some other such reference section (diagrams with callouts are good
> for this sort of thing).

By this reasoning, I could start calling them "t-nodes" or something.
The goal of clear doc is to use language that doesn't require the
user to go looking up things all the time. Yes, they *can* look up
things that they don't know, and sometimes must. But as
communicators, we're supposed to minimize such things.
 
> But for some _authority_ to pronounce a word as clear and
> inoffensive as _field_ to be unacceptable when explaining how to
> complete a form ... well, as I said, I'm just mystified.

I didn't say there was an "authority". I said there's a convention
that's used by most applications in the world. And "field" is clear
and inoffensive to you, as a seasoned industry worker. It's less
clear to the new user.

> Can you summarize the argument against "field" and in favor of
> "text box" for me, please?

You use "field" (as did I) because everybody once did. It was the de
facto standard. In fact, all UI widgets were once generically called
fields. Then they said, "'field' isn't very descriptive, and in
addition we need to give them unique names so we can start designing
APIs for them." So someone came up with "text box". I don't know who,
but now most people have adopted that. Microsoft does. Apple does. So
that means that most apps in the world use that terminology. And that
means that most users in the world use that terminology.

You may not like that terminology. And you may hate Microsoft. But
you can't escape that the terminology is in wide use. I don't
especially think it's the best term, but I can't think of anything
better. And even if I did... I recognize that my users are using
Office and other apps all day and are seeing that terminology used
most often. As a communicator, it's my job to make things easier for
them.

I could call them "fields" or "t-nodes" or "text entries" or whatever
else inflated my ego or my homage to history. But stubbornness
doesn't help my users.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
Buy or upgrade to RoboHelp X3 today and receive the WebHelp
Merge Module for FREE ($299 value). RoboHelp X3's all-new
features include conditional text, completely re-engineered
printed documentation output, Context-sensitive Help Toolkit,
single-source layouts, and more!
Order online today at http://www.ehelp.com/techwr-l


---
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.