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.
>
> we don't have
> to explain things such as "drag and drop". As techwriters, we can assume a
> greater degree of computer knowledge on the part of the user.
>
Ye gods, how I wish this statement were true. Unfortunately, it assumes a
uniform level of familiarity with computers. You still have to match the
granularity and the coverage to the anticipated skill level of the
audience, and that is still a variable.
Technical writing is not always for a technical audience. What about a
person who has just bought a computer for the first time? What about
people who are trying to learn how to use something like Photoshop for the
first time? There are some still out there, more than we'd like to think.
I just finished doing a software user guide for a customer who is buying
our product for use by employees who had never used personal computers
before. Up until this very year they had done all their work on old
green-screen dumb terminals. I had to design and write the manual on the
assumptions that the users had never before worked on a system that
included a mouse. (In computers, what the heck is the plural of "mouse"?)
I had to put in an annex that explains, in excrutiating detail, how to use
a mouse, what a pull-down menu is, how to scroll, etc. It is a real
challenge to write a software user guide for people who may not know what
the word "click" means.
I think companies will soon discover that the attempt to fuse the jobs of
UI designer and tech writer can be pushed only so far. They both are still
very different jobs, with very different requirements, and they are both
full time jobs. The UI designer can put popup tips all over the interface
to explain every feature on it; in most applications, that still does not
tell the user *what to do next*. It does not give the user who needs
information about a procedure a way to find procedural information.
Creating help that addresses those types of concerns is still enough of a
chore that you can't do that and design/write/debug the interface at the
same time.
I'm sure companies who want to cut their payrolls will try fusing the
jobs. And eventually they will come full circle back to the discovery that
created the position of techical writer in the first place - developers
don't have the time to create products and document them both, even if
they have the language skills.
ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl
WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
