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.
Re: Need for new paradigm/toolset (Was: Impact of info expl...)
Subject:Re: Need for new paradigm/toolset (Was: Impact of info expl...) From:Tim Altom <taltom -at- IQUEST -dot- NET> Date:Fri, 22 Mar 1996 12:30:00 EST
At 11:35 AM 3/22/96 CST, you wrote:
> 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.
If you've spent much time in the mainframe world, this has been the norm for
decades. A company develops a big-ball package, then either a third party or
the original maker kneads it into shape for the individual application.
> 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?
Because shrink-wrap won't be the answer. The conditions you're talking about
are so hideously complex that even software isn't enough to cut it down to
size. It requires the services of documentation management professionals,
people who specialize in archiving and retrieving drawings, chunks, and
other parts of documents. I found it interesting to meet these people, and
we even had a local STC meeting about this very subject. To anyone with an
interest in this area, I'd recommend you contact the local chapter of AIIM
(Association for Information and Imaging Management) and hook up with them.
301.587.8202 gets you the national office.