Re: When to use screenshots

["David Chinell" <dchinell -at- msn -dot- com>]

In my feckless youth, I often copied neat stuff to my swipe 
file without carefully noting an attribution. The following 
material is pretty much what I'd say about your question, 
but somebody beat me to it. If the original author would 
like to claim responsibility, I'd be glad to update my swipe 
file. -- Bear

~~~~~~~~~~

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 shotshad 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".

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.

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

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.