Re: Screen shots for online help

["Chuck Martin" <cm -at- writeforyou -dot- com>]

"G. Abenhaim" <g -dot- abenhaim -at- nhc -dot- com> wrote in message news:209630 -at- techwr-l -dot-  -dot-  -dot- 
> On Monday, August 18, 2003, at 02:24  AM, Anitha R wrote:
> > How many of you include screenshots in your Online Help files?
>
> We ALWAYS use screenshots for online help to let users know what they are
> supposed to see on screen. If they do not get the extact screen when they
> use teh software, then they know they have missed a step. I would say
every
> page has at least one or two screen shots..the documentation here at my
> company must be very detailed. Any less, we would get calls from our
clients
> complaining.
>
> Screenshots and their description help the users understand more easily.
> remember, that you always need to write your documents as "dummy proof";
as
> if they never had background knowledge..so even the high level technician
> can understand the low level of the application.
>
Since I began developing online Help more than 10 years ago, the general
mantra has been to not use screen shots in online Help. The biggest reason,
as some have noted here, is that screen real estate is both incredibly
valuable and in short supply. Well-designed Help systems take up just a
small part of the screen so as to cover as little of the application as
possible. Screen shots in the topics force users to often scroll vertically
(not often a good thing) and usually to scroll horizontally (almost
universally a Bad Thing).

Way Back When, when I took a couple of courses by William Horton, one of the
things we covered was screen shots in printed material, most notably the
size of such screen shots. His research showed that making screen shots
25%(!) of their real size didn't significantly detract from their
usefulness. The conclusion drawn was that screen shots in printed material
are used as simply a marker to insure that users are in the right place,
that there is not need to see details in the screen shot. User glance at the
manual that is reasonably close to their monitor, see that the (smaller)
screen shot look like the window or dialog box they see on screen, and know
they are in the right place.

Ahelp system is much closer to the application on screen--usually covering
part of it. So if the object on screen (window, dialog box, etc.) is well
labeled, and the Help content is clear abotu what it is referring to, screen
shots shouldn't be necessary in many Help topics, especially procedural
ones. Consequently, topics can be compact and fit often into single screens.

The one nagging issue: user printing Help topics. But how many users do
that? I have no data, but I've not encountered many who do.

More recent developments in online Help make the use of screen shots even
less necessary. Help ssytems that reside in their own pane within the
application or dialog box have even less a need to have their screen shots.
And embedded user assisttance places performance support right where suers
are doing their tasks.

That all said, when creating standalone Help topics, I do use small
illustrations. Most often that's when an application uses toolbars, and when
I tell a user to click on a button, I'll add a small illustration of the
button with its icon. That doesn't significantly affect the space needed to
display the topic information, yet offers a visual cue that shows the user
just what to look for on the toolbar.

In the rare cases where a full screen shot might be called for, especially
in a conceptual topic where I want to illustrate and explain the UI with
callouts , if the technology allows, I'd place the screen shot in a separate
window, pop-up if possible, with a link in the main topic.

Chuck Martin

P.S. Are the "clients" referred to that actual users of the software and
documentation? Or are you creating software and documentation for said
clients who are buying the software and documentation to be used by their
users? If the latter, many clients in such situations believe that
documentation requires lots of screen shots, but users may or may not need
them. I've been in situations like that, and give the clients what they
want, but you have to know the real end users to know what will work best
for them. many clients in such situations are making assumptions based on
their own beliefs, not real user needs.