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: help with a strong word From:Richard Danca <rdanca -at- UIE -dot- COM> Date:Thu, 12 Aug 1999 12:27:01 -0500
The issue here is not how a techwriter should handle a dangerous
procedure but how the *programmers* should do it. If developers
have created a potentially fatal process, then let them fix it, not expect
techwriters to save their users.
In this case, it seems that the procedure should be disabled by default.
This would require users to activate it before they could use it and
would give the programmers more places to add on-screen warnings.
It's *code* writing, not tech writing that will best serve the users in a
situation like this.
A couple of products that do this are Symantec's Norton Utilities and
Symantec's (formerly Quarterdeck's) CleanSweep.
>From the earliest release on, way back in DOS days, Norton Utilities
has set many dangerous procedures to read-only. It takes a special
effort to make the program to write changes, and even then you have
the choice of setting it to write for this session only (the default) or for
all future sessions.
Likewise, CleanSweep ships with SafeSweep on as the default.This
prevents you from deleting certain kinds of files. You must deliberately
set SafeSweep off to be able to delete these files, and even then the
program asks you if you really want to delete the files and whether
you want to archive the deleted files just in case.
Warning users against dangerous procedures is really the job of the
interface, not the docs. Let's be honest: we're a lot surer that users will
see the interface than the docs (sad but true). Let the programmers fix
the problem they've created and do it just in time: right before the
problem arises.
Soap box mode off.
==================
Richard A. Danca User Interface Engineering mailto:richard -dot- danca -at- uie -dot- com 800 Turnpike St., Suite 101
978-975-4343 North Andover, MA 01845
978-975-5353 (fax) USA http://www.uie.com
===================================
Heads up, Texas! Our Product Usability: Survival Techniques
and Techniquesfor Complex Applications will be in Houston
Sept. 27 and 28, followed by Jared Spool's Brain Sparks
on Sept 29. Details at http://www.uie.com
