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: Click X, or click the X button? From:Robert Lauriston <robert -at- lauriston -dot- com> To:techwr-l List <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 22 Oct 2009 17:56:17 -0700
I'm less concerned about research than about complaints from customers
that the documentation was bloated. There's no advantage to the user
to have a, say, seven-step procedure spread over three and a half
pages in order to provide screen shots that duplicate what they see on
screen.
On Thu, Oct 22, 2009 at 5:40 PM, Leonard C. Porrello
<Leonard -dot- Porrello -at- soleratec -dot- com> wrote:
>
> Extra time? Hardly. It takes about three seconds to insert an already
> captured image and about 30 seconds to capture a brand new image (which
> I rarely need to do). The benefit to the user is well worth the
> (negligible) time investment.
>
> As for slowing down users, again, the research doesn't agree. But maybe
> you are imagining something that I am not thinking of. The screen
> captures of buttons and icons I use don't significantly add to the
> length of my documentation.
>
> And finally, as far as I know, minimalism says nothing about using more
> or fewer screen captures.
>
> But it seems that you are more interested in anecdotal accounts than
> research or systematic theories. So, I'll add my two cents. I find that
> having a complete screen capture at the top of a help page orients
> users, and having screen captures of buttons and icons along the way
> enables users to scan pages more quickly. Instead of utilizing only
> verbal processing, having to read every word, in-line screen captures of
> buttons and icons enable the "reader" to utilize the cognitive processes
> required for reading as well as those required for visual processing. By
> being able to use more of his brain (inferior frontal gyrus,
> parieto-temporal area, and occipito-temporal area for reading and the
> visual cortex for graphics), the user is able to work through a help
> page more quickly while understanding it and how it is related to the
> GUI more thoroughly.
>
> But as someone else mentioned, it all comes down to audience. I would
> agree that an audience that doesn't need step-by-step directions also
> doesn't need screen captures of buttons and icons.
>
> Leonard
>
> -----Original Message-----
> From: techwr-l-bounces+leonard -dot- porrello=soleratec -dot- com -at- lists -dot- techwr-l -dot- com
> [mailto:techwr-l-bounces+leonard -dot- porrello=soleratec -dot- com -at- lists -dot- techwr-l -dot- c
> om] On Behalf Of Robert Lauriston
> Sent: Thursday, October 22, 2009 4:22 PM
> To: techwr-l List
> Subject: Re: Click X, or click the X button?
>
> It slows down users because when the content is cluttered with
> unnecessary images they have to scroll more.
>
> Usually when I see that stuff there's lots of other makework filler.
> At one of my old jobs, one doc shrank from 2000 pages to 130 after we
> switched to a more minimalist approach.
>
> Even if there is some marginal benefit to users, I don't believe that
> it could possibly be enough to justify the extra time the tech writer
> has to spend doing it.
>
> On Thu, Oct 22, 2009 at 3:00 PM, Leonard C. Porrello
> <Leonard -dot- Porrello -at- soleratec -dot- com> wrote:
>> I suppose it's busy work if you're stuck in 1987 and unable to single
> source. In-line with text, I use just an image of the button. And the
> research indicates that this approach is optimal for the user, aiding in
> "identifying and locating window elements and objects" (Gellevij 2002).
>>
>> Leonard
>>
>> -----Original Message-----
>> From:
> techwr-l-bounces+leonard -dot- porrello=soleratec -dot- com -at- lists -dot- techwr-l -dot- com
> [mailto:techwr-l-bounces+leonard -dot- porrello=soleratec -dot- com -at- lists -dot- techwr-l -dot- c
> om] On Behalf Of Robert Lauriston
>> Sent: Thursday, October 22, 2009 1:45 PM
>> To: techwr-l List
>> Subject: Re: Click X, or click the X button?
>>
>> You include a screen capture for every button? Even Save and Next?
>> Cropped to the button, whole dialog, or what?
>>
>> To me, that's tech-writer busywork that leads to bloated docs and
>> slows down readers. I do that only when the UI is bad and it's clear
>> that the user will have trouble finding the UI element.
>>
>>
>> On Thu, Oct 22, 2009 at 1:38 PM, Leonard C. Porrello
>> <Leonard -dot- Porrello -at- soleratec -dot- com> wrote:
>>> I use an actual screen capture of the buttons and say "Click X"
> (where X
>>> is the screen capture).
>>>
>>> Leonard
>>>
>
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices. http://www.doctohelp.com/SuperPages/Webcasts/
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
