TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Need for new paradigm/toolset (Was: Impact of info expl...)
Subject:Need for new paradigm/toolset (Was: Impact of info expl...) From:Emily Skarzenski <eskarzenski -at- DTTUS -dot- COM> Date:Fri, 22 Mar 1996 11:35:31 CST
Chet Ensign wrote about the need for a new, non-linear paradigm in
information development. As he said, we need a tool "that merges the best
of wp/dtp technology with the best of client/server database technology."
Chet is right on target.
I see a trend in software development toward "customized" systems that
exist somewhere between an off-the-shelf and a completely custom
solution. These products are developed as an 80% solution, where the
other 20% is client-specific customization, which is either done by the
vendor, an outside consultant, or technical professionals at the client.
This allows software vendors to market their wares as customized, but
reduce the costs involved in developing a completely custom solution.
Regardless, customers want to end up with manuals and online help that
are 100% specific to their product.
The problem this poses for documentation is something like this:
-- The end-product doc sets have a good deal of content in common.
-- It's impossible to predict exactly which content will be shared.
-- It's impossible to predict how the customized parts will be
To me, the solution begins with the ability to modularize information down
to the topic level and thread together the appropriate pieces on demand.
We also need to be able to save the "recipe" for version control. And of
course, the output format should be publication-ready.
SGML does some of this, I know -- but requires a lot of setup and
configuration. FrameMaker's conditional text feature indicates a
recognition of the problem, but is far too limited. Why, I wonder, isn't
there a shrink-wrapped solution for a documentation scenario that is
becoming increasingly common?
Emily M. Skarzenski
Deloitte & Touche/ICS - Chadds Ford, PA
eskarzenski -at- dttus -dot- com