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: Including Screen Captures From:Steven Jong <SteveJong -at- AOL -dot- COM> Date:Fri, 24 May 1996 12:33:43 -0400
Bill Hartzer <XBJH%mimi -at- MAGIC -dot- ITG -dot- TI -dot- COM>
asks if it's reasonable to document a GUI product without
screen captures. I say: Like, the Sixties are over, man!
Okay, perhaps I'm being overly reactive here. It is a matter of
degree; certainly any device, including screen captures,
can be overused. Also, it depends on
what kind of information and audience you're talking about.
If the focus of the information isn't on screen interactions,
perhaps screen captures aren't important. For example,
a programming language reference needn't be highly graphical.
An audience unable or unwilling to sit at a screen and compare
the document with the actual software might not need screen
captures. But if you're talking about an end-user document,
especially a task-based document, and certainly for an
inexperienced audience that needs reassurance and positive
verification of each step of a task, I think the idea of
eliminating screen captures altogether is terrible.
Have you done a competitive analysis? I confess I am not
familiar with the documentation for Windows NT and OS/2.
Does your competition use screen captures? Do other documents
for those platforms typically include screen shots?
Certainly, in the Windows, Macintosh, and VMS markets,
with which I am familiar, GUI applications are *liberally*
illustrated with screen captures, and that style of document
is fully expected.
As for the "theory" you presented, it has four arguments,
which I summarize as follows:
1) The reader won't need screen captures because it's hard
work putting them in.
2) Also, the reader won't need screen captures because it's
*really* hard work putting them in.
3) We can do better than including screen captures.
4) If we substitute words for graphics, the book will be
shorter.
The first two are the same, and flawed. Audience need is one
aspect of the question, development effort is the other.
Combine them and you have a cost-benefit analysis; but
decide on the basis of either element and you're foolish.
Yes, doing screen shots is work, sometimes hard work. But our
job as technical communicators is to *do* the hard work, so that
our readers *do not* have to do it themselves.
The third argument needs some demonstration before I'll buy it.
Can you (or your manager) cite an example of a document without
screen captures that effectively documents a GUI product?
I can't.
Last, under the aphorism that a picture's worth 1,000 words,
how much "shorter" do you think the documents will be if you
have to explain GUI transactions using text only (I'm sure you
won't be able to use flow diagrams)? Based on my experience,
you could well end up with a *longer* document.
-- Steve
=================================================
Steven Jong, Documentation Group Leader ("Typo? What tpyo?")
Lightbridge, Inc, 281 Winter St., Waltham, MA 02154 USA
<jong -at- lightbridge -dot- com>, 617.672.4902 [voice], 617.890.2681 [FAX]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net
