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.
I once wrote documentation for a small software program, which required
about 50 pages of documentation. While I was writing the documentation, I
also gave them feedback about how to make the software easier to use.
It was a contract job, so I wasn't around to find out whether or not they
actually implemented my suggestions. But if they did, they probably needed
less than 5 pages of doc.
I think John's on the right track with this. If at all posible, design the
product to not need doc.
-Ami
John Garison wrote:
>
>You're thinking about this the wrong way. Don't think in terms of paper v.
online. Think
>of it from the users' point of view. The real question is "How do I
provide the information
>the user needs when and where it's needed so that getting it isn't a
distraction?"
>
>The real answer to this is to make the information part of the application.
>
>Put more effort into usability design. Put more effort into knowing who
your users are
>and how they use your applications. Put information on the screen. Provide
>information as part of the forms they have to fill out. Provide hints.
Show examples.
>Make it all part of the application.
>
>The down side: It takes us out of what we feel comfortable with. It forces
us to work in
>conjunction with the developers. It's expensive.
>
>Counter argument: Taking us out of what we're comfortable with is a good
thing.
>Working with the developers is a good thing - in fact, once they see what
all we do,
>they'll be less likely to make changes without consulting with us first.
And it really
>isn't that much more expensive. It's just different.
>
>You may still need some sort of introduction/overview/getting started
guide. OK, write
>one up that's short and gets people up and running and in front of the
application. Do it
>in PDF and let them print it out if needed. Show them the support that's
designed into
>the application. Then get out of their way and let them do their jobs.
>
-----------------------------------------------------------------
Ami Wright
"Technical" tech writer
American with international experience
www.amiwright.com
-----------------------------------------------------------------
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
