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:Dream World From:Mark Baker <mbaker -at- OMNIMARK -dot- COM> Date:Tue, 25 Aug 1998 10:06:23 -0400
Cynthia Fabre wrote
>And I respond... Yes, in a perfect world this would happen! However, it
>has been my experience in several companies that the developers are "hands
>off" and us measly lil' online help developers shouldn't even speak to
>them. (I won't mention how many times I've pointed out errors to the
>developers. If I'm going to write help, I'm certainly going to test my
>procedures!)
Design collaboration never just happens. All designers are jealous of their
design privilage, none more so than writers. But design isolation does not
make for good products. Integrated multi-disciplinary design teams do. This
will not happen all by itself, but you can make it happen. A technical
communicator is (or is supposed to be) a technical professional in a
particular discipline which is equal in stature and importance to user
interface designers and software developers. Of course members of these
disciplines assert the importance of their disciplines above all others (UI
people and developers battle for supremacy all the time). The question is,
why don't technical communicators assert themselves in the same way?
>It is also important to remember the audience for which the help system is
>intended. I have written sophisticated online help, and I have written
>"monkey-level" online help. To say that a field "should" not have a
>description is to assume your user is smart and competent.
Hardly. In the case cited we have a text box with the label "Address:"
beside it. It's not much of a stretch to figure out that you are supposed to
type an address in it. Extrapolating the UI just a little, we can reasonably
presume that this text box occurs in a form titled something like "Supplier
Information", probably reached from a menu item "Supplier Information ...".
If those are insufficient clues to the user to type the supplier address
into the text box, then I can't see how we can assume that they know enough
about Windows to use the "What's this?" help in the first place.
Monkey level help is lost on monkeys (who lack the skills to take advantage
of it) and insulting and annoying to people. You can and should assume your
reader has sufficient knowledge to have got to this point in the UI and to
understand the task they are trying to perform. It is the technical
communicator's job to understand their reader well enough to provide help
only where help is needed. Sticking gratuitous help messages on everything
is not thoroughness, it's laziness. Good design never arises from a contempt
for the intelligence of the user.
---
Mark Baker
Manager, Corporate Communications
OmniMark Technologies Corporation
1400 Blair Place
Gloucester, Ontario
Canada, K1J 9B8
Phone: 613-745-4242
Fax: 613-745-5560
Email mbaker -at- omnimark -dot- com
Web: http://www.omnimark.com