Re: on custom-built docs & feature databases...

Subject: Re: on custom-built docs & feature databases...
From: Joyce Flaherty <flahertj -at- SMTPGW -dot- LIEBERT -dot- COM>
Date: Sun, 17 Mar 1996 14:20:45 EST

I'm working on a similar project. I gave up the book
metaphor long ago to move toward building an online
information database. My database includes information
from training and service manuals, customer manuals,
schematics, illustrated parts, and troubleshooting
(expert system)--two vendor pkgs, three home-grown and
a home-grown interface.

All is well, but research continues and
I am now involved in evaluating SGML as a possible better
way to store the information. Our objective is online
information management. The functional specs most
certainly include selecting a set of topics that
satisfy certain conditions, such as the *features* you
describe.

I don't know that I can be a big contributor to the
thread at this time, because I'm in the learning stage
with my nose in my books. OTOH, I have a handful
of SGML experts helping me out--thanks to this list!
They might be willing to contribute.

1)-Authoring Interface--I have a first iteration
authoring interface that I am going to introduce
to our doc department for review next week.
2-Database--I also have a prototypic database in
place with tags that I am calling data elements
(my mainframe background always getting in the way).
3-Hardcopy--I haven't figured out yet how I am going to
get the retrieved information into an application to
produce hardcopy in a format that doc finds acceptable.
Importing the SGML is the ticket. I just haven't
selected the pkg. 4-Online--We are dedicated to
royalty-free viewers for the online display. Although
several pkgs export SGML-like code, only the more
expensive ones import and the viewer is not free. So
for now, I am *stuck if you will* with the
application-specific scripting that I write.
5-Recordkeeping--The signout and turnover routines will
handle all of this (endless possibilities here). This
part is easy, so I (we) will address it later in the
project.

At the risk of starting a full-scale list upheaval,
dare I mention that taking the tool expertise and page
design function away from the tech writers is another
objective. I have read that page design can consume
from 40%-an amazing 90% of a writer's time. I would
like to see more of this time spent putting words that
communicate into the computer.

Finally, I would like this thread to continue, though
my own contribution is strictly on the fly.

joyce flaherty
flahertj -at- smtpgw -dot- liebert -dot- com

______________________________ Reply Separator _________________________________
Subject: on custom-built documents & feature databases...
Author: cklein -at- bnr -dot- ca at INTERNET
Date: 3/15/96 9:57 AM
<snip>
I am currently exploring futures for our documentation suite.
We have several thousand pages which are constantly and
selectively affected by the introduction of new development
"features" to the product. Our customers don't shop on a per
"feature" package. Instead they, procure sets of features.
Some features will always be purchased together. We need the
ability to provide any feature permutation.

The problem: how will we selectively compile their
documentation to match their feature sets? how can
we set up feature databases with user-oriented info
(not functional specification) that serves both
product information and training needs?

Is anybody out there currently working on this problem?
Do you (does he/she/them) care to discuss your (his/hers/
their) solution in this forum? Moving forward is part of
the solution but retrofitting it to existing pages is
another...


Previous by Author: Re: Online with IBM's BookManger
Next by Author: Re[2]: FrameMaker Required
Previous by Thread: You can't please all the people. Formerly: FrameMaker Required
Next by Thread: Re: on custom-built docs & feature databases...


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads