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: The user guide prescribes the program From:"Marlene J. Geary" <marlene -at- NECA -dot- COM> Date:Mon, 6 Jan 1997 21:58:39 -0500
Elna Tymes from Los Trancos Systems wrote:
>As it is, most of us run around chasing programmers and system
>designers, or playing with opaque interfaces, trying to figure out what
>the program is supposed to do and writing up-beat verbal patch-arounds
>when the program is rough or not working right.
I almost think chasing programmers to give you information is a rule of
nature. But, quite often, our development team comes to our technical
writing group for input. We help them design the wording of prompts, come
up with new command-word choices, give user-interface screen comments, etc.
My company figures that an engineer shouldn't spend an hour coming up with
the wording for a prompt when the doc group could reword the prompt in a few
minutes. If the two work together for that few minutes, that's a lot of
dollars saved.
We don't actually design screens. However, if the engineer wants to offer
something to the end-user on the screen and can't quite figure out how in
terms of interface or display or text, we're consulted for help.
We're also charged with keeping an eagle eye on the prompt user interface
created by developers. Often a developer will sit in their own world,
forgetting about (1) prompt and command standards and (2) the end-user. As
a part of documenting the product, we have to examine everything. If a
question in the new feature doesn't jive with products developed in the
past, we notice and report back to the developer. If we read a text prompt
and it makes no sense, we'll let the developer know - before the product is
coded. Much easier that way.
Marlene
====================================================================
| Marlene J. Geary | I sing because my heart | Writer/Editor |
| "Mars" | demands it and would | DISC |
| marlene -at- neca -dot- com | break without it. | Farmington, CT |
====================================================================
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
