The object-oriented model for program design evolved from the structured, or top-down, model. Programs in recent years have become much larger, more complex, and subject to faster changing market conditions, and the object-oriented model appears better suited to address these new realities. Technical writers are facing a similar challenge as the volume of information is growing exponentially and increasing in complexity. This paper describes the object-oriented model, shows how the model is influencing the world of documentation, and proposes that it be considered as a basis for the creation and maintenance of large libraries of technical information.

Benchmarking is rapidly becoming a standard business practice used by organizations to improve their quality in specific areas. Though benchmarking previously has been associated with product comparisons, such as benchmarking the performance of one product with another, process benchmarking is becoming equally important. This paper, based on a recently conducted benchmark, discusses why you might consider benchmarking an aspect of the process you use to develop technical information. It discusses how to prepare for a benchmark, find a suitable benchmarking partner, and conduct a benchmark, and it provides a guideline for the time and effort required.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

Because corporations today face fierce international competition, they must produce and maintain high-quality documentation-but at minimal cost. Optimizing a writer's time and effort will no doubt become a key study area as we try to do more with less, without sacrificing quality. One way to increase a technical writer's productivity is to design documentation so that it covers a broader product area. This approach gets more use (or reuse) of the text. The paper describes the productivity and cost benefits of creating single-source manuals, that is, two or more manuals output from the same set of source files created and updated by one writer. It also describes how to create single-source manuals based on an actual case.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

The ways in which technical writers can team up to make a video on a technical subject are discussed. The authors' experiences are described to illustrate methods for planning video and writing a script using visual and aural metaphors to represent technical concepts; the production process, and tips and techniques to enhance the presentation. The production of videos using in-house resources, the videotaping of live presentations, and video editing, packaging, and distribution are discussed.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

It is pointed out that the design document is an effective way of managing documentation development, particularly in large-scale projects. It provides a rough picture or sketch of the information before the writing begins, thereby permitting changes in design before the course of the documentation is set. Once finished, it becomes a road map for writers, managers, and developers. It can later be used to verify that the design was implemented in the final text for publication. It is concluded that, although on first appearance it might seem that a design document simply adds one more thing to do on a project, the added effort is more than compensated for by the amount of time and money saved in not having to modify information at a much later point.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

Many organizations hire new technical writers regularly as their business expands, or hire temporary technical writers to cope with a heavy workload period. Although it is assumed that such people are hired for their writing skills, they still must be trained quickly in four areas: how business is done in the organization, the process used to produce information, the style of writing preferred, and the technical tools available and how they are to be used. The author shows one way of structuring such a training program. It is based on an actual course developed over a period of three years. It is concluded that a good training program requires considerable forethought and subsequent modification to keep up with change, an organized coordinator, a dedicated set of teachers and a process that can be readily learned and modified again by others as turnover occurs.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>