Judy Donovan, Recorder

The VR Software Users Discussion Group meeting began with an introduction of the attendees and--to help tailor the discussion--each person was asked to state what software their organization is currently using.  Attendees were Maureen Burns (U.C. Irvine) who has migrated from VRMS to Re:Discovery; Trudy Jacoby (Trinity College), former VRMS user, now using FileMaker Pro; Pam Krupansk (Tufts) who uses IBM DB2;  Andy Gessner (Columbia University) who uses FileMaker Pro; Lynda White (University of Virginia) who is migrating from MARC records on SIRSI to EAD (Encoded Archival Descriptor); and Judy Donovan (Drexel University) who is investigating VR software to build the slide collection database.

Discussion Leader Trudy Jacoby gave a brief history of the Software Users group.  It began in 1990 as a software discussion group for VRMS (Visual Resources Management System) users.  VRMS was the most-used software for VR collections at the time.  It had one important advantage over any of the other software products on the market at the time in that it was developed in a slide collection specifically for  the management of surrogates.  It was an excellent program for enhancing procedural flow, generating reports and creating slide labels.  Since VRMS was the most widely-used software, the discussion groups truly focused on software issues specific to VRMS.  By the mid-1990's the VRMS software developer/owner decided not to continue developing the software, nor would he sell or license the code that ran it to institutions interested in further developing it on their own.
Institutions began to migrate from VRMS to newer VR programs such as Re:Discovery, FileMaker Pro and Embark.  Some of the program vendors even offered support to help migrate the VRMS records to their software.

By the time of the Philadelphia conference in 1998, there had to be two sessions at both VRA and ARLIS to accommodate the interest in software discussion, triggered for the most part by the fact that many institutions were migrating to new software.   Sessions began with general issue discussion, then the groups broke into subgroups based on which software they were using or migrating to.  At the time it was basically FileMaker and Re:Discovery that were the dominant products.  Migration issues were also handled by listservs, for example VRFMP-l (run by Susan Jane Williams at Yale) which offers help for those migrating from VRMS to FileMaker Pro.

Now that a majority of people have migrated to a new software, there is less worry about software interfacing and compatability.  The focus now is more on getting the new software to handle the requirements of VR collections.  It should be noted that since VR collections are a miniscule market, most software developers are not programming to their unique needs.

Next, individuals in the discussion group shared their experiences with specific software products.  Trudy Jacoby described the New England consortium that she belongs to that supports FileMaker Pro.  Six institutions that used VRMS (Brown, Trinity, Wesleyan, RISD, Roger Williams and Smith) formed a consortium to share knowledge, programming expertise and product support assistance as they all migrated to FileMaker Pro.  Norine Duncan at Brown University is working with a FileMaker consultant to construct data records.  This consortium had two principal requirements:  One, that they not be dependent on one software developer and Two, that no one individual in the consortium should become the sole user support person.  The consortium is setting up a fund to pay FileMaker experts to serve members.  Any consortium member can use any FileMaker consultant as part of this fund.  They plan to set up a website that will share object records and cataloging (OCLC-based).

Maureen Burns shared her thoughts on migrating to Re:Discovery (this information she presented at the VR Software Users meeting in Los Angeles).  She candidly admitted that she wished she had  joined Trudy's consortium (!).  She said that Re:Discovery offers good vendor support; one of the reasons UCI selected it was that the vendor handled the actual migration of the data as part of the purchase price. Re:discorvery  was written in FoxPro.8, which is the same program that the last version of VRMS was in, allowing for some familiarity in function. The program is similar to VRMS, but not similar enough (procedurally) so the transition was very "painful".  She converted over 200,000 records from VRMS to Re:Discovery. The software offered the option of adding whatever fields the user needed.  She said that they wanted a correlation between the number of fields and what gets printed on the labels.  In terms of mapping the data from the old to the new systems, the VRMS fields that posed quandaries were the Artist/Site/Era field and the "Other" field.  In the former, three very separate things were all thrown into one field and tied to one authority table.  When they tried to separate them out in Re:Discovery, the authority would not function correctly and they were forced to combine them back into one field.  The "Other" field in VRMS--where one could find data related to measurements, media, museum accession numbers and other miscellaneous information-- had to be dumped into a "notes" field in Re:Discovery.  The end result is that UCI ended up altering the existing Re:Discovery database so much that it is not working as well as they had hoped.  One of the major problems being label printing.  Maureen is publishing an article on her experience with Re: Discovery migration in the VRA Bulletin.

Maureen also summarized what Vicki Aubourg from California Polytechnic University had reported about her experience with EMBark at the Los Angeles VRA meeting.  She chose EMBark for several reasons:  The price was reasonable, it has flexible customizing capabilites for data entry; multiple searching options with full Boolean and simple search capabilities, it has exporting and importing capabilities for tab delimited text files, simple image acquisition and image management, among others.    She said that when her database reached 900 records, the system began to slow down, necessitating that they store only the thumbnail images in the database and the higher resolution images are stored elsewhere. Other disadvantages are that source files need to be updated when they are moved or renamed and that substantial preparation time is necessary to customize fields and develop choice lists (but that it is an advantage to have the option for site specific customization).

Maureen mentioned that VRA presenter Lynn Lickteig from the University of Colorado at Denver offered "four truths" she learned about planning imaging database projects:  1) the team approach is essential, and you should include faculty staff and students; 2) you will always need more money than anticipated so develop a budge and then add 25% more ; 3) There is always more money for "things", but rarely money for people--staff calculations are usually underestimated especially in the area of cataloging; and 4) There is no such thing as perfect equipment, so purchase the most for your money but expect and anticipate problems and treat your tech staff "like royalty".

The group agreed that the VR division should publish a compendium guide on VR software, listing what's good and bad about each.  Judging from the presentations at VRA/Los Angeles, there is enough experience with the major software products out there that such a guide could be written.

Finally, the group resolved to remove the term "software" from its title (it should be known in future as the VR Issues Discussion Group.  Consensus was that VRA should offer specific software discussion groups, while ARLIS should focus on issues related to visual databases.