If a museum really wants to try to develop their own system, I would
recommend using FileMaker Pro rather than Access as it is easier to use for
creating a simple functioning system than is Access.  If you are just going
to be doing data entry initially, you might consider a DOS-based system as a
DOS-based system is much faster to use for initial data entry than a
Windows-based system.

Any commercial system, such as our (Willoughby's) SNAP! for Windows which is
based on Access or our SNAP! for DOS which is based on Q&A, will have
involved man-months if not man-years of development by experienced
programmers and is not something you can duplicate easily in your spare
time.  And, of course, it's not just time that is required to get it right
but some familiarity with the tools.   If you hire a student or local
programmer to develop a system for you, you have to weigh the economics of
what you will have to pay them compared to the cost of a commercial system
(our SNAP! for Windows is $3995, SNAP! for DOS is $1595) as well as the
usefulness of the end product.  I.e., how many days of your time or a local
programmer's time does this represent and can he/she replicate the
functionality of a commercial system within this timeframe and does doing it
yourself outweigh the inherent advantages of going with a commercial system
(support, user group, adherence to museum standards, free upgrades, etc.).

On the other hand, developing your own system will provide you with a deeper
understanding of data issues, of your own data, it's fun (for awhile) to do,
and since many museums do not view staff salaries as an expenditure, it may
be the only route open to you.  If anyone is interested in seeing a
straightforward yet fairly comprehensive design for a museum automation
system, just write to us for our SNAP! for DOS 50-page description or visit
our web site (willo.com).  The fields we incorporated into SNAP! for DOS
were based on an extensive analysis of over 120 manual documentation systems
and the fields represent over 99% of the data that is typically recorded in
the primary source document of any museum (catalogue card, ledger book,
etc.).   While the design of SNAP! for DOS is proprietary and I'm not
encouraging you to take it and replicate it, it will give you an idea of the
kinds of elements that might be included in an entry-level system and the
features and functions you might want to consider incorporating (help
messages, pop-up lists, validation, etc.).

Another potential list of fields for inclusion in a do-it-yourself system
may be found in the Museum Documentation Association's (MDA) Spectrum
document.  The MDA is in the UK.  Their web site is
http://www.open.gov.uk/mdocassn/index.htm.  Spectrum is a museum
documentation standard and is written for use in both manual and automated
systems so it's primarily a list of what information you should record about
objects rather than a list of fields derived from these broader categories
for inclusion in an automated system but Spectrum is an amazing document
(also available in electronic form) and will be useful to anyone responsible
for maintaining object documentation.

Lenore Sarasan
Willoughby Associates, Limited
The Museum Automation People
266 Linden Street
Winnetka, Illinois  60093
http://www.willo.com (WEB)
847 866-0401 (VOICE)
847 866-0409 (FAX)


>
>Date:    Thu, 14 Aug 1997 18:15:01 GMT
>From:    Stephen Ringle <[log in to unmask]>
>Subject: Re: Art museum database (Microsoft Access)
>
>We transferred all data in our old, DOS text based database to Access this
>past spring.  The database structure and much of the user interface was
>designed by me, with input from computer science faculty here at the
>University of Maine.  We also enlisted the aid of a C.S. major to do much of
>the "coding" and to assist with the receiving end of the data transfer.
>
>Most of what we have accomplished so far works great.  But when I
>want to add features or enhance forms or facilitate routine actions, learning
>the program is a real challenge.  I often turn to the Computer Science
>faculty for assistance.
>
>My advice is: if you're not on a campus where help is handy, don't build it
>yourself, unless you want something extreemly simple.  (I tend to want to try
>very sophisticated actions, like automatic lookups if an entery fails to
>bring up a valid object record, with understandable error messages, cascading
>updates to current-location and location-history tables, etc.) Otherwise,
>convince your superiors to invest in the Willoughby Group's Snap for windows,
>or some other off the shelf collection management software which has support
>groups and help lines you can call.   Current software is sufficiently
>sophisticated for users, without pretending to be programmers.
>
>My 2c.
>
>
>
>In article <[log in to unmask]>, [log in to unmask]
>says...
>>
>>Hi,
>>
>>we've been using Access for a couple of years now and have developed
>>several systems for managing collections management information related
>>to our collections.  If you can define what you are trying to do a
>>little more specifically (object-level catalogue/inventory, accession
>>file, etc.) I'd be happy to send you the background on what we've done.
>>
>>You can respond to me off-list at [log in to unmask]
>>
>>Richard Gerrard
>>Registrar, Colelctions Management
>>Heritage Toronto
>
>--
>      ============================================================
>      Stephen B. Ringle, Registrar             [log in to unmask]
>      University of Maine Museum of Art
>      5712 Carnegie Hall, Room 109              vox: 207-581-3257
>      Orono, Maine   04469-5712                 fax: 207-581-3083
>      ============================================================
>
>