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.
Wow, that research is really interesting. I've always done partial
screenshots, although not as small as some in the article. After reading the
article, I'm now rethinking my approach.
On Tue, Sep 16, 2008 at 10:00 AM, Boudreaux, Madelyn (GE Healthcare,
consultant) <Madelyn -dot- Boudreaux -at- ge -dot- com> wrote:
>
> Michael West wrote:
>
> >> How do
> >> you annotate your screen shots?
>
> >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.
>
>http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=768161 includes
> the abstract. I've found the whole article online in the past, but I
> don't know if it's still available.
>
> ***
>
> 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 tomjohnson1492 -at- gmail -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit
>http://lists.techwr-l.com/mailman/options/techwr-l/tomjohnson1492%40gmail.com
>
>
> To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwr-l.com/ for more resources and info.
>
>
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-
