|
JoAnn T. Hackos, PhD
CIDM Director
www.infomanagementcenter.com
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.
|
