Automated documentation systems

>which "programs"  are being used for documentation of treatments etc on
>a PC.  Currently all our reports are paper based which is both slow and
>complicated.  We would like to convert this to a computer based system.

Peter,
Your question is a big one and I haven't the time or energy to do it
justice, so I will be a bit brief and invite you to phone me to discuss
the subject in greater depth.  First, by way of background, you should
understand that tend to see most of the world as one sort of database
problem or another ("Hmmm, the boards are detached? I wonder if a
database will help..."), so I'm not being off-hand when I suggest
something that may seem counter-intuitive:  unless you are prepared to
make database design and maintenance a major part of your life (like a
hobby, or if your lucky, an obsession), you should *not* be thinking of
database management systems (DBMS's) as your primary documentation tool.

Why?  Because what we lump together as "documentation" is really a
rather complex group of tasks and while conceptually a DBMS is the ideal
tool for managing each of these tasks, as a practical matter, it takes
far too much effort (and some considerable skill and knowledge) to pull
it all together.  Think of some of the things you need to deal with:

    1.  A logging function.  Keeping track of what is in the lab, who
    sent it, when, where it is right now, when it is due back, etc. This
    is pretty simple and can be handled nicely with even a simple
    flat-file manager, although a DBMS will be better.

    2.  Description, Condition, Treatment Reports.  These are terribly
    complex documents, ranging in size from 1 page to many (I have some
    that run to more than 50 pages) and often contain material that
    *cannot* be included in the database records (eg photocopies,
    photographs, signatures).  Although all reports may share a few
    features (eg some bibliographic info, logging info) and all *should*
    share some other "parts" (descriptions of methods and materials of
    manufacture, statements of conditions, proposals, etc.), obviously
    each report has some unique features.  One may have a sewing pattern
    and a collation; another may have a detailed narrative description
    of covering methods; another may describe secondary, tertiary, and
    quarternary mounts (sneakily I remind everyone that our domain is
    heterogeneous); another is little more than "This trade case had a
    loose front board, so I did XYZ to it". Now it is pretty easy to set
    up a simple database to log work that is in the lab and it is easy
    enough to get it to produce something that looks like a treatment
    report, but to work up a system that lets you generate *serious*
    treatment reports (ie reports that are as complete, subtle,
    detailed, varied, complex, and meaningful as those you produce by
    hand, is to say the very least a non-trivial problem.

    3.  Production statistics (for people in institutions).  This can be
    tied to the logging function and isnt, in and of itself, too
    terrible a problem.

    4.  Billing (for people in private practice).  Somewhat more
    complicated, especially if you have staff and also need to do
    serious accounting, in which case you probably want some way to
    connect your lab database to your general ledger, etc.  phew, that
    could be fun.

    5.  If you deal with outside contractors (for institutional people)
    or subs (for people in private practice), you will also want to (a)
    track materials as they are shipped/received (b) keep track of the
    contractor's treatment reports (c) produce packing lists, invoices,
    etc.  This can get a bit complicated.

    6.  Photographic records (here I am speaking of information *about*
    your photodocumentation, rather than the photographs themselves:
    film type, exposure info, lighting info, filtration info, etc.

Right now, there are no off-the-shelf programs for book conservators,
and for that matter, I'm only aware of one for general practitioners (I
haven't seen this, but I can dig up info on it if you are interested.  I
seem to recall it was aimed at objects conservators, but I may be
mistaken). Of course many people (and several on this list) are rolling
their own, and it is hoped that it won't be too much longer before some
of us are happy enough with what we've done to make them available.  A
friend of mine is writing an application that he is planning to make
available (not for free, as this kind of software development is a very
significant investment of effort), and from what I saw of it, it will be
superb.  At Stanford we are developing a system for inhouse use, but I
suspect that as it fleshes itself out, we will probably make it
available.  But these are a bit off into the future (well more than a
year in the case of the Stanford stuff).

So, having been set off the yellow-brick road for a while, you still
need something to get the job done.  If you accept my suggestion that
trying to make a DBMS do everything for you is a major headache, , you
will almost certainly be happier if you use several tools, each for a
limited purpose:

    a *good* word-processor (and it's worth taking some time trying
    several, because what may have been adequate for writing letters and
    memos may not be very helpful when you are trying to automate the
    production of treatment reports).  At a minimum you want something
    that has a decent macro facility (preferably a real macro language)
    and perhaps a "Glossary" function (used to replace abbreviated codes
    with canned text.  With the word processor, you can spend a
    reasonable amount of time (as opposed to most of your waking life)
    preparing a fairly full set of report forms, some of which you will
    fill out on the machine, and some (gasp) using a pencil.

    A DBMS or flat-file manager (the former will give you more power and
    room to grow, but the latter may be easier to use (though if you use
    a DBMS (eg dBase) as if it were a file manager, it may not actually
    be any harder to use).  You can use this for logging, production
    statistics, maybe billing (though here you probably want to start
    thinking of using a full-blown DBMS).

    You will probably want a stand-alone keyboard macro package to help
    with entering canned text, and perhaps a stand-alone form design
    program.

>These programs should also allow for cross referencing, lets say,
>rebackings and pre 1600.

Well, it sounds simple but everything has a cost (see the rules of
Database below).  To take this very good (and simple example), if you
want to find all the items printed before 1600 that you have rebacked
(note that I already made that a much more limited question, as I am
limiting it to *your* rebacking and *imprints* before 1600 (lots of
other things could happen before 1600 and conceivably you could give a
damn about them).  Well to do this search you almost definitely will
need to assign an date-of-imprint field (trying to pick it out of a
callnumber (or other) field wont work for reasons I wont go into here).
You will have to be scrupulous about entering a date, which sounds easy
enough, except you frequently don't know a date.  Or don't care.  Or you
have made one record to represent a group of items with varying dates
(2312 Sermons).  The rebacking bit sounds easy enough, except that as a
practical matter you are probably going to need to maintain a separate
keyword field (ie you could of course search for every record in which
the Treatment field contains "reback" but (a) it will probably take a
week and (b) it will pick up "I decided not to reback this volume"). And
you will need to use a restricted vocabulary, which means you will need
to work up some sort of vocabulary control mechanism, perhaps an
authority list (allowable keywords),

and the beat goes on...

So if you have a *real* need to do this sort of thing and it is worth
the *real* costs of doing it (or if, as I do, you just sort of enjoy
this kind of stuff), then yes, you can make it happen.  But it ain't
free.

>It would be great if total computer literacy >were not a requirement
for their use.  Am I asking to much?

Yes, really you are.  Even if you adopt the simple regime I describe
above, if you are going to commit your treatment records to the
safekeeping of a machine, you really must have at least one person
around who understands the machine and its rites.  I don't mean that you
need a programmer or a hacker, but someone should know there way around
and know what to do when things break.

The Rules of Database:

    A Database is a black hole (thanks to Stanford's Systems Office for
    this one).  Once committed to maintaining a database, you will find
    everything in your universe being sucked into it.  Including your
    time (as I write this I am doing database maintenance on another
    machine.  How do you want to spend *your* Saturday nights :-)

    Everything costs something.  Usually too much.  If you think you
    want to QUERY XYZ sometime three years from now, maybe, if it seems
    like a good idea at the time, do you really want to spend time every
    single day adding data to field ABC just to make that query
    possible?  Sometimes it really is easier to browse through a pile of
    paper reports. Or lie.

    Garbage in, garbage out, but it didn't look like garbage when you
    put it in.

Hope this helps,
Walter

                                  ***
                  Conservation DistList Instance 5:32
                Distributed: Tuesday, December 10, 1991
                        Message Id: cdl-5-32-002
                                  ***