Re: Troubleshooting Documentation (FAQ approach)

Subject: Re: Troubleshooting Documentation (FAQ approach)
From: Dan Roberts <DRoberts -at- ISOGON -dot- COM>
Date: Wed, 5 Aug 1998 13:39:39 -0400

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=



Previous by Author: Advice?: Word Pro 97
Next by Author: Re: Letters of Recommendation
Previous by Thread: Norton corrupts D2H (take 2)
Next by Thread: re-formatting Word's autonumbers


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


Sponsored Ads