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.
Subject:Re: Including Screen Captures From:Henry Korman <korman -at- WP-CONSULTING -dot- COM> Date:Mon, 27 May 1996 10:13:01 -0700
On 23 May Bill Hartzer wrote:
>Has anyone heard of this theory of not including screen captures in
>doc for GUI-based software products? Is the user missing anything by
>not having screen captures in the doc? It _IS_ easier on our end to
>not have to do screen captures, but I'm a little concerned about the
>users. Am I way off base by thinking this way?
I teach a course in downsizing documentation for Seminars in Usable Design
(http://www2.csn.net/suds/). One topic has to do with reducing the number
of screen captures in documents.
By way of supplementing what others have offered:
Is the customer's goal learning or performing?
If the goal is performing, screen captures may help a customer race through
to the end, making quick comparisons between screen and page, then moving
on quickly.
If the goal is learning how to use the product, too many screen captures
may be an impediment, since sensitivity to the interface is a major
ingredient in mastering software. Screen captures are dead things, lacking
the richness of the actual interface. Consistently directing the attention
of customers to the screen, rather than at screen captures, can help
develop and tune the needed sensitivity. Captures would be reserved for
those instances when a crucial confirmation is necessary, such as a major
branch in the path of a procedure.
We believe you can't simply cut the screen captures and maintain usability
of the documents as learning tools. The second approach needs a
well-rounded implementation, embodying several related principles. These
include: many brief textual cues to interface elements, using descriptive
language, appropriate formatting of types of information, and making sure
customer's learn techniques for recovering from common errors.
Best regards,
Henry Korman
Wordplay Consulting Email: korman -at- wp-consulting -dot- com
Documentation/Design/Consulting Voice: (510) 841-5858
Berkeley, CA USA Fax: (510) 848-0159
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net
