When learning to use a software package, game or language, many users need time to play with it. It's not all fun and games -- it's learning. We have to learn where the "handles" are, the peculiar jargon and how the authors think. Even if we don't do it consciously, we do it.

Most major software applications, and many minor ones, have user groups representing the feelings of all users. The manufacturers generally listen in and work not only to improve the product based on group feeling, but the manuals as well. On the other hand, the "80/20 Rule" applies here: 80 percent of the people use 20% of the features.

The "80/20 Rule," when observed in user groups, has at times led manufacturers to recognize that nobody read the manuals anyway. In the days before Windows 95, Microsoft stopped giving full copies of DOS manuals for this reason. Many manuals are going to full online or downloadable versions instead of paper. Online or context-based help files have become the norm.

Software developers, constrained by time and money, will place their efforts where they think it'll do the most good:

1. keeping the 80% happy, and
2. adding neat new features with marketing pizzazz

Because packages like MS Office allow a large number of people to perform a large number of tasks, it almost obliges the user to RTFM, though users have learned over the years that many of their tasks are easier learned from trial and error, or from asking friends to help, than from RTFM. Sooner or later, we will get the software to yield to our superior might and unyielding will. :-)

MS Office products, for instance, have become a de facto standard and are almost everywhere. Like the English language. Maybe we used to write ad hoc programs for analysis and plotting some time back, but nowadays we might instead reach for Mathematica or MathCAD instead.

The good news is that software that does many things is likely to do what *you* want it to do. All you have to do is figure out how. You may have to RTFM, but you may not have to read it *all*. The bad news is that for us to do that is against our natural behavior.

Software manuals are still for the most part not written either to instruct or to serve as useful references. If they don't perform one or the other function (and both would be better), people won't exactly *take joy* in using them even as a last resort. As writers, this is one of the areas where we have the most difficulty in considering reader needs: because we know the software well enough to write about it, we know it too well to remember the questions that we used to ask -- and that our readers will ask now.

Mathematica, a math expression manipulator package made by Wolfram Research, seems to take great pride in the really cool graphics you can (theoretically) make using it: fractal images, topographical feature maps, that sort of thing. The problem with a program that powerful is that the "80/20 Rule" becomes understated -- to more like "95/05." Mathematica is a large, showy program -- with large, showy manuals -- which will force many small business users to see if they can get the charts, graphs, and simulations they *need* using just Excel.

But Mathematica goes one step further: you can use it to create "notebooks," which contain not only the graphics, but the equations used to generate them, and any form of commentary you want to add, in any font you want it in. This makes it possible to ignore word processing software altogether and just write up all the work in a Mathematica notebook. Of course, if you do that, the notebook can only be *read* by other users of licensed versions of Mathematica.

Analytical software doesn't have to be very much more powerful before it gets so far away from the engineer's need to *get to the point* that we can never find our way back again.

The fact is that if you have a special message to convey or you are developing new ways to manipulate and visualize data, almost by definition you have to do it on your own regardless of the complexity of the software you use. You're unlikely to find any mass-produced software that reflects an awareness on the part of the designers of the importance of data organization or visual representation.

References

Mathematica
Matlab

1. If you're concerned about the quality of the manuals you're using, try a user group. Usenet newsgroups exist for most major languages and application software as well.
2. If you're writing a software manual, write for the 80% first, and get their input at all stages of development. Know not only what users want to do, but why and for whom as well. Don't write it as a narrative. Write a recipe instead, based on what users want.
3. Take the organization and presentation of data into account before you use the software to the extent that your resources permit.
4. Be concise. The thicker the manual, the less it's used. If an item won't be referenced by a user, can you leave it out?
5. Make sure you can use it. Later on, users will come to you for help. Will your manual help you to remember procedures you haven't used in months?
6. Documentation inside the system is better than a manual, and tool-tip text and drop-down help better still.