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: Is there a study on reading warnings, notes? From:"Kathleen MacDowell" <kathleen -at- writefortheuser -dot- com> To:"Geoff Hart" <ghart -at- videotron -dot- ca> Date:Sat, 1 Nov 2008 08:32:22 -0500
I completely agree with Geoff's idea that the warnings should be
incorporated into the steps/main content when they're related to personal
safety, and that is how I have always written them. Then the offset warnings
or cautions are added for emphasis (We mean it). In addition to placing the
content in the line "thought," I've always wondered how much attention is
given to those warning/caution boxes. When I've written hardware content,
sometimes there are a lot of warnings, and it seems possible that people
would habituate to them.
It's really a no-brainer. Contrast that with a recent download experience I
had: Click on the button to download now. Next sentence, "Turn off the
device before downloading the frabbitz." Not even in a separate step, just
tagged onto the download instructions. Adding insult to injury (or
frustration), the instructions were completely missing from the main
download page--one could just download without any instructions. Sheesh.
Regards,
Kathleen
On Sat, Nov 1, 2008 at 6:53 AM, Geoff Hart <ghart -at- videotron -dot- ca> wrote:
> Edwin Skau wondered: <<Is there a study that shows how many people
> actually read warnings, notes and tips?>>
>
> I'd bet a couple beer that there are many, but I don't personally
> know of any -- I no longer have regular access to research journals.
> I tried a quick Google, and came up with far too many results to sift
> through, none of the first few screens from journals. Maybe there are
> some academic members of our group with better access to journals who
> can provide suggestions?
>
> Meantime, if you wanted a quick feel for this, why not poll your own
> colleagues: ask 3 or 4 people per day for the next month and by the
> end of the month, you'll have nearly 100 replies -- more than in most
> rigorously controlled studies. Categorize these replies by occupation
> (office worker, engineer, manager, etc.) just out of curiosity, in
> case there's a pattern. Let us know how that turns out, because it's
> interesting information. Or set up a SurveyMonkey poll for techwr-l!
> (Experimental design is much more complicated that that description,
> but you can get good initial results using really casual methods.)
>
> (I'd do this myself, but I work at home. A sample size of 2 is not
> representative, and doubling the poll size by asking the cats
> probably wouldn't be too helpful. <g>)
>
> <<Before I moved to tech writing, I always treated them as 'asides'
> for later reading that never happened.>>
>
> And yet you're still alive? Miraculous! <g> Sarcasm aside, this is a
> reminder that some of these "asides" exist purely for legal reasons:
> like the "caution, the contents are hot" warnings on coffee mugs, the
> warning is there to protect your company, not your customers. To be
> effective, a caution or warning should be integrated in the
> procedure, not set aside where it can be ignored. For instance,
> instead of having a sidebar saying "plugging in the device can result
> in an electrical shock if you're standing in water", why not make
> step 1 of the procedure "Dry any spilled water, your feet, and your
> hands before plugging in the device. Failure to comply will..."?
>
> This is also a strong reminder that a well-designed product does its
> best to eliminate adverse consequences, or at least to protect its
> users from those consequences, thereby eliminating the need for
> cautions. With electrical equipment, a ground-fault-interrupt socket
> would prevent shocks under these circumstances.
>
> For one of our favorite non-story (the lawsuit about the woman
> scalded by McDonald's coffee), making the coffee at an appropriate
> temperature would solve the problem. (Here, the real story was not
> that the woman should have known that coffee is hot, but rather that
> McDonald's allegedly made their coffee too hot despite warnings from
> judges in previous lawsuits.) Japanese and Chinese tea cups (the ones
> with no handles) have an interesting design feature: if the cup is
> too hot to pick up comfortably, the contents are too hot to drink.
> That eliminates the need for a "caution, it's hot" warning, because
> you won't drink the tea until it's at a safe temperature. Software
> could be designed equally sensibly if anyone bothered to take the
> time to do so.
>
> <<Many folks I've asked about this have confessed to similar reading
> behavior.>>
>
> Whereas I read the "asides" first in many cases. But your anecdotal
> evidence is important: it reminds us that most people read only the
> minimum they need to escape the documentation with the knowledge they
> need. Karen Schriver studied this behavior quite some time ago, and
> found that something like 80% of all readers do nothing more than dip
> into our documentation to escape with what they need and nothing
> more, and that broad pattern (not the actual number) appears to be
> fairly representative. We need to design documentation around that
> principle... for example, by building warnings and cautions into the
> steps rather than setting them aside.
>
> ----------------------------------------------------
> -- Geoff Hart
> ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
> www.geoff-hart.com
> --------------------------------------------------
> ***Now available*** _Effective onscreen editing_
> (http://www.geoff-hart.com/books/eoe/onscreen-book.htm)
>
> Print version: http://stores.lulu.com/store.php?fStoreID=1505747
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
> solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
> HTML and publish to the Web, Help systems or printed manuals.
>http://www.doctohelp.com
>
> 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 kathleen -at- writefortheuser -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/kathleen%40writefortheuser.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.
>
> Please move off-topic discussions to the Chat list, at:
>http://lists.techwr-l.com/mailman/listinfo/techwr-l-chat
>
>
>
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
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-