Re: Getting rid of the manual

Subject: Re: Getting rid of the manual
From: Ami WRIGHT <ami -at- ziplink -dot- net>
To: <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Thu, 27 Jul 2006 08:14:51 -0400


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

Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at http://www.DocToHelp.com/TechwrlList

---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.


Previous by Author: Re: FrameMaker 7.2 and 7.1
Next by Author: Re: FrameMaker 7.2 and 7.1
Previous by Thread: RE: Getting rid of the manual
Next by Thread: Adobe Acrobate 3D


What this post helpful? Share it with friends and colleagues:


Sponsored Ads