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.
>Depends. If I'm giving an instruction, I show only the thing that needs
>to be acted upon, plus enough contextual information to make it
locatable.
>Generally the nearest corner or border is more than enough.
>Verbal context is often just as useful.
>I *never* capture a whole window just to talk about one tiny little
>piece of it. That's the sort of thing a programmer would do, not
>a professional communicator.
Unfortunately, the research into user behavior doesn't support you on
this. As reported in "The effects of screen captures in manuals: Textual
and visual manuals compared," (Gellevij, M., Van der Meij, H., De Jong,
T, & Pieters, J., 1999. IEEE Transactions on Professional Communication,
42, 77-91.), a comparison of full screen captures, partial captures, and
purely textual manuals (no captures at all) found:
"For learning, the full-screen captures manual and the textual manual
were significantly better than the partial-screen captures manual."
In other words, by providing partial screen captures, you're doing your
users more of a disservice than not including any captures at all. Food
for thought.
I've usually gone the route of optimizing captures, which takes MUCH
longer but gives you the best of both worlds: I make the screen as small
as possible on the desktop, capture the screen, then edit it in ways
that are in accordance with a real experience, then, if possible, grey
out the parts of the screen that are irrelevant. For example, I'd find a
page with the shortest possible title and text on the screen and edit
out extra blank spaces around the tool bars.
It requires a lot more work up front, but if you do your planning well,
you can then use the same capture, with different parts greyed out, for
multiple illustrations. If I'm doing a whole UI, I shrink my window down
to the smallest possible size that still captures things cleanly, and
capture all the images at once, then edit them consistently. This is
also useful for making tutorials, because you can keep the elements all
in the same place, which keeps your elements from jumping around the
screen when the tutorial plays.
***
>Generally in such cases my time is better spent helping the
>programmers design the GUI so that it doesn't need "explaining."
There's no such animal as a UI that doesn't need explaining, because
humans that need too many different methods of explanation. The most
stupidly obvious UI to you may be completely unreadable to someone else
because they use a different set of cognitive skills. In your private
life, you may opt to call those people "idiots" but as technical
communicators, we have a duty to learn how to explain to them.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ComponentOne Doc-To-Help gives you everything you need to author and
publish quality Help, Web, and print content. Perfect for technical
authors, developers, and policy writers. Download a FREE trial. http://www.componentone.com/DocToHelp/
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
