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: Impact of information explosion on our profession (Was: on custom-built documents & feature databases...)
Subject:Re: Impact of information explosion on our profession (Was: on custom-built documents & feature databases...) From:Tim Altom <taltom -at- IQUEST -dot- NET> Date:Tue, 19 Mar 1996 15:00:00 EST
At 09:38 AM 3/19/96 -0600, you wrote:
>Technical writers all,
><much great stuff reluctantly snipped to save room>
>What I think we need is a revolution in the tool set, one that merges the best
>of wp/dtp technology with the best of client/server database technology. We
>need a tool that allows us to write what is the writable part of our
>information -- the words and organizing principles that provide the context for
>conveying information -- yet at the same time populate it with facts, stats
>and details from the database component of the package. For example, I am
>looking at a picture of a semiconductor memory register. It shows the register
>names and beginning and ending offset addresses. Somebody wrote this using a
>table editor. Yet this graphic could almost certainly have been automatically
>generated straight out of a product design database. That's the sort of directi
>on that I am thinking here.
>I have no idea what this tool looks like. No yet. But perhaps, if we talk about
>it, we can come up with the requirements for such a tool, propose a
>hypothetical design. And maybe, if we can express what we need, the product
>manufacturers out there can build it.
>Well, that's what I'm thinking about. If anyone wants to jump in on this, I am
>all ears.
You're right, Chet. We've been staggering toward that future for decades
now. Just as the first cars were buggies with internal combustion engines,
we're still producing manuals and other materials with linear capabilities.
Of course, SGML comes to mind as the sort of thing you're talking about, but
I sense that you're looking deeper than a tool. Rather, you're searching for
a (buzzword alert!) paradigm that shifts us from DTP just as surely as
aerodynamics changed the shape of the car and ergonomics changed the insides
of it.
I think there's a wall in the way of such a "scattershot" paradigm, though,
and it's the same bugaboo that plagues database designers. Getting the data
into the thing isn't the problem. It's finding it and getting it back out
and then incorporating it in the right spot. In any database extraction
scheme there are millions of possible mistakes and perhaps only one right
configuration. Your graphic would be sitting cheek-by-jowl with hundreds or
thousands of others, some current, others obsolete, most similar enough to
their neighbors to be mistaken for each other. So...how to tag it, find it,
and plop it (finally) on a medium?
Or is this just another example of the 2-D thinking you're seeing as the old
way of doing things? Is there a way to incorporate chaos into this to
simplify matchups? We've been using the brute force method for years,
tagging everything that goes in and then praying that we've tagged it with
the right thing when we try to find it. Is this too linear? Are we looking
at this as yet another example of a bottom-up construction?
Damn. Too many questions and not enough answers. Just another day at the office.
