RE: Real value (was implementing single-source) - demonstrated!

["Glenn Emerson" <gemerso1 -at- rochester -dot- rr -dot- com>]

Well, the semantic debate continues. What you define as "single source" is
in fact "content management" or to borrow from the latest buzzword
"knowledge management."

Single source means all outputs from one source. There are several limited,
practical real world attempts at this in the market now. (Doc To Help,
Framemaker/Webworks, ForeHelp, RoboHelp, Vignette StoryServer,
Astoria/Canterbury, to name a few.)

Your solution as you describe it means putting multiple sources into one
management database and then using the control system to output just what is
needed in whatever form, on demand. That's content (or more commonly
"knowledge") management. You describe getting all information about a
product out of human heads and into the database--that's the essence of the
latest IM holy grail, "knowledge management." (High level MBA types sucker
for this, because it means, they think, that all their employees are nothing
more than tupperware containers of information that can be made disposable
once the information is sucked out. Essentially, the "game boy" or "Johnny
Mnemonic" view of the work force--pop a new information cartridge into an
employee and voila.)

To digress for a moment, "knowledge management" is just information
management with a sexy name. Knowledge is applied information. Applying it
takes intelligence. Granted, one can describe the information with
meta-information, and add some primitive level of contextual intelligence to
the management system, but information does not become knowledge until it is
assimilated and applied by a human being.

Unlike the "game boy" vision that is knowledge management, however, each
human knowledge receptacle brings a lifetime of emotions, experience and
countless other variables to the table--none of which can be contained in a
"data warehouse." Thus, some are more easily educated than others. Some are
more suited to certain tasks than others.

The human element always remains in the equation. Thus, it is imperative
that the information be usable by the human element. Thus, it requires a
human expert to design the information and the presentation thereof in a
form usable by the target population. I'm digressing quite a bit from the
main discussion, so I'll end by refering you to an excellent book on the
topic: "The Social Life of Information," by John Seely Brown (chief
scientist at Xerox PARC).

Now, to get back to the discussion, the problem I have with the approach you
take to content management is that for most applications it is overkill and
less effective than more practical, scalable, human-directed solutions.
Visual Source Safe can be used for content management the same as your
system. VSS requires direct human involvement from the information
designers. This is actually good--they know best the nature of the
information, it's quality, and how best to present it to a target audience.

In your email, formats that are difficult to make fit the requirements of
the leviathan are ridiculed as "dead end." With no regard for what may well
be the best way to present information to the human population it is
destined for, you ridicule and declare unnecessary formats which are
difficult for the system to process.

You say, for instance, that "99% of all tech departments" will never use
film. Well, Apple has been using video in their technical service
documentation for nearly a decade. Apple's job descriptions for tech writers
include "digital video editing experience." By using video, they've enabled
a comparatively low-skilled, workforce with a basic education to become an
agent service force--reducing their service training costs considerably.
Sixty years ago, the U.S Army started using film because they tried several
approaches and decided film was the most effective way to train large
numbers of low-skilled troops to perform basic tasks. It is not enough for
the human to be told the exact steps. To internalize and apply intelligently
the procedure, the human must understand the goals, objectives and
rationale. Complex, abstract information like this is best communicated in a
visual, entertaining means. Maybe 99% of your clients don't use it. Fine.
I'm not interested in that. I'm interested in benchmark information design &
deliver solutions, not large-scale, enforced mediocrity.

Microsoft has made a major push to make Windows Media interactive with HTML.
Most PCs shipped today have at least rudimentary speakers, a sound card, a
video accelerator card, etc. Flash can contain printed information and can
be assembled dynamically from a database of textual and media clip sources
(Macromedia Generator). These are not closed or "dead end" formats--they're
the cutting edge. Your ridicule of them proves my point--the large content
management system is too inflexible to adapt to these new technologies in a
timely and cost effective manner.

We've moved ahead with Flash executable based MPEG video installation
manuals instead of print for small office and home products. Much cheaper to
translate into myriad languages, much easier for the end user to understand
(meaning fewer expensive support calls), much easier to include warm fuzzy
entertaining stuff that gives customers good feelings about the company and
product, etc. The technology to author and deliver these kinds of solutions
is here now, but you would hold us back because these "dead end" formats
aren't easily supported by your system--there's little of the promised IM/KM
value gained from trying to manage these in your system.

I have, from bitter experience, little faith in content management system
designers who defend their approach by:
 1)Ridiculing the developers upon whom the system is inflicted ("Most of
them can't get it in the first week," you said. "Most of them don't like the
discipline imposed upon them," you said.) It's very easy to sweep away any
realistic concerns or objections they may have by resorting to straw man
tactics.
 2)Ridiculing or minimizing "dead-end formats" such as Flash (which is
actually growing in popularity and use) because they are, in fact, difficult
or impossible to mold to the leviathan management system.
 3)Proposing false dilemmas as you do when you say: "Where do the components
come from if not from a content
warehouse?" This is not essential for content management. Just essential for
your vision of it.

You keep trying to defend your approach by saying the system we've used is
poorly implemented. Yet the implementers of our system sit on OASIS and W3C.
You don't know enough about our system to criticize its implementation. So
you take my philosphical and economic objections to your approach to content
management and evade the issue by trying to characterize my experience as
limited and poorly implemented.

But all along, you've been proving my point. Your approach is overblown and
too costly for any kind of truly flexible and innovative instructional
design or tech doc shop. Instead of addressing my objections, you do what
many of your colleagues do--engage in straw man tactics to minimize the need
for any medium or format which doesn't easily fit your system and cover up
system usability problems by ridiculing the skills and professionalism of
the authors using it. (If you read Carroll, you certainly missed the point.)

Your approach is useful for shops that generate large volumes of material
which seldom if ever deviates in form or function (legal publishing, for
instance). In that case, there is sufficient economy of scale to warrant the
investment in your moon rocket.

More practical, scaleable systems of content management are used all the
time. Sure, there is great similarity between structures in a Carroll or
Mager approach. Sure, the textual content of help and print are similar (but
those movies you say no one uses are very effective in help and not possible
in print). Your goal of taking the human element out of the process is a
foolish one. What purpose does the information serve if not a human one? But
humans introduce too many warm fuzzy vagueries for a one size fits all
system. We must make man serve the machine!

NO. A concern for the end user must be the overriding one. And the design of
the information must focus on the needs of the end user and be entrusted to
people who have professional skill and education suitable to the task.

Content management is necessary and valuable, but must not inhibit or
otherwise impose artificial constraints on the information developers. Your
IM technologies are limited in that they do impose constraints--the more
sophisticated and over arching the IM system the more constraints and
limitations. Your response--to ridicule those requirements that don't easily
fit your system design is typical and unacceptable. Varied and incompatible
media can be supported as delivery systems as long as the human information
designer remains the control system for the content or "knowledge"
management process--but that means the human remains in the process and your
approach is unnecessary.

You propose the machine to eliminate the redundancies in human systems.
That's one solution, and a very inflexible one once adopted. A better
solution is to examine and refine the human processes, and develop IM tools
that support (rather than try to replace) the human component. Perhaps too
humble a role, eh?

Regards,
Glenn Emerson
-----Original Message-----
From: Tim Altom [mailto:taltom -at- simplywritten -dot- com]
Sent: Wednesday, November 22, 2000 7:32 PM
To: gemerso1 -at- rochester -dot- rr -dot- com; TechDoc List
Subject: Re: Real value (was implementing single-source) - demonstrated!


In point of fact, Glenn, we consult with companies about the business of
technical documentation as an adjunct to their business justifications of
single source. And yes, I'm well aware of both Mager and Carroll. And no,
their approaches are not exclusive. And finally, no I'm not confusing single
source with content management. Single source REQUIRES some form of content
management. Where do the components come from if not from a content
warehouse?

What you're not breaking out here is that single source can occur on many
levels. The simplest is a FrameMaker document with a good template design
and conditional text. You can them move up through levels of complexity to
full database/SGML implementation. The point of all single source is that
you do not need to rebuild to reuse. That includes multimedia components as
well as text. Single source is not used to construct multimedia components,
but that's the fault of the multimedia tools, such as Flash, that will not
accept a very wide range of imported files. They're what we refer to as
"dead-end formats" because, like PDF, they're not much good at getting
multiple formats out of them or into them.

The benefit of single source is not for one-shot deals like movies (which
99% of all tech doc departments will never use, for goodness sake), but for
ongoing documentation bound for help files, the Web, WBT, and the like. The
supposed wide differences between these media is a myth. Most of the Web
pages you see on large companies' sites don't exist until you ask for them;
they're produced on the fly, many from components stored in databases. The
very same material can be used in help files, in marketing materials, in
manuals, or any number of other places, with only their formats changed. The
content remains. So long as you know IN ADVANCE what the absolute structure
will be, you can reuse these materials without even knowing what they
contain.

And yes, there is great benefit in having more than you use. The only
difference is that it's now written down somewhere, rather than just being
in the heads of various human beings in the organization. We always have
available more than we can use at the moment. That's no reason for
ash-canning it all. Store it in an SGML or XML "flat file" and it's ready at
a moment's notice. If it's stored, it can be used. If it's not, it walks out
the door with the last person who knows it.

I close with a similar challenge to you...we have created several single
source implementations. How many have you done? Have you designed, built,
and tested such a thing, even on a simple level? Or are you just convinced
from one bad experience that nobody can build a workable solution? I just
concluded a job for a client who got a rather lengthy printed manual, and we
threw in the help file FOR FREE, because it took me all of a half-day to
make a fully-formed WinHelp file, with links and index keywords, thanks to
the use of our structured documentation methodology and Microsoft Word. We
could do it even faster if we'd used FrameMaker. It would have taken me, oh,
about 60 seconds to do. Not bad for something that doesn't work, eh? And, by
the way, the document methodology was patterned partly on Carroll's work.


Tim Altom
Simply Written, Inc.
Featuring FrameMaker and the Clustar(TM) System
"Better communication is a service to mankind."
317.562.9298
Check our Web site for the upcoming Clustar class info
http://www.simplywritten.com




^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Sponsored by SOLUTIONS, Conferences and Seminars for Communicators 
Publications Management Clinic, TECH*COMM 2001 Conference, and more 
http://www.SolutionsEvents.com or 800-448-4230

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.