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.
I have found there are several kinds of readers. Some get information out of
reading 6 well-written steps. And, others look at the screen capture with a
couple of callouts and say "yeah, that's it!" Certainly, a screen capture
that displays valid data helps somebody visually orient themselves to the
documentation as well as the program in front of them. Moreover, folks often
use written material to review a procedure before they do it, say in the
coffee room or the bathroom or wherever. Certainly, in such cases, the
reader does not always have the documented program in front of them.
Thus, I disagree that getting rid of screen caps from documentation is
prudent. I do agree that screen captures have considerably less worth in the
online help.
-----Original Message-----
From: TECHWR-L digest [mailto:techwr-l -at- lists -dot- raycomm -dot- com]
Subject: Why use screen shots at all? [WAS Survey: "Screen shots"]
From: John Cornellier <tw -at- cornellier -dot- com>
Date: Wed, 12 Dec 2001 11:46:36 +0100
X-Message-Number: 3
11-Dec-01 4:34:48 PM, KMcLauchlan -at- chrysalis-its -dot- com wrote:
>I got tired of bitmap issues related to screen-caps,
Why not get rid of the screen caps altogether?
I'm documenting software applications which treat data in a graphical way.
The only time we use screen captures is to help the user visualize what
something is *supposed* to look like. E.g. if your data looks like
this < picture > try applying the XYZ Filter after which it should look like
this < picture >. But we certainly do not supply a picture of dialogs, e.g.
for standard data selection, etc. What's the point?
In online doc, most screen captures are a total waste of space.
In most printed doc I've seen the screen caps are just fluff, padding. E.g.
to print, choose File > Print. The print dialog appears. < picture of Print
dialog >. If the user is sitting at the computer and the dialogue has
a title, then he or she doesn't need the screen shot. If he or she is on the
train, there may be some slight benefit to seeing the dialog though I doubt
it. Anyway whatever benefit there might be is outweighed by
the cost:
- printing costs which are passed on to the customer
- production complications (color, resizing, moor(?) effect in scroll
bars...) which makes the doc harder to maintain
- difficult to support cross platform
- gets out of date fast (one tiny thing changes on the dialog, you have to
redo the whole image)
- makes book bulkier, harder to carry, read.
- takes up pixels and is redundant in most cases, since the dialog is
displayed on screen anyway.
In short, my opinoin is that most screen caps are really there for aesthetic
and marketing reasons. "Make the book look thick ... don't scare the reader
with too much grey text ..." But I doubt that serious usability
testing would show that screen caps in the doc improve the user's
productivity. Or not?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of
your book. What are you waiting for? http://www.iuniverse.com/media/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.