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: Getting rid of the manual From:John Garison <john -at- garisons -dot- com> Date:Wed, 26 Jul 2006 08:20:03 -0400
OK, time for my 2¢ ...
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.