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.
That would depend on a number of factors, including the learning objective,
the complexity of the interface, the type of user action required, the
quality of the screen capture, and quality of the accompanying text, and so
on.
Is it a training manual or a reference manual? How experienced are the
users? What publishing media are in use? Under what conditions will the
users use the learning material?
There simply is no one-size-fits-all rule for all this.
I do know a few things after thirty years in the business:
1. My stuff works well and is always in demand.
2. An instantly-identifiable mark of amateurish user assistance material is
a clutter of screen captures that serve no clear purpose.
3. Real-world business results trump "research" every time.
--
Mike West
Melbourne, Australia
> -----Original Message-----
> From: Boudreaux, Madelyn (GE Healthcare, consultant)
> [mailto:Madelyn -dot- Boudreaux -at- ge -dot- com]
> Sent: Wednesday, 17 September 2008 2:00 AM
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Cc: Michael West
> Subject: Screen captures (was RE: TECHWR-L Digest, Vol 35, Issue 14)
>
>
> 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 archive -at- web -dot- techwr-l -dot- com -dot-
