Our library and computing staff
worked together to create an in-house customized online catalog. In this
article, we'll discuss the process and the lessons we learned. In our company,
Packer Engineering, we have a tradition of building much of our own equipment.
We simply extended this philosophy to the library!
and you too can create your own customized online catalog.
Packer Engineering, Inc.
a multidisciplinary consulting engineering firm, was founded in 1962 by
Dr. Kenneth F. Packer and is headquartered in Naperville, Illinois. Our
engineers study fires and explosions to learn what caused them, investigate
accidents involving people and machines, analyze failures involving machinery
and equipment, assess product designs to make sure they work and find ways
to improve them, inspect buildings and structures to determine their condition,
and conduct customized and routine materials testing.
At Packer Engineering, everyone
practices the scientific method. Our engineers apply a systematic methodology
to obtain the correct answers to the questions and problems they are presented
with. A scientific approach requires a foundation in the discipline literature,
and therefore our company has always supported a library. The Packer Engineering
Library (PE Library; http://www.packereng.com/html/pelibrary.html)
has grown from one small room with an in-house accession scheme to a collection
of 5,000-plus monographs, current and historical standards and regulations,
over 200 journal titles, and several thousands of pieces of gray literature,
ranging from automotive profiles to vertical files on safety topics.
In 1995, only secretaries
had desktop computers--stand-alone machines running Microsoft Windows 3.1.
The library had one general computer with the same configuration. By 1998,
computing staff had implemented a Novell network, workstations for all
employee desktops, and Internet and external e-mail access via a T-1 line.
As our needs evolved, the operating systems were upgraded to Windows NT
and Windows (95 or 98). The hardware has varied, but is mainly Intel processor-based.
This blend is our current configuration.
The first PE Library online
catalog was set up in 1990 using Nutshell Plus II, a DOS-based package
from Fairhaven Software (http://www.fairsoft.com).
While this package included an easy-to-use reporting function, it did not
provide much flexibility in search construction. Nevertheless, it served
library staff needs for several years.
We Needed to Upgrade
IT manager Patrick Farrell
developed the first in-house library computer system in 1996. Dubbed "Card
Catalog," it was created in Delphi (http://www.borland.com/delphi)
under Windows 95. Card Catalog expanded the searching function of the original
Nutshell online catalog to include all the key bibliographic fields of
author, title, and publisher, as well as some subject searching. Soon after,
PE Library staff acquired desktop computers, and we added the Card Catalog
program to those machines.
The Nutshell record format
did not prove easily transportable to a format Delphi could read, and we
didn't have the funds for temporary data-entry help. So we began the Delphi-based
Card Catalog with new records, and with no retrospective conversion. PE
Library staff continued to use both online catalogs. "Card Catalog" was
a very useful custom application, but since it did not incorporate earlier
catalog records, over time it proved frustrating to use.
Neither the Nutshell nor
the Delphi online catalog was MARC-compliant, but both encompassed all
standard bibliographic citation elements: author, title, publisher, place,
date, and notes. Both catalogs were installed on library machines only,
not companywide. Customers had to either come to the library to search
the catalog or request that a library staff member search the catalog for
Toward the end of the '90s,
several parallel needs regarding access to library materials and records
came together. Library staff wanted an online catalog with robust searching
and output, something more like the features available with commercial
integrated library systems. Packer Engineering management wanted to see
more up-to-date library automation as part of a move to expand the company's
computer functionality. Many of the engineers wanted access to the library's
holdings from their desktops. In particular, younger engineers just joining
the firm were accustomed to relying on university library automation systems
with desktop access. While they did not demand a sophisticated online catalog,
many remarked that they wanted to be able to search basic citation information
just as they could search author, title, and date. In short, both the company
and the national computing environment raised everyone's expectations for
an online catalog.
Developing a Catalog
In early 2000, library
staff frustration with the limitations of the dual, DOS-based catalogs,
computing staff frustration with frequent service calls regarding these
catalogs, and management's urging to update the library operation led to
our decision to do it ourselves. Innovation is encouraged at our company,
so the only obstacle to developing a catalog was lack of time. Some database
programs were already in development for tracking company jobs and inventorying
file photos, so we designed our Library Services Database (LSDB) along
the same lines as these programs.
The Library Services Database
was a bit more challenging than its predecessors because it was to be installed
on every workstation, so it had to work with several different hardware
configurations, and with MS Windows 95, 98, and NT.
It took several meetings
and revisions for us to develop a format for the LSDB that would meet library
staff needs. The first part of the database we created was a Books and
A/V catalog. We thought it wise to start with the most standard example
of a library online catalog, and then model catalogs for our other collections
on this one.
The LSDB includes both search
and find functions. "Search" is geared toward public users--search results
appear in a window, and users can scroll through to display each record.
Several of the engineers we consulted noted that they wanted to see all
the search results at once, in some fashion. "Find" was the original query
process; it retrieves the same results as Search, but does not display
them in a list. We may decide to discard this function in future refinements.
Boolean searching is not possible in the LSDB. The programming required
to implement this is really extensive, and may not be practical unless
we get additional help.
The LSDB, as it was originally
developed, includes both an order function so library customers can request
materials ("Order" sends a record to all library staff as an e-mail.) and
a printing function. We have expanded the original printing function significantly,
as we note below. We use MS VisualBasic 6 to drive all of the LSDB forms.
All of the data records are stored in MS Access.
Collecting and Organizing
Once we set up and agreed
on the basic database structure, the next challenge was importing the information
from the earlier library catalogs. Nutshell did not provide any structured
options for exporting, but it was critical to import these original records
into the new system so it would be complete. So, all of the Nutshell records
had to be exported as text, and then the resulting text file was edited,
record by record, so that it was clearly space-delimited. Finally, the
data was imported into Access.
The Delphi Card Catalog
included an option to export in dBase format. The exported file was easy
to import into Access.
The next step was designing
LSDB display/report and input screens/forms. We created all of these using
Seagate's Crystal Report 8 (http://www.seagatesoftware.com/products/crystalreports/default.asp).We
chose Crystal Report because our company already owned a copy of the application,
and it had been used successfully for report writing for other Access-based
programs. All the fields in an LSDB record are displayed as text boxes
that are linked directly to the Access database.
One of the key final steps
in the original development of the LSDB was to add a password-protected
administrative login function, so only library staff would be able to add
and delete records. The public access view, in addition to being read-only,
was extended so that the charge function would not display the name of
the person who had borrowed the material (see below).
|Innovation is encouraged
at our company, so the only obstacle to developing a catalog was lack of
Testing Our Science
Refining and testing the
LSDB was done in a catch-as-catch-can manner. While this project was important
to all of us and to company management, the billable work to our company's
clients had to come first. Despite time crunches, we have managed to seriously
test and augment the LSDB.
One of the first things
we implemented was to make every field in each catalog in the LSDB searchable.
(This was more a library staff need than a customer need, but customers
have also come to use the feature.) The original fields in the Books and
A/V catalog were as follows:
As part of the first refinement,
we added a charging function, with three new fields:
Facility (Packer Engineering
has a Warrenville, Illinois, shop and a satellite office in Troy, Michigan,
as well as the Naperville headquarters.)
Location (within the facility,
Publisher (place and name)
Format (e.g., book)
"Checked out" (a yes/no toggle
"Checked out by"
"Date checked out"
This function does not
replace the manual check-out system that allows engineers to self-charge
items after hours, but it makes performing inventory on the collection
much easier. The "checked out by" field is not visible to the public access
login. A reserve function was added to this catalog this past fall.
The second refinement was
the creation of a whole suite of catalogs for the LSDB. The PE Library
has always maintained automotive manuals and vertical files, general vertical
files, and standards as collections separate from the main monographic
collection. We based all of the new catalogs on the Books and A/V catalog.
As we have developed the LSDB, the various catalogs have been changed to
better reflect the nature of the collections. For example, call numbers
are only used in the Books and A/V collection, and authors are not part
of the automotive file materials. We expect that the different catalogs
will become increasingly more varied over time, as we further customize
One of the catalogs that
wasn't part of the original plan has already become an important tool for
library staff. A month or so into the development process, we came up with
the idea of automating various library tip sheets and index cards, including
login information to subscription services--information that needs to be
shared with library staff but not with library customers. The creation
of this "Roll Index" required us to expand the administrative login, so
only library staff could view and edit Roll Index records. We access the
Roll Index from a pull down menu in the program that is not available from
the public login. This "catalog" has become extremely popular with all
library staff; we use it many times a day!
The Experiment Goes Live
During summer 2000, computing
staff installed the LSDB on employees' workstations. Also during the summer,
our teacher intern Elaine Poirier started using the LSDB without training
to "test drive" it from a user's point of view, and to report on anything
that was confusing. Her project quickly came to include taking the lead
on planning and conducting all-staff workshops on the LSDB. Her teaching
skills were well suited to these tasks.
A beta test of the workshop
with the PowerPoint presentation (the framework for the session) was conducted
in early July, using a group of staff volunteers. The test session went
very well, but we did get some suggestions and questions, which we addressed
in the final presentation. We made the final presentation twice in mid-August;
80 percent of the company staff attended.
We have made the PowerPoint
presentation available to all employees on a shared network drive. We also
send periodic e-mail reminders and tips on LSDB usage to all staff.
Analyzing Our Results
When the LSDB project was
underway, everyone involved began to realize that the project would have
begun more smoothly if the library staff had known more about the computing
applications and the computing staff knew more about library operations
and needs. We all think it would have helped to sit down at the beginning
and share some background with each other, but we have managed fairly well.
The LSDB progressed as time
allowed, in a somewhat random fashion. This casual approach was positive:
We could simply call or stop by and chat with each other. On the other
hand, we kept few notes on our steps along the way. We formalized our interactions
just a bit this past fall, with scheduled meetings and note keeping. This
helps us all have the same understanding of the ongoing process.
An in-house project such
as this necessarily faces time and money constraints. This was a project
added onto everyone's regular workload, with no overtime pay. In an ideal
situation, staff would have time set aside for a project of this magnitude.
One impetus for developing
the LSDB ourselves was lack of funding for purchasing an off-the-shelf
library automation system. This was also mostly positive--it ledto the
development of this customized product that really fits our needs.
We needed more user input
for the LSDB; we did not adequately "test the hypothesis" (that is, the
database). While we did keep track of engineers' requests and suggestions
for a desktop-deliverable library catalog, we could have involved them
further in the project. Ideally we would have had one or more engineers
involved in the development of the product, to make sure it would meet
their needs. While a number of engineers are now using the LSDB, and follow-up
comments indicate they are pleased to have it, we believe we could have
done an even better job if representative engineers had been involved.
We provide access via a
shared drive in the Novell network, but the LSDB itself must be installed
on each client computer. So it was very time-consuming to implement it
companywide. Since our initial installation on all machines, we have developed
an executable file. It accesses LSDB updates from a server volume and then
automatically installs them on the client machines. This saves us time!
Initially we had to send an e-mail to all staff to tell them to run the
executable update program. However, this fall the LSDB itself was modified
so it checks the version against the master version to see if a newer version
exists, and if so it instructs the user to run the update program.
Achievements and Goals
Much of our LSDB development
work this past fall has been in customizing the various catalogs to better
reflect the nature of the different collections. We have also expanded
report writing functions. Since all the fields of every catalog can be
searched, library staff wanted to be able to export search results to create
reports. To meet this need, we expanded the print function to include an
export option. Now we can export records in a variety of formats including
delimited, rich text, and text.
The executable update program
and the automatic version query and alert have made LSDB installations
and upgrades easier. However some of the significant changes to the LSDB
have still worked best when the program is reinstalled directly on a machine.
To solve this problem, a long-term goal of ours is to revamp the entire
application into an Active Server Page implementation. In this setup, record
fields would be linked to an SQL server.(Our company already is running
one for other applications.) The LSDB would be a browser-accessible application,
available on the company's intranet.
A short-term goal is to
get all of the materials in the PE Library collections cataloged and into
the LSDB! As with most library automation projects, the data entry required
for retrospective conversion is the main stumbling block. We are hoping
to be able to get some temporary help early this year to get all of the
standards online, since the engineers use this collection daily.
Another long-term goal is
to develop Boolean searching capabilities. Some of the engineers have mentioned
that they would like this, and it would allow library staff to construct
more sophisticated searches.
Our Final Conclusions
All of the library and
computing staff members have enjoyed engineering an in-house library automation
system that's customized for our company. We are proud to have worked to
create a product that is increasingly well suited to the PE Library's collections
and customers. We expect to continue to make refinements to the LSDB; in
particular we plan to ask the engineers during the first half of this year
to let us know any additional features they would like to see.
We would be happy to speak
with any readers interested in embarking on this do-it-yourself method!
(Our colleagues, information
technology manager Patrick Farrell, information specialist Karen Crothers,
and information assistant Gwen Barber, also made contributions to this
Sara R. Tompson, director
of library services, holds an M.S. in library and information science from
the University of Illinois. She is a past president of the Illinois chapter
of the Special Libraries Association and co-author ofSpecial Libraries:
A Guide for Management (1997), as well as numerous articles. Her e-mail
address is email@example.com.
George L. Goehring, systems
analyst, holds an A.S. in computer science as well as a computer-aided
drafting and design degree. He is certified in programming in multiple
manufacturing machinery and has extensive VisualBasic programming experience.
His e-mail address is firstname.lastname@example.org.