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.
>- Go through the definitions and tasks windows by giving a simple background
>and then a "How to..?" approach to explain the usage of each field.
IMHO, you are mixing up to approaches that each have their merits:
1) Explaining each interface object (e.g., field in an entry mask,
button, menu comamnd).
2) Explaining how to perform common tasks with the software. (Which may
well involve several unrelated elements, e.g., two menu commands.)
Mixing up the two may take away the advantages of each: Because you
choose the narrative "how to" approach, the document is difficult to use
as a reference. Because you limit task explanations to a single group of
interface elements (e.g., a data entry mask), the task may not be
described fully.
My favorite appraoch to software manuals is to have two parts:
One task oriented one where I describe all the tasks that a user may want
to perform with the software, irrespective of the interface elements
associated with the task. This answer user questions of the "How can I
..?" kind.
The other section is the reference, where each and every interface
element is listed in a suitable order and described. This answers "What
does ... do?" questions.
This seems to be similar to a combination of your original suggestion and
that of your boss.
As to Tom's comment ("Do what the boss wants."): Yes, in the end the
decision is his, and given your lack of experience, it is inadvisable to
put up a fight. (After all, he _may_ actually know better than you.) On
the other hand, engaging in a constructive discussion, comparing goals
and ways to reach them, is not picking a fight, and I encourage you to
present your reasons for doing what you want and try to reach a mutually
agreeable solution.
Hope this helps
Jan Henning
--------------------------------------------------------------------
Jan Henning
ROSEMANN & LAURIDSEN GMBH
Am Schlossberg 14, D-82547 Eurasburg, Germany
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now's a great time to buy RoboHelp! You'll get SnagIt screen capture
software and a $200 onsite training voucher FREE when you buy RoboHelp
Office or RoboHelp Enterprise. Hurry, this offer expires February 28, 2002. www.ehelp.com/techwr
---
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.