Packer Engineering, Inc. (http://www.packereng.com), 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 them.

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 time.

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:

• Call number
• Facility (Packer Engineering has a Warrenville, Illinois, shop and a satellite office in Troy, Michigan, as well as the Naperville headquarters.)
• Title
• Edition
• Location (within the facility, e.g., Reference)
• Author
• Subject
• Publisher (place and name)
• Year
• Format (e.g., book)
• ISBN
• Notes

• "Checked out" (a yes/no toggle function)
• "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 them.

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 article.)
 
 

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 srt@packereng.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 glg@packereng.com.