No abstract

In mid-1979, a study group was convened at the IBM Santa Teresa Laboratory to find ways to improve the usability of publications supporting the Laboratory's programming products. 1 The group, called the System Information Ease-of-Use Study Group, consisted of technical writers, editors, and information planners---all members of the System Information (i.e., programming publications) Department at the Laboratory. The study group was asked to answer the question: "What can the planners, writers, and editors of programming publications do to make the books they work on more usable?"

No one doubts that indexes are of value to readers. But they can also be of value to their own authors as editing tools. Because an index provides a microcosm of the main text, errors in that text will often be reflected in the index, and reflected in a way that makes them more visible. As he creates the index, the author can use it to spot errors in the body of the work—errors of terminology, of arrangement, of proportion, and of omission. This technique can be used to supplement the normal editing process.

No, Temps Perdu is not the meteorologist brother of Frank, the tender chicken man. It is a French swan's way of saying "lost time."

The problems with flawed technical documents are frequently problems of a larger nature. When the subject to be described is itself amorphous or internally illogical, technical writing may only dutifully reproduce the inherent confusion. Writers should be alert to identifying these problems and assisting product/procedure designers in eliminating confusion at its source.It's no secret that customers frequently complain about programming manuals. In annual meetings, around the office coffee machine, in comp centers neath the abend's red glare-one can hear the people who depend on software documentation raising agonized cries. The problems that can be found in manuals are many, and familiar: minor irritants like Ted Mack spelling, blunders like lost table headings or illegible printing, yellow-brown fogs of vagueness, absent examples, missing information, even the deadly sin of downright factual mistakes-all these flaws are not uncommon.There have been attempts at solutions. Originally, back in the Iron Age of data processing, manuals were written by the same people who designed the systems, by programmers and engineers. It was soon concluded that the manuals were turning out badly because-although these fellows were marvelous coderrthey were *