Re: Troubleshooting Documentation (FAQ approach)

[Dan Roberts <DRoberts -at- ISOGON -dot- COM>]

I used this approach for a GUI application that required troubleshooting
information. One method I used to generate potential troubles was to
take the various tasks/functions/actions a user could perform, and try
to come up with reasons the user wouldn't be able to perform the action
... "I'm in the Widget dialog, but I can't get dopplegangering to take
effect? Well, you have to make sure that the Widget has a Dopple that
you can ganger. If the Widget doesn't have a Dopple, you must first
create one."

Of course, this method only worked because I had the application on my
desktop and could play with it and break it. And it also required input
from developers to confirm/deny the troubles that I shot.

I can't imagine trying this method with an API or language. Ack!

Dan Roberts
droberts -at- isogon -dot- com

-----Original Message-----
From: Renee Harper [mailto:sashrs -at- STUFF -dot- UNX -dot- SAS -dot- COM]
Sent: Wednesday, August 05, 1998 1:09 PM
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Subject: Re: Troubleshooting Documentation



2) the FAQ approach

   This approach lists all the problems as customer/user questions.  For
example:
   "Why can't I use X while Y is running?"  Lots of users like this
approach,
   but as I writer, I find it hard to write these questions (unless I
have
actually
   received the questions from users). You can find many FAQ examples on
the
Web.


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=