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.
Documenting Floating windows - how would you do it?
Subject:Documenting Floating windows - how would you do it? From:"Peter Ring, PRC" <prc -at- PIP -dot- DKNET -dot- DK> Date:Fri, 23 May 1997 10:23:40 +1
On 22 May 1997 Carla Lotito asked:
> I'm documenting a product which has floating windows (windows that can be
> accessed from several points in the software).
>
> The documentation is by module in the software and includes field
> descriptions. However, window X can be accessed from module A, B and C.
>
> Different users may use each module but it is possible that the same user
> use all modules. The documentation will be delivered as a whole, not by module.
>
> Where would you document the description of window X?
>
> * In module A and then provide a cross-reference from B and C?
>
> * Would you repeat the exact description in each module?(this may increase
> translation costs)
>
> * Or, would you make a new chapter called Floating windows at the end of the
> book (where it may not be seen by a user) in an appendix and just mention
> the existence of these windows and refer users to the appendix in each
> module for more information?
To my experience, this works:
Start with a "How to get started" chapter/volume. If the software is
complicated, make a "Learning to use X" chapter or volume teaching how
to handle a suitable number of typical situations with examples and
exercises. Give references to the reference chapter/volume (see
below) to make the reader used to use it.
Put the complete documentation of ALL windows in a "reference"
chapter/volume, including purpose, all input rules, expected results,
handling of problems specific for this window, cross references to
linked windows, and references to where it is handled in the "How to
get started" and/or "Learning to use X" chapter(s)/volume(s). If
suitable include some typical examples here, too.
Make sure there is a good index!
If the product is simple and you prefer to keep the mixed purpose
manual structure, don't be afraid of the repetitions for a
translating cost viewpoint, but tell the translator which sections
are identical. If your word processor permits it, insert the
repetitions as a full text bookmark reference, and let the translator
work from the file version of the documentation (most translators
prefers that anyway).
Greetings from Denmark
Peter Ring
PRC (Peter Ring Consultants)
- specialists in user friendly manuals and audits on manuals.
prc -at- pip -dot- dknet -dot- dk http://www.pip.dknet.dk/~pip323/index.html
- the "User Friendly Manuals" website with links, bibliography, list
of prof. associations, and tips for technical writers.
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
