When to use screenshots

[tstorer -at- free -dot- fr]

I'm wondering if any of you out there use explicit guidelines for when
writers should use screenshots.

At the company where I work as an editor, we're getting pressure from the
localization department to drastically cut down on the number of
screenshots in our guides. They localize into eight languages and spend
way too much time, hence money, on recreating screenshots in the different
languages.

On the one hand, we've identified the need to use common fictitious data
in the processes we're making screenshots of (user names, file names,
etc.), shared with localization, so localization can quickly set up their
screens.

On the other, in my editing I'm seeing that lots of writers are throwing
in screenshots when there really isn't any need for them. I'm now quite
ruthless about tossing out screenshots.

My own off-the-top-of-my-head rule of thumb is that to be considered
necessary, a screenshot has to help users get information quickly that
they won't get just as fast by simply looking at the screen (assuming they
are actually using the product as they read the doc). This seems to be:

- To present major GUI components that are dense, complex, or
ill-designed, with call-outs to identify screen areas or elements, so the
user doesn't need to squint and scan the screen.

- In numbered procedures, when a dialog box or window is large with lots
of elements, and the screenshot zooms in or is cropped in such a way that
the user can quickly see where in the screen to go for this step.

I should point out that our software is relatively sophisticated and all
our users can be assumed to have mastered basic mouse techniques. In one
guide the writer had put in before-and-after screenshots to show the
results of resizing a pane--really unnecessary for the readers of that
guide.

Some writers believe that users need to be reassured at every step of the
way--if you say as the result of a numbered step, "the so-and-so window
appears," they want to show that window in a screenshot so users can check
to be sure they haven't gone somewhere else. I feel this is fine for
mass-market software liable to be used by insecure beginners, but in this
day and age, I think business users at a certain level (the level of our
software) are more concerned to have fast, lean documentation without
extraneous information or page count than to have their hands held for
basic mouse-click procedures. (The desire for lean documentation is one
our customers have strongly expressed--along with the sometimes
contradictory desire for exhaustively complete documentation.)

So, if anyone has explicit guidelines for screenshots or sees flaws in my
approach, please chime in!

Thanks,

Tom Storer

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo:
http://www.webworks.com/techwr-l

Doc-To-Help 7.5 Professional: New version with new features, improved performance and reliability, plus much more!  Download your free trial today at www.componentone.com/techwrlfeb.

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.