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.
So far what most people seem to be telling me is that
I'm wasting time and effort. The premise, of course,
is that their screen caps are always razor sharp and
take no time at all to get that way, no matter how much
they may get resized.
My experience has been somewhat different. The screen-caps
I work with include some standard Windows install stuff,
some configuration dialogs in Windows and other operating
systems, some error message windows/boxes from any-and-all
of those systems, and some screens from other companies'
products, where our product integrates with theirs.
That means, they come in all sizes and shapes and ,
ninety-nine times out of a hundred, the window (error
message, dialog box, etc.) doesn't have any resizing
handles and so cannot be resized BEFORE the screen-cap
is taken.
I occasionally get lucky and (with a bitmap program)
tinker a screen-shot into a state where it looks clear
and clean in PDF on my 1600 x 1200 display, AND on my
neighbor's 800 x 600 display, AND on our in-house laser
printers (several kinds), AND when commercially printed
and bound. Not very often.
Mostly, the lettering will suffer, especially when the
message window is wide, requiring a lot of shrinking
to fit it on my 7.5 x 9-inch page format (minus margins,
of course). For me, it worked out that the time and
frustration I'd spend on tweaking the bitmap characteristics
and then trying it out at two or three screen resolutions
and on a BW and a color laser printer... took as much
out of me as just slapping together a duplicate
of it in Visio. Also, if the screen changes slightly
before product release, it's simple to tweak the
text and re-save. If a bitmap screenshot needed a lot
of massaging in a bitmap editor, then the revised one will
need it all over again.
As I said, when there are decorative graphical elements
in a window (mostly, little theme pictures, like
the globe and computer, or like the shredded-window icon)
then I just copy those in as small bitmaps within my vector
drawing. I don't try to re-invent those wheels. I don't
care if the windoze logo happens to get smudgy and
pixellated at some resolutions, as long as the text
and the bounding boxes are razor sharp, cuz
the text contains the info that the customer needs.
The rest is just meant to look familiar enough that
they recognize what screen they're on.
The argument that an imperfect rendering of the
interface elements will distract and confuse the user
seems to be countered as follows.
Many of us need to show fairly standard activities
that nevertheless are partly at the mercy of the
particular status of the user's computer.
You can show the reader the process of verifying or
enabling/disabling, or removing a driver from Windows,
for example, but you can't show him exactly what he
will see on his screen when he opens the "Devices"
dialog. Almost of necessity, *his* list of installed
drivers and devices will be different from yours,
so not only will your screenshot show a slightly
different font and maybe a different Pantone color
in the title bar, but it will show a different list.
EEeek!
If you, as a manual-reading user, are knocked
off-kilter by noticing the difference between 11-pt
Humanist531Bt versus 11-pt Ariel Blk, aren't you
going to be absolutely devastated trying to find
<Devicename> on your screen among a bunch of entirely
different words and names than what that inconsiderate
writer shows in the manual?
Truth be told, graphic handling is one of the few things
I miss from using MS Word. Because Word gloms onto graphics
and makes them its own, it's very good at outputting them
directly to screen or to print. FrameMaker has been much
nicer for other things, but it doesn't beat graphics into
submission the way Word did. It takes a much more hands-off
attitude.
C'est la vie. C'est la guerre.
I'm expecting the adventure to continue as I attempt to
move to Linux (causing me to abandon Frame... and Visio). :-)
A final thought. Someone is bound to say (and I see there are
some more additions to this thread that I have yet to read)
that "The customer is always right." Well, I'd like to suggest
that the customer is always right only when the customer is
willing to PAY to be always right... Otherwise, the customer
gets a solution that compromises across all the customers who
pay the regular price.
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
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
---
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.
