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: Screen Dump Question From:"Susan W. Gallagher" <sgallagher -at- EXPERSOFT -dot- COM> Date:Wed, 20 Jan 1999 15:16:19 -0800
At 04:37 PM 1/20/99 -0600, Lief Erickson wrote:
>...My boss would like a screen
>shot of nearly every window... Obviously this is overkill.
>
>At the same time our documentation is used as a pre-sales piece...
>potential customers want ... to see if our products
>solve their problems... without having to install the
>software... a lot of screen captures help them visualize what
>is accomplished using our products. Now, the reviewers at the pre-sales
>phase are people writing checks, not users, but the documentation is been
>written for users in mind...
If the budget allows, and if the software is complex enough, create
two separate pieces -- a user manual and a technical overview. The
technical overview can be the software-centric piece that touts the
system's capabilities and ease of use while the user manual can be
the task-oriented approach your end users need to answer their
questions and help them become productive. Not that users won't
be glad for the technical overview too. It will provide them with
a good overview of the system's capabilities and accomodate a
different learning style than the user manual does.
If you can't do that, think about creating modular documentation --
docs where each two-page spread is a separate topic, like the old
Mac docs. (The definitive reference work for this technique is
_How to Write Usable User Documentation_ by Edmond H. Weiss, Oryx
Press, 1991, ISBN 0-89774-639-2). You can design a spread that
always displays a screen capture in the same place on every page,
where the eye can either search for it or ignore it, depending on
the user. If you've never tried to create a doc like this, the
discipline it imposes is an invaluable exercise.
If neither solution suits you, your best alternative would be to
remove the screen capture from the procedural section of each
topic so that it does not interrupt the procedural flow or the
user's train of thought. Perhaps you could introduce each section
with an overview and a screen capture.
There is probably just as much research supporting the use of
screen captures in manuals as there is research that renounces
the practice. A friend of mine who has worked as a trainer for
a long long time says she never uses screen captures anymore
because they distract her students -- she finds them looking
at the screen in the book rather than at the screen on the
computer and there they go, gleefully pressing key after key
only to discover that a mistake they made five minutes ago has
led them to a totally different part of the system.
The real questions we need to answer when we think about including
screen captures are: 1) does the graphic make a significant
contribution to the text? and 2) is the graphic placed so that it
does not interrupt the flow of the idea/description/task. If you
can answer "yes" to both questions, go with the graphic; if not...
Well, you know. ;-)
