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.
Sunshine QT asks:
> To what extent is it your decision as the tech
> writer/tech writing department how to lay out manuals,
> and to what extent is it the programmers' decision?
Although the tech writer/department, hopefully, has a better general idea of
how to lay out manuals, there can be cases where a programmer or other
non-writer should have input.
(1) Who knows the intended audience better? For example, if you are writing
API docs (i.e., for other programmers), perhaps the programmer has a better
idea as to what the audience will expect and can give you feedback on what
works for him (as a representative programmer).
(2) Sometimes the tech writer/department comes up with a general standard
that is not appropriate for all documents. For example, Sunshine mentioned
the programmer objected to Sideheads. If the document in question has long
headers, and the headers are limited to the sidehead area (instead of
running across the sidehead and column of body text), it can be harder to
read and waste lots of space. Or perhaps the document has lots of
information that would best fit across the entire width of the page (e.g.
complex graphics that are difficult to read when shrunk to fit the column of
text, tables that would benefit from wider columns, long equations, etc.).
You might find a compromise that works - for example, instead of large
sideheads, having slightly outdented headings (stick out from the left edge
but allow enough horizontal space for the required information).
(3) I am not accusing Sunshine of this, but sometimes a tech writer learns
(or invents) a new design technique and decides that this is THE answer to
document design and tries to apply it everywhere, and not necessarily in the
most appropriate manner. In this case, anyone not afraid of offending said
writer might question this approach.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17) http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by ForeFront, Inc., maker of ForeHelp Help authoring tools
for print, WinHelp, HTML Help, JavaHelp, and cross-platform InterHelp
See www.forehelp.com for more information and free evaluation downloads
---
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.
