Re: Why We Need Good Software Manuals

[William=E -dot- =Newkirk%Pubs%GenAv -dot- Mlb -at- RODES -dot- CCA -dot- ROCKWELL -dot- COM]

>For example, when I'm configuring Eudora, I encounter fields like Network
>Timeout and Network Buffer Size; checkboxes like Cache Network Info and Use
>Asynchronous Winsock Calls for Database Functions.
>As I arrive at that point in the configuration process, I need a little
>tutorial that explains what these items are for and gives me some idea what
>to expect from setting them one way or another.  ...RM
>Richard Mateosian        http://www.c2.org/~srm/   President, Berkeley STC
>Freelance Technical Writer     srm -at- c2 -dot- org        Review Editor, IEEE Micro

that's my point exactly. the original example was completely off the wall in
an attempt to get across the frustration when you have a program asking for
information, provides a "help" function at that inquiry, and the help
function fails to provide even an insight into what's wanted.

at the minimum, it would be nice if the help were to at least tell you where
to look in the rest of the documentation for more information. It's bad when
a program comes up with something like "your administrator will provide these
values".

if it were a hardware manual, you'd have a section on installation, a section
on operation, and a section of general information (specs). an electronic
help system may not have the room for all that sort of rot, but it shouldn't
be just a glossary or dictionary. If it was important to the program to only
have an 8.3 file name in a box or only numbers with no leading zeroes,
certainly the help should say so.

i've been harboring the thoughts that some if not a lot of program authors
actually never use what they write...8)

bill n
rockwell avionics/collins
wenewkirk -at- rodes -dot- cca -dot- rockwell -dot- com