Chances are if your library has not yet decided to implement an electronic reserves project, it soon will. A wide variety of decisions must be made before a project can take off, including what scanning hardware and software to use, how much staffing to hire, and, of course, how to handle the copyright issue. However, possibly the most important decision a library will make regarding e-reserve implementation is whether to create a management and maintenance system from scratch, a homegrown system, or purchase a turnkey solution such as ERes, Contec, or Nousoft. On the one hand, a homegrown solution gives your library complete control over the entire program and is relatively inexpensive, but your library may not have the technical expertise or the manpower to create a homegrown product. A turnkey solution gets your library up and running quickly and comes complete with usage instructions and support, but a turnkey solution may not be in your library's budget.
The libraries at Southern Illinois University, Carbondale (SIUC) and the University of Minnesota have both recently grappled with this decision. While SIUC decided to build a homegrown product, the University of Minnesota went with a turnkey solution, specifically ERes from Docutek. What follows is a discussion of the reasoning that went behind these decisions, as well as reviews of both SIUC's homegrown product and Docutek's ERes version 3.1 in terms of ease of use, customizability, labor, and cost.
SIU: the setting
Morris Library of Southern Illinois University, Carbondale serves the needs of over 22,000 undergraduate and graduate students with a collection of over 2.4 million physical volumes and a wide range of user services. Divisions within the library include Instructional Support Services, Humanities, Social Studies, Education and Psychology, Science, and the Undergraduate Library. The Undergraduate Library contains a reference collection, a small circulating book collection, a busy reference desk, and the reserve collection, among other responsibilities. The reserve collection averages about 400 courses and approximately 3,000 unique readings per semester. During the fall semester of 1997, it was decided that the Undergraduate Library would begin an electronic reserves pilot project to be rolled out the spring semester 1998.
A team of three librarians was created to look at other e-reserve implementations and recommend hardware and software purchases as well as suggest staff requirements. After reviewing various e-reserve home pages and touring Northwestern University's E-Reserve department, it became obvious Adobe Acrobat products were the dominant software tools to create reserve readings. Adobe Acrobat Capture 2.0 and Adobe Acrobat 3.0 were purchased as well as an HP ScanJet 4c. Two student workers were hired for approximately 20 hours a week a piece. Thirty-five classes signed up for the pilot project.
A scanning schedule was developed using professor supplied course syllabi. Reserve readings were scanned as they were needed with an attempt to scan them two weeks in advance of the assigned reading date. A large desk calendar was used to schedule readings, and as they were finished they were crossed out. A reserve reading flow chart was also created which included fields for file name, scanned, processed, reviewed, cropped, copyright attached, uploaded, and erased from the PC. The flow chart was important in case a student worker left in the middle of a job; the next student worker could pick up where the other left off. Approximately 450 articles were scanned that semester with about 7-10 being scanned per day.
Although scanning reserve readings is time consuming, there is little that can be done to avoid this process other than requiring that instructors do it themselves. What quickly became the most frustrating aspect of the project was the time it took creating the HTML pages to access the readings. Flat HTML pages were created including an instructor list, a course list, and all the individual course reserve home pages. Early in the project the supervisor found little time for anything else besides coding HTML for the e-reserves web pages. Authenticating users also became problematic. Straight IP address authentication was out of the question due to the large number of distance learners using off-campus ISPs. Using Netscape's FastTrack server to password protect directories, each individual course page received a unique username and password which then had to be passed back to the instructor and finally on to the students. And to top it all off, a separate Microsoft Access database was created to maintain information about the courses and readings. This too needed daily maintenance. Due to all these time consuming duties the project quickly became too overwhelming.
The above narrative may sound familiar to many librarians attempting to implement e-reserves. It was quickly decided that the project at SIUC needed a software program to aid in the management of electronic reserves. SIUC considered a turnkey product to alleviate the situation, but because of cost and time constraints this option was not feasible. The library simply did not have money for electronic reserves software in its budget. A homegrown solution was the only option, but it had to be easy use for both administrators of the system and student workers. A series of criteria were produced:
- The program must be web based, utilizing forms for the entry of course and bibliographic data.
- The program must be database driven, and create the e-reserves web site dynamically based on this data.
- The program should require that bibliographic information be entered only once, have the ability to use that data in multiple ways, and have the ability to retrieve that data in subsequent semesters.
- The program must be able to remove a reserve reading at the end of the semester that reading is intended for without intervention, as well as allow administrators to place a reading on reserve for as little as a day and remove it without intervention.
- The program must authenticate user access to readings through an easy to use password, preferably one they are already familiar with such as SSN or student ID number.
- The program must have both a browse and a keyword search feature that allows users to search for courses and instructors, but not specific readings.
- The program must include a log file to evaluate usage patterns and detect problem areas.
- The program must be able to handle a variety of file types such as PDF, DOC, XLS, PPT, ZIP, etc, as well as links to web based material such as course syllabi and external sites.
Other necessities were conceived as the project went along including the ability to allow student workers to upload reserve readings into the server, but not overwrite or have the ability to erase any existing readings, and to somehow have the program maintain copyright information for each individual reading. There was also a concern that once a user had authenticated, there was nothing to stop this user from book marking a reading or even placing a link to that reading on a personal web page. Luckily, Morris Library employs two extremely capable web applications programmers. Work began in the spring of 1998 by one of these programmers to tackle the above criteria.
Development began using the Perl programming language. Using the above criteria as a guide, the programmer spent approximately 50 hours total creating the program which includes 12 individual scripts and three directories. The scripts include:
- input -- the input program for e-reserves processing
- input.courses -- creates or modifies information for a particular course (page one of e-reserve processing)
- input.readings – to create or modify reserve readings (page two of e-reserve processing) input.help -- help regarding filling in the two pages of processing
- list – the patron processing form for displaying e-reserves
- list.courses – displays courses or instructors based on user selection
- list.readings – displays course page and readings after user clicks on course link
- maint.pl – a maintenance routine which removes deleted records from the data files
- fileUpload.pl – uploads new files to the server
- proc.pl – performs common procedures throughout the e-reserves program
- ssn – text file holding all the valid IDs
- wrong.id – displays error screen if user leaves ID field blank or if the ID isn't listed in the ssn file
Three directories named temp, data, and readings are also essential parts of the program. Temp holds temporary files created by search functions used in list.courses and list.readings. The data directory contains four flat text files data.courses, data.readings, data.dates, and data.logs. The data in these files are retrieved by the scripts listed above for display to the adminstrators and patrons using the program. The readings directory obviously holds the reserve readings uploaded to the server. After completion, the program was unveiled on schedule during the 1998 summer session for use by the library staff and patrons of SIUC's Morris Library.
After clicking "submit" the user is presented with the results from his or her search, a list of available courses or instructors (Figure 2). Upon choosing a course the user is sent the actual course reserve page with links to all the various readings the instructor has assigned (see Figure 3). Readings are categorized by date to be read, group number, or alphabetical order if no date or group number is available. A complete citation for the reading is included as well as a bolded note to the user that is an optional field input during the e-reserve processing phase. This bolded note may warn the user that the reading is large or poor quality, among other possibilities. This is followed by the link to the reading which denotes the format of the reading as well as the overall size of the reading in bytes.
What's in the URL?
Copyright compliance was a major concern for everyone involved with the project. By placing readings on the WWW, libraries with e-reserve projects run the risk of the readings being made available to anyone with a browser and access to the Internet. It became apparent in the early stages of SIUC's project development that once a user had authenticated there was no way to stop the user from either book marking the reading or making it available on a private web page. The chances of the latter actually happening may seem remote to most reserve librarians (getting students to actually read the material is hard enough), but something had to be done to fix the problem. One option was to dedicate a server session to each authenticated user and have it time out after a period of inactivity much like database vendors such as ProQuest or FirstSearch. However, it was decided that individual sessions would be too much of a burden on the server. Everything can slow down when a server gets low on process space and memory.
Instead, the programmer built into the URL a time-out feature which times out course and reading links after six hours. In other words, each course page and individual reading has a dynamically created URL with a time-out limit of six hours. The time-out feature begins as soon as the user selects a course or a reading. A user may still bookmark or place a link to the reading or course page on a private web page, but it won't last long.
The URL also calls other functions such as verifying that the user has properly authenticated. It also pushes the reading to the patron using a byte serving script for PDFs from Adobe. Byte serving, or page-at-a-time downloading, serves up PDFs to the user one page at a time rather than downloading the entire file before displaying. This is especially useful for users with slow modem connections since downloading the complete reading is not required to view the beginning of the document. In order for byte serving to work, the user must have the Adobe Acrobat Reader installed as a plugin on their browser of choice, as opposed to a stand alone application.
Courses and readings are entered into the system using the two page Electronic Reserves Processing Form. However, before a person can begin, the program must recognize that person as a "super user" or a person with administrative priveleges. Rather than require a unique password like the patron interface, the processing form recognizes the remote host name of the workstation trying to access the program. If the program doesn't recognize the remote host name the user is sent to the patron interface home page and a log entry is created stating someone tried to gain access to the processing form. The remote host name and the date of the attempt is also noted in the log (more about the log file later).
Figure four illustrates the first page of the Electronic Reserves Processing Form, the course entry form. Everything about the course is entered onto this page including the department, the course number, the course title, the semester and year of use, and the course instructor. Users may also search the course data file for an existing entry to avoid redundancy. After clicking "submit," the user is then presented with a verification screen allowing for modification of the course information, assignment of readings, display of current readings assigned to the course, or the option of creating a new course. Clicking on "Assign Readings" will open the second page of the processing form and allow users to assign readings to that course.
Page two of the Electronic Reserves Processing Form assigns reserve readings to a specific course. (see Figure 5) On this page, the user enters bibliographic information such as author of the selection, title, source, publisher, date, and the pages scanned or used by e-reserves. Again, the user may search for the author or the title of the work being processed to make sure that the data hasn't already been entered or to verify that the reading doesn't already exist on the server. After entering the bibliographic information for the reserve reading a note may be attached to the reading. (see Figure 6) This note will be visible to patrons accessing the corresponding course page and may include information on the quality of the scanned reading, size of the document, or a note from the instructor. This is followed by the name of the file to be uploaded to the server or the URL for an external link to the selection. The file extension is not required because the script will recognize the extension on the file after it is uploaded to the readings directory.
Copyright information is maintained for the reading by making a selection, fair use or copyright, from the copyright drop down box. If copyright is granted for a fee, that information may also be entered. With this data, administrators may reliably track whether or not the reading is being used as fair use, or with copyright permission. If this reading is accessed again in subsequent semesters, this information will appear again as well as a note telling the user the last semester the reading was used. Next, corresponding dates must be entered. The first field "Date to be Read or Group" allows the user to specify the assigned reading date or reading group supplied by the instructor. This date is then shown to the student on the patron accessible course page (see Figure 3).
Finally, the dates on reserve must be entered for the reading including a beginning date and an ending date. Users may leave the reading on for the entire semester or a shorter period of time depending on copyright restrictions. The field was initially created to take advantage of the "guideline of spontaneity" which is a guideline stating that material may be reproduced and made public for a short period of time without copyright.1 When a reserve reading falls in between the two dates entered, the reading is displayed to the student, and after the ending date the link to the reading is removed from access. This all happens without user intervention. Upon completion of the form the user has the option of showing the link (to verify accuracy), saving and assigning the reading, resetting the form, or entering a new course. Once the reading has been assigned to a specific course and the actual file (pdf, doc, ppt, etc.) is uploaded to the server, the reading is ready for patron access.
Two other features available to "super users" worth mentioning include the fileUpload.pl script and the log file. The upload script allows student workers or others without access to the server the ability to upload readings into the readings directory. Again, this is a function that is only available to workstations with recognized remote host names. Another characteristic of the upload script is that users can only upload files, files cannot be deleted or overwritten.
Super users also have access to the log file. The log file can be viewed by typing "log" into the search box of the patron interface home page from a super user workstation. The log file counts access to course pages as well as hits on the readings themselves. The remote host name of the computer accessing the files is also noted as well as the date and time. The log file also tracks illegal attempts to access the processing form and attempts to use links that have timed out.
The program has been in place for two semesters now and in that time some limitations have become apparent. For one, not everything is automatic. The current semester must be manually input into the script "list" in order for the correct semester's readings to display. This is a minor irritation that will be worked out in future versions. Secondly, although only providing "super user" access to workstations with recognized remote host names provides good security, it makes it difficult to work on the system from home. Unless you can figure out what remote host name the campus, library, or ISP modem pool has given your connection the system won't let you in. While it is possible to find this information out and enter it into the scripts, it is still an annoyance.
Another limitation is the fact that everything in the system is protected by a password including non-copyrighted material. This means that non-copyrighted material such as course syllabi or final exams are also behind a wall of security. And just as users are unable to link or book mark specific readings or course pages, this also means that instructors can't link to assigned readings from their own course web pages. If an instructor has built a course web page and has material on electronic reserve, the link to this material must go to the e-reserve home page where the user can first authenticate and receive authorization. If authenticated and authorized, the user may then proceed to the assigned readings.
Future plans: Introducing FreeReserves
Library staff and patron response to the product has been very favorable. Due to this success and the portability of the Perl programming language, the developers of the program intend to make the source code available to anyone who wants to use it under the GNU General Public License agreement and under the name FreeReserves. By making the code open source and free to the library community, the developers hope that the program can continue to grow and improve. All that we ask in return is that if you make an improvement to the program that you pass it back to the developers so that it can be built into future versions of FreeReserves. System requirements for the program include a Unix based web server running at least Perl 5.003. Currently, FreeReserves is not available for Windows NT servers. Hopefully, a compatible program for NT servers will be worked out in future versions.
Most importantly, in order to correctly install FreeReserves at your institution, there must be someone there that has at the very least a basic understanding of Perl. This is not a program that can simply be "double-clicked" to install. The beauty of FreeReserves is that it is open source. This means that everything from the data structure to the interface can be modified to comply with your institutions' desires or standards. However, whoever modifies the program must be knowledgeable in Perl. For more on FreeReserves including a demonstration, and downloading and implementation information, please visit http://www.lib.umn.edu/san/freereserves/.
The University of Minnesota
Rather than take the time to develop, test, and implement a homegrown solution to maintaining electronic reserves like SIUC, the University of Minnesota instead went with a turnkey product, specifically ERes from Docutek. What follows is a discussion of the ideas and reasoning behind this decision as well as a review of the ERes software. Although it was the original intention of this paper to give a detailed discussion of the U of M's electronic reserves implementation, as of the writing of this paper, the pilot project has not started.
The University of Minnesota—Twin Cities campus has an enrollment of over 37,000 students, graduate and undergraduate. The University Libraries are housed in five main facilities and eleven branch sites, and contain over 5 million print volumes, as well as numerous serial, microform, and government document collections. Because of its vast holdings the University of Minnesota Libraries is the 17th largest research library in the nation. In terms of reserves, the collection is spread out across 16 individual sites. The three largest reserve collections are contained in Wilson and Walter Libraries in Minneapolis, and Magrath Library in St. Paul. To give the reader an idea of the volume of the operation, Wilson Library reports an average of 61,000 reserve items circulated per year and between 100-120 courses on reserve per quarter. Walter Library reports a circulation of 36,000 items per year with an average of 100-120 courses on reserve per quarter. St. Paul's Magrath Library reports a circulation of 35,000 items per year and around 100 courses per quarter. Obviously, these statistics do not include the 13 other reserve collections on campus.
Because of the overwhelming size and spread out nature of print reserves for faculty and students of the University, as well as staff of the Libraries, electronic reserves was seen as a way to consolidate the operation. Talk began in March of 1998 and an ad hoc committee of four reserve staff members was created to discuss electronic reserves. The group was given a small budget and began inspecting e-reserves sites on the web and visiting local area college implementations. Based on this field research the group quickly formulated a series of criteria for an e-reserve system at the University of Minnesota. First of all, the system must be able to handle usage by multiple reserve sites, 16 to be exact. Secondly, in order to comply with copyright guidelines, the system must include password protection capabilities. The University of Minnesota currently uses a campus wide authentication system known as x.500 which requires a username and password for authentication and authorization to licensed resources. It was the group's hope that x.500 could be incorporated into any e-reserve system developed to minimize university student and staff confusion. There was also a concern about the compatibility of the system with future automated system upgrades (new OPAC, etc.). It was decided that the system should be stand-alone.
Essentially, however, the two main criteria for the system were ease of use and support. The system would be used primarily by student workers and staff members with little or no technical knowledge, and little time to learn. The potential number of documents, and the potential number of courses desiring to have digitized material also meant that the system had to be learned quickly. Support was also a major concern. Would the already overworked automated systems staff at the libraries be able to effectively develop and support the system? These criteria and others moved the group into the next phase of discussion: homegrown or turnkey?
Based on research, discussion, and field trips, the group decided that a turnkey system was the way to go. It was decided that a homegrown system required too much technical expertise and would require more support than the group thought the automated systems department could handle. So, four major players emerged for the right to provide electronic reserves to the students of the University of Minnesota: Docutek (ERes), Nousoft, OCLC SiteSearch, and DRA. DRA was considered as an option due to the University Libraries' commitment to use the DRA OPAC. With implementation of the DRA OPAC so far in the future, and the e-reserve committee's resolution to use a stand alone product, DRA quickly fell out of the running. Nousoft was considered due to its complete package including copyright maintenance features, password protection capabilities, and archiving features. However, cost was an issue as well as San Diego State University's decision to no longer use the product (SDSU was the first library to use Nousoft). Excitement for OCLC's SiteSearch was also minimal due to the fact that only one other institution was using it at the time. Eventually, it was decided that ERes from Docutek would be the electronic reserves system for the University of Minnesota.
ERes version 3.1 from Docutek is a series of CGI scripts which use the Perl programming language and a unique backend flat file database system. Library staff or instructors with little of no knowledge of HTML may enter course and document information into ERes using a web based interface. This information is then automatically organized into specific course web pages much like FreeReserves. ERes may currently run on any web server platform including UNIX and Windows NT, and can handle a wide variety of document types including MS Office products, gif, jpeg, WordPerfect, HTML, text, postscript, and PDF, among others. Other unique features of ERes include optional password protection at the course level, and an automatic interactive bulletin board and live Java chat room for each course page. This makes discussion of course related material outside the classroom easier and has obvious uses for courses catering to distance learners.
Unlike FreeReserves, ERes uses a user name and password system to allow access to the administration functions of the program. This user name and password system also has four levels of access privileges from the Manager, who has complete control of the system, to the general account level which has the power to create course pages and work with page entries. The beauty of this system is that it allows for access to the system by library staff and course instructors from any location with a connection to the web. If a library so desires, it can allow the instructors themselves to maintain their own course pages with a lower level account. This account could include the ability to not only maintain the course readings, but also administer the bulletin board and chat room for the course as well as include pertinent announcements for students accessing the course page. In essence, these capabilities allow instructors with no technical expertise to maintain their very own course home pages complete with course readings, course syllabi, reading schedules, announcements, and a bulletin board and chat room, among other possibilities.
The University of Minnesota was impressed with what they saw, especially of the fact that over 60 colleges and universities currently use the product. Docutek also offers a product called ERes Pro that includes not only the program, but also a Pentium computer running Linux and the Apache web server with the software pre-installed. According to the ERes web site "unpack the boxes and plug it in…your ERes Electronic Reserve System is running!"2 The University of Minnesota went with ERes Pro and purchased a Pentium II 400 MHz Widows NT server with a 9.1 GB hardrive and monitor for approximately $4,500. The size and speed of the server were based in part on the overall student population of the University of Minnesota as well as the potential number of reserves to be put on the system. The software license cost approximately $6,000 with a yearly fee of $900 for maintenance and support.>
The University of Minnesota ERes home page at http://scooter.lib.umn.edu looks much like other ERes implementations (See Figure 7) . Users may find their desired course page, or look at a manual, software requirements, or links outside of the system. The home page also includes links to the administration functions of the system. Upon entering the second level of the system users may search for course pages or browse for course pages by instructor name or department name. The interface is very intuitive and leads users to the appropriate courses with minimal difficulty.
Eventually a user finds the appropriate course page (see Figure 8). Before entering the course page the user is presented with either a copyright notice page or a copyright notice and password page depending on whether or not the course page is password protected. This password is assigned by either the professor or library staff member who originally created the course page and is one word (alpha-numeric). The course page includes the name and number of the course, instructor name and email, links to the course chat room and bulletin board, an announcement from the instructor (if the instructor has decided to post one), and information about the course readings or documents. The document information includes the title of the reading, the format, and the size of the document in pages.
Again, administration privileges are determined by the administrator's account level. There are four account levels. The General account level allows for the creation of course pages and page entries. Anyone with the general account level may only work with the course pages he or she has created. This would be an obvious choice for an instructor who has been given access to maintain his or her own course page. The second account level is the Helper who has the same privileges as the General user, but may also add readings to any course page. A Helper may delete readings only from course pages he or she has created. The third account level, Assistant, may create course pages and work with page entries for any course page.
Finally, the ERes Manager account level is authorized to not only create course pages and modify page entries, but also create and maintain user accounts, as well as perform other administrative functions (see Figure 9). These include the ability to add or remove departments, gather usage statistics, create departmental internet resources web pages, delete course pages, link to course pages created outside of ERes, and send email messages to all account holders. According to Phil Kesten, Docutek's Information Systems Representative, only one Manager account exists in the ERes system, and this is usually given to one person. Again, there is no need for this person to have any technical knowledge or expertise outside of knowing how to use a web browser.3
At the heart of the ERes system, however, is the ability of any account holder to create course pages and add or delete documents from it, among other possibilities. Any account holder may create a course page by clicking on "Create a course page" from the ERes home page. This will then prompt them for their user name and password to gain access to the first screen of course page creation. (see Figure 10) After the course page is created, the account holder may begin to attach documents to it. In order to gain access to a course page account holders besides the Manager must first find the course page in the user interface system and then click on "All page functions." This will again prompt the account holder for user name and password information and finally forward the account holder to the Course Page Functions screen. The account holder may then add, modify, delete, or change the order of documents, post announcements, manage the course bulletin board, gather access statistics, or even delete or archive the course page (see Figure 11). Again, the privileges an account holder has are determined by the account level his or her user name and password is given.
The most obvious limitation concerning the ERes product is the ability to customize the interface or the overall system. The ERes license agreement prohibits any modification of the code without the prior approval of Docutek. This is in part because of support issues. Docutek obviously can't support code it doesn't recognize. In terms of navigation issues and screen text and layout, Docutek prefers to keep the same look and feel of the program from site to site as each installation is a potential advertisement to the world. However, Docutek does promise that it will develop an ERes system that meets the wants and needs of the school. This may require extra software engineer hours, and possibly an extra fee attached to the overall price. For example, the University of Minnesota would prefer to use its own x.500 authentication system for student access to the program. This may require that Docutek modify the original code. Obviously, developing a homegrown system allows for as much customization as you want without the hassle of dealing with any license restrictions or programmers outside of your library. To their benefit, it is remarkable that Docutek allows for any customization and it certainly shows their commitment to customer satisfaction.
Secondly, unlike electronic reserves systems like Contec or Nousoft, and even to a lesser extent FreeReserves, ERes version 3.1 currently does not contain any copyright management applications. The ability to password protect course pages is as far as the software goes concerning this sticky issue. Granted, systems like Contec and Nousoft are far more expensive, and most libraries already have copyright management guidelines in place. ERes will, however, be developing a copyright management piece into future versions of its product.
Finally, although course pages may be password protected, there is no password protection at the document level. All documents have world access rights in the ERes system. If a person knows the URL to a reading, the course page and password protection can be bypassed. This, of course, means that a student may not only bookmark a reading, but also link to it from a personal web page. Again, the chances of this happening are rather slim, but who can guess the mind of a malicious user? According to Phil Kesten, the new version of ERes will offer greater security at the document level by making the URL impossible to determine.4 Nonetheless, the URL will still be world accessible.
Currently, ERes version 3.1 uses a flat file database as its backend. ERes 4.0 will use an SQL database and VBScript/ASP technology to drive the program. This will offer the database a great deal more flexibility. By using Active Server Pages this of course means that ERes 4.0 will require a Windows NT server running Microsoft's Internet Information Server (IIS). Although ChiliSoft has developed software that allows ASP programming on UNIX based servers, Docutek reports that the software is still "buggy" and has not yet reached the level of relationship between ASP and Microsoft's IIS.5
The database behind ERes 4.0 will also include a number of new fields concerning copyright and the flexibility to add new fields for copyright management at the request of individual schools. This will include the ability to flag documents based on copyright compliance causing affected documents to be viewed only as permissions warrant. Each document will be tagged as either "Copyright Registered" or "Copyright Not Registered" with additional fields for "Claim Fair Use," "Request Copyright Permission," "Reveal to Public Pending Permission" or "Do Not Reveal to Public until Permission is Granted," and "Permission Granted."6 This additional functionality will almost certainly allow ERes to keep its dominance of the electronic reserves market.
The U of M: what's next?
Using ERes version 3.1, the University of Minnesota Libraries hopes to conduct its pilot electronic reserves project during the Spring Quarter beginning March 15, 1999. Until then, various decisions still need to be made concerning courses to take part in the project, equipment, staffing, and workflow. For now, no more than 10 courses will take part in the pilot project giving the University Libraries time to learn the new software, determine how much each reserve collection can handle, and decide what each reserve unit needs in terms of staffing and equipment.
The reserve unit of Wilson Library (Minneapolis campus) will direct the pilot project. One HP 6100C scanner has been purchased, as well as Adobe Acrobat 3.0 and Adobe Acrobat Capture 2.0. The University Libraries' Copy Service has agreed to scan, process, and upload reserve readings, while the actual reserve unit will handle data entry, advertising, and correspondence with instructors. Some of the responsibilities between the Copy Service and the reserve unit may begin to blur as the pilot project goes on, but it is important that these workflow issues be resolved before the word gets out and the reserve units are inundated with courses desiring the service. It is hoped that after a successful pilot project the lessons learned will enable the three Copy Service centers at Wilson Library, Walter Library and Magrath Library to not only take care of the electronic reserve scanning needs for their corresponding libraries, but also all the branch libraries on the Twin Cities campus.
Based on the experiences of SIUC and the University of Minnesota, the main differences between homegrown and turnkey e-reserve systems can be found in a discussion of labor, cost, and customizability. Homegrown systems can be quite labor intensive to develop and support. Developing the homegrown system at SIUC took over 50 hours of programming time and countless hours taking care of minor adjustments and "tweaking" the product. Developing a homegrown system also requires staff members with technical knowledge and web development expertise. This obviously includes knowledge of HTML, not to mention advanced programming languages such as Perl. Although creating a homegrown system using only HTML is possible, this type of endeavor can quickly become overwhelming for institutions with large reserve collections.
Turnkey systems like ERes offer a distinct advantage over homegrown systems in terms of the time and effort it takes to get a product up and running. For the University of Minnesota, the lack of programming skills and the desire for on-going, reliable support prompted them to purchase ERes from Docutek. Docutek in particular has made it easier for libraries to begin offering e-reserves through its ERes Pro product line. With ERes Pro, Docutek will build and configure a server for you, complete with the software already installed and ready to go. Of course, this comes with a price.
Developing a homegrown system obviously saves money, especially when compared with turnkey systems like Contec or Nousoft. This is not to say homegrown systems are without costs. There is, of course, the staff time required to develop the program, as well as software and hardware costs. SIUC spent an estimated $3,000 on hardware and software, and an indeterminable amount in programming hours. This is far less than the University of Minnesota, however, which will spend approximately $11,000 on the ERes software and server, not to mention possible customization costs and yearly license fees. Of course, the total cost for the University of Minnesota is based in part on the overall size of the university. Some smaller libraries using a turnkey system may have lower costs.
Finally, the biggest difference between homegrown and turnkey systems lies in the customizability of the end product. Libraries developing homegrown systems can conduct usability testing to determine the most appropriate web interface, or use existing graphics and web site appearance to create a satisfactory e-reserves site. Anything from graphics, to screen layout, to navigation can all be customized to meet library web page standards or the desires of your library's webmaster or web committee. By creating a homegrown site, SIUC was not only able to customize the patron interface, but also the backend database in order to create a system which totally catered to the needs of their reserve unit. With a turnkey system, a library is somewhat hampered in the choices it has concerning customization. Although Docutek does claim to allow for some modification of the product, extensive modifications may require an added fee. Some modifications may be completed by the purchasing library, but the license agreement prohibits any modifications without the approval of Docutek in advance. In defense of Docutek, their willingness to modify their product at all is commendable. ERes is also already extremely easy to use and requires very little in the way of modifications for most colleges and universities.
The decision to go with either a turnkey system or a homegrown system to deliver electronic reserves is based on the unique situation at your library. For libraries without the technical expertise or manpower to create and support a homegrown system, products like ERes are the clear choice. ERes in particular is used by over 60 libraries worldwide both large and small, and does not require any knowledge of HTML or advanced programming languages. A homegrown system, however, gives a library significant cost savings as well as the power to customize the product at will. Obviously, there are advantages and disadvantages to both types of systems that must be considered before determining the most suitable method for electronic reserves maintenance and delivery at your institution.
- Janis H. Bruwelheide, The Copyright Primer for Librarians and Educators (Chicago: ALA, 1995): 32.
- Philip R. Kesten and Slaven M. Zivkovic, "ERes—Electronic Reserves on the World Wide Web." Journal of Interlibrary Loan, Document Delivery & Information Supply 7, no. 4 (1997): 43.
- Philip R. Kesten
. "ERes questions" Private e-mail message to Shane Nackerud. 25 February 1999.
- Philip R. Kesten
. "ERes questions" Private e-mail message to Shane Nackerud. 24 February 1999.
- Philip R. Kesten
. "Copyright questions" Private e-mail message to Shane Nackerud. 26 February 1999.
"Docutek Information Systems, ERes Technical Overview" Online. Available http://www.docutek.com/products/eres/techno.htm. 28 February 1999.