Re: Real value (was implementing single-source) - demonstrated!
HALL Bill wrote:
> Andrew argued that the cost of training authors to work productively in such
> a system would be prohibitive. The fact is that it took us one day to teach
> authors (who had no prior contact with either SGML (or FrameMaker) the
> mechanics of using the SIM-based work flow environment and the basics of
> structured authoring in FrameMaker+SGML's authoring interface, and a week or
> less of ad-hoc support before the authors were exceeding their productivity
> in the WordPerfect environment.
I think that a distinction has to be made between writing in a
markup language on one hand and designing the DTD, the style sheets
and checking that a document is well-made and valid on the other. In
many cases, you could probably get a tech writer started with about
an hour's instruction. The actual design work takes longer to work.
Of course, developing a DTD and style sheets is part of the initial
investment. But the important thing is that writer adaptation to
structured document authoring, using a powerful and intuitive
authoring tool such as FM+SGML took about 1 week,
after which significant productivity gains were already evident.
An investment that begins paying off almost immediately is
almost certain to yield a large ROI. Let's say the DTD/style
sheet development cost was $50,000, and you have 5 TWs at
an annual cost (salary plus overhead, recruiting costs, and
miscellaneous) of $100,000 per writer. A 10% productivity
improvement would recover the investment in 1 year, even
without the accoutrements of an information management
system. Add all the bells and whistles of a modern information
management system, and Bill estimates the savings at
$100 million Australian, which ought to perk up anyone's ears,
no matter how small their operation.
So, let's say you decide your shop is just barely able to
justify the cost of converting to structured document authoring
now, with the hopes that you'll be able, sometime in the future,
to afford the additional cost of an information management
system. You have two options:
1. Defer the adoption of structured document authoring until
you can afford the cost of an information management system,
and continue authoring unstructured documents the old way.
2. Adopt structured authoring now.
Selecting Option 1 means that you'll be unable to prove to
management that the structured document approach, in
and of itself, yields major benefits, nor will you be able to
show concretely how the addition of a powerful information
management system for structured documents will yield
even greater benefits. Furthermore, by piling up more and
more unstructured legacy documents, you are substantially
increasing the cost of admission, because legacy document
conversion is a significant initial cost factor.
Selecting Option 2 means you'll be in a strong position to
convince management to implement a full information
management system earlier, and at less cost.
At what point is a project large enough to justify the effort? Would
the switch to a mark up language be worthwhile for every project? Or
is it possible that, on much smaller projects, the effort and the
cost wouldn't be worth the results?
I have no opinion on these points; I'm only asking them because I
can't help suspecting that the project in Bill's example is probably
much larger than many tech writing projects, and I wonder whether
this observation is relevant to the discussion.
The threshold at which the value of structured documents
becomes manifestly evident is much lower than most people think.
True single-sourcing means that all content must come from a
single managed and controlled source, such that all users
(human and non-human) can retrieve only the specific
information they require, and are guaranteed that it will be
the most current and valid information available at the
instant they retrieve it. There is only one way this capability
is realizable, and that is for the content itself to be physically
stored in a database.
To get information into a database, the following
requirements must be met:
1. The database itself must be Unicode-compliant so that it
can accept any character in any language, including special
languages such as mathematical chemical, and musical
notation.
2. The content must be structured and tagged so that each
individual structural component can be separately stored in
the database.
3. The content must be stripped of all proprietary formatting,
unless it is stored as a Binary Large Object (BLOB)
such as graphic, video, or voice information.
4. To enhance the retrievability and control of the information,
metadata, in the form of element names, attributes and
Reference Description Frameworks (RDFs) are needed.
5. Each "Resource" stored or pointed to in the database needs
a Universal Resource Identifier (URI) so that hyperlinks can be used to
retrieve it. A resource can be anything from an entire document
down to an individual structural component or BLOB.
To fulfill the diverse requirements of human and non-human users,
the information retrieved from the database must be transformed
and formatted, using middleware, to meet the needs of
each requesting user.
XML, including XLinks, XPointers, XSL, URIs, Namespaces, and RDFs,
is the only metalanguage that is fully capable of satisfying all of
these requirements, including its designed-in compatibility with
database storage as described above.
Using XML as the method for information interchange also means
an end to the enormous costs, time delays, and error propagation
incurred in conversions between incompatible proprietary formats.
Any DTP or word processor can be used, so long as it can import and
export XML instances, and preserve the validity of their structure while
they are being modified. This factor could potentially set many TWs
free from the onerous burden of MS-Word, which they are required to
use simply because everyone else in the company uses it, and it's
not feasible to convert documents between Word and a far better
DTP such as FrameMaker.
====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory -at- primenet -dot- com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo -at- omsys -dot- com with "subscribe framers" (no quotes) in the body.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
Previous by Author:
Re: Real value (was implementing single-source) (Long)
Next by Author:
The Consequences of Embedded On-Line Help
Previous by Thread:
Real value (was implementing single-source) - demonstrated!
Next by Thread:
RE: Real value (was implementing single-source) - demonstrated!
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads