JoAnn T. Hackos, PhD
Accidental reuse—reminds me of the title of a popular book and movie a few years ago called the Accidental Tourist. Information developers and instructional designers, pursuing a single-source strategy and a content-management solution, believe they will be able to reuse content created by others by accident—that is, without a plan in place to develop content for reuse by design.
The problem has emerged for me in two ways, through an example of “accidental reuse” in a product demo and through work with organizations that are attempting to capitalize on their single-source investment. The conclusion I’ve reached—accidental reuse doesn’t work.
Product Demo Highlights the Reuse Dilemma
I have a very nice self-running, well-narrated product demo that I bring out whenever I need to show a group of information developers how a content-management system (CMS) behaves. The demo, for a popular CMS, illustrates check in/check out, version control, sharing histories, and the reuse of content in different contexts. After a few years of showing the demo, I know it by heart. About 18 months ago, while running the demo yet again, I stopped paying attention to the intended content and happened to notice an interesting effect. The speaker demonstrates how a writer might search for a paragraph of content in the database, locate it in someone else’s document, and reuse it in her own document without resorting to “cut and paste.” The paragraph of text is stored only once in the database but reused in two different contexts. Nice example!
Unfortunately, the paragraph of text, just by chance, begins with the word, “furthermore.” The people who prepared the demo were just illustrating the reuse functionality. I’m sure they paid no attention to the paragraph they happened to select for reuse. But I wonder—how often would I (or any other writer for that matter) be able to reuse a paragraph from another text, written by someone else, that begins with the word, “furthermore”? A perfect example of accidental reuse—and highly improbable.
Information Developers Expose the Problem
Reuse appears to be on everyone’s mind these days. The saying goes: “We can save time and effort and reduce development costs by reusing information.” Managers do elaborate calculations of their expected return on investment predicated on the reuse mantra. Then, once their CMS is in place, they sit back and wait for reuse to happen. After about six months, they call me. The request—come and teach our writers and our course developers how to write in a single-source environment. If they could only understand how to write differently, reuse would explode.
As I investigate the problem and develop a workshop for their needs, I ask how they have planned for reuse. The answer—we didn’t know that we had to.
Reuse can’t be Accidental
For a number of years, the software-development world has espoused the reuse solution in object-oriented programming. Develop functional modules that can be reused from program to program and save massive amounts of development time. Sounds familiar?
Unfortunately, the results have been very disappointing. Read almost any discussion of software-development management, and you will learn that programmers don’t want to reuse objects developed by others. The complaints—”it takes me too long to find the object I need; the object is not well documented so I can’t really tell what it will do to my program; it’s a lot faster and easier to write it myself; if I have to reuse an object, I will probably want to tweak it to make it better.”
Those words of explanation are nearly identical to the words of information developers and instructional designers pursuing accidental reuse. It simply doesn’t work, at least not at the level required to achieve a noticeable return on investment.
The Solution—Planned Reuse
If you are to achieve the return on investment you have promised, you need to organize around planned reuse. Planned reuse can occur in at least two ways. The first was suggested to me by Robert Reich, who developed his Environment technology around this strategy. He suggests beginning with an entire existing document, such as a previous version of a manual, and making the required changes. The Environment technology creates a networked set of relationships among the reused and the new components in the database. This strategy seems to me to work most effectively in a “one off” situation. For example, I have an existing proposal that I want to modify to create a new proposal. I want to add a section I’ve written in several additional proposals that fit the new situation. I can drag-and-drop these into place in my new version of the document. Voila! Reuse!
More determinedly, I recommend planning for reuse, not by assembling components from previous work, but by designing modular content in a subject area and reusing content by packaging modules into multiple contexts. With this strategy, you begin with the parts and assemble them as needed into various wholes. Take, for example, the subject matter needed to aid surveillance engineers in diagnosing and clearing alarms. The subject domain, “clearing autonomous alarms,” can be divided into a series of modular topics, limited in size and scope to foster the reuse strategy. Some topics might discuss concepts—perhaps a group of informative “articles” written by team members who understand what readers need to know as they begin the diagnosis process. Other topics will explain the process of diagnosis and problem resolution—once again presented as a series of autonomous articles. Still other topics will present the procedures needed to clear each type of alarm, accompanied by topics that present reference information, perhaps in the form of tables and checklists.
To create a topic-based reuse strategy requires a lot of advance planning. A collaborative working team of information developers and instructional designers must understand the users’ need to know and plan the set of topics to be developed in advance of the writing. They collaborative team must also plan at least a portion of the proposed “packaging” of the topics into specific contexts—a guide for training new surveillance engineers in handling the standard alarms, a quick reference for diagnosing infrequent alarms, a conceptual overview for those planning how the alarm system will be configured. Of course, it is impossible to know all the potential configurations that users might eventually want or all the media that might be useful to them. However, the planned packages provide the writers with a context in which they might anticipate how reuse will mostly likely occur.
By developing a topic-based reuse strategy, you are essentially creating a database design that will naturally result in reuse, rather than planning individual deliverables and hoping that reuse might happen. Content management doesn’t happen by accident. No miracles are likely to happen. Planned reuse will increase the productivity of your team and may result in an even greater return than you had anticipated.