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.
Cayenne Woods asked about optimizing screen shots,
and said in summarizing that
> [Using] sections of the screen, or full-size once then sections
> (doesn't work 'cos each screen's only described once, doesn't make sense to
> break it down at this point)
First, I'm going to ask some tough questions about the
purpose of screen shots. Then, as a reward for staying
with me, I'll share some tips for getting good results with
screen captures.
Whenever a tech writer asks me for advice
about "describing screens", I ask WHY they think it
necessary or desirable to "describe screens". I even
do it when they don't ask for advice (hee-hee).
Since most end-user documentation exists NOT to
"describe screens" but to give the user instructions for
getting work done, a little rational analysis may reveal that
most of your screen shots are unnecessary.
In much of the bad user documentation that I have
had to throw away and/or re-write, gratuitous screen shots
had been used as a no-brainer substitute for the hard work
of writing usable instructions. I think this may be for one or
more of the following reasons:
1) Programmers like to see screen shots. Who knows,
maybe they take them home and show them to Mom.
2) Junior tech-writers find it an easy way to fill up pages
while offering visible proof to their employer (usually a former
programmer) that they've actually worked out how to
install and run the application.
Take your pick. But we're not working to coddle programmers'
egos. Our job (usually) is to tell users how to get their work
done. Showing them pictures of things they can already
see is just blowing smoke, and they know it, even if our
employers don't. (Mine do, because I've explained it to them.
Sorry.)
I tell Help authors and user-guide writers to use screen
shots only when they have a specific instructional purpose
in mind--a purpose that is clearly stated in the caption or
lead-in. One of following purposes, for example.
1. To point out the location of something.
In complex and poorly-designed systems (especially of the
non-GUI persuasion) it is sometimes desirable to point to the
location of a particular field because it takes too many words
to point to it textually. A full-screen capture is rarely optimal for
this purpose. A small portion of the screen, with one vertical and
one horizontal window border partially showing, is enough for
the user to identify the visual coordinates of the subject area.
Sometimes even a simple line-drawing rather than a screen
capture will work best.
2. To show a comparison between two things.
Sometimes you can make an instruction clearer by showing
two similar things (command strings, for example) and pointing
to the significant difference between them. A full-screen
is rarely optimal for this purpose.
3. To show a sequence of actions or events.
Sometimes you can make an instruction clearer by showing
a 'before & after' comparison between two screens or dialogs.
This is handy when a user performs an action in one location
and then views the effect of the action in another location. A
full-screen capture is rarely optimal for this purpose.
4. To point to an area where something important happens.
In high-level and introductory topics, it is often helpful to show
a complex window -- for example a main application window --
with callouts pointing to its most significant features and areas
of activity.
Note that in three of four cases, it is desirable to show only a
particular area or object--not a whole "screen". In ALL cases,
the focus is on particular objects, not on the whole "screen".
One of the questions asked in this thread was something
about how to avoid losing detail in whole-screen captures.
No-one pointed out (until now) that often, losing detail is a
GOOD THING. Professional illustrators often blur and mask
the irrelevant details of a complex picture in order to focus the
viewer's attention on the significant bit. So should we.
While I can't think of many good reasons for reproducing whole
"screens", I CAN think of plenty of reasons why is a bad idea.
Think of it this way. The user hasn't come to the Help or the user
guide to find out what a screen "looks like." No, the user is there
because he or she wants to know HOW TO DO SOMETHING. So
the real challenge for tech-writers and Help authors is coming up
with an information design that gives a quick, clear, uncluttered
answer to that specific question that the user has in mind. This
is too hard for beginners, so what they give you instead is page
after page of dumb screen shots.
Techwhirlers, PLEASE take this advice to heart--
----------------------------------------------------------------
----------------------------------------------------------------
Your task isn't to describe the obvious, but to
make it useful.
----------------------------------------------------------------
----------------------------------------------------------------
And now some screen capture tips.
1. Whether to use WMFs or BMPs or something else depends on
final output format. When preparing for Word and PDF output, WMF
and Word's default graphics formats work fine. My Help authoring
tool of choice, though, prefers BMP.
2. Capture as close to final output size as possible. There are several
ways of compressing the visual area you want to capture, and some
have been mentioned in this thread.
* Try different screen resolutions. Higher resolutions
let you get more information in a smaller area.
* Try changing to smaller and more efficient screen
fonts to get more information in a smaller space.
* Re-size and re-shape the capture area to eliminate
empty space.
* Use cropping and masking tools to remove the
insignificant portions of the window. (Warning:
This requires you to make some hard decisions
about what is significant and what isn't.)
3. I get good results using Paint Shop Pro for screen captures. First, I
crop and (if absolutely necessary) resize, then I decrease color depth
to 256 and save to BMP format. After that, any resizing or rescaling
exacts a penalty. Making it smaller means you're asking the software
to show the same information with fewer bits. It can't.
--
Michael West
Technical Writer/Editor
Melbourne, Australia
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Take XML and Tech Writing courses online! Our instructor-led courses
(4-6 hrs/wk) give you "hands on" experience at your convenience. STC members
get 20% off! http://www.online-learning.com/index.html.
---
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.
