1

Samantha Clarke & Lisa Dean

LIS630: Computer Related Technology and Information Management

Assignment 3: Configure and Evaluate an Integrated Library System

April 15, 2019

Report and Reflection: Configuring KOHA

I. Introduction

This report details our attempts at customizing a Koha interface to create a public library

OPAC and ILS. We will detail what modifications were made to the Koha interface, our

rationale for some of the choices we made, and what difficulties or successes we had along the

way.

II. Configuring Baseline Parameters

Defining a group branch was fairly simple. We made up a library branch code, 8675309,

and named the library “Group 9 Library”. The code itself would come in handy with later tasks,

such as running reports. This helped us to narrow down report results to exactly our additions to

the catalog, patron lists, acquisitions, etc. We also played with the library group function and

placed our library and Midway together in a group simply called Greensboro Libraries. It is

unclear if this group function had any effect on our catalog. Below is a screenshot of the entry

for the library in Koha.

I attempted to create an IP address and MARC organization code according to the instructions

given in Koha and through the Library of Congress documentation linked in the “Modify

Library” screen. We also created a main email address for the branch.

2

Attempts to modify the overall aesthetic of the OPAC were made, but there was not much

progress. However, on the OPAC screen of the Systems Preferences page, we were able to set an

image in the header, upload an image for the favicon, and create the base URL,

“www.group9library.com”. There was an attempt to adopt a style sheet for the OPAC look and

feel, however once one style sheet was added, it was impossible to change it.

We also set up a budget for the library, set at $500,000. Three funds were created within

the budget: Reference Materials, set at $100, and Adult Fiction Materials and Children’s Fiction

Materials, each set at $200. Below is a screenshot of the Budget Summary. Many of the

materials selected for the catalog fall into these categories, and so funds were created to account

for these.

Regarding the overall experience with these configurations, most of the system

preference page proved confusing and difficult to use. However, with more time and maybe

some web design knowledge, these could be configured with relative ease.

II. Editing Patrons and Circulation Parameters

Patron circulation privileges were set according to patron and item type. This process was

a bit confusing at first. When the edit button is clicked on any of the records, a duplicate row

appears. However, this row is for editing purposes only. After working with a few of the records

this became apparent. Below is a record of the parameters that were set for some of our patrons.

3

We limited new-users to 10 checkouts at a time and fines for all patrons were to start being

assessed at a rate of .20 per day after a grace period of 5 days. The one exception to this rule was

for staff members who had no fines apart from fees for lost or damaged materials.

IV. Z39.50 Client Targets

Z39.50 Client targets were chosen at random, and limited to those that depended upon

MARC syntax (UNIMARC in this case). The client targets in the screenshot below were chosen

and added to Koha:

These two were chosen because they appeared to be sourced by public libraries and so would fit

the needs of this library.

This portion of configuration was not easily understood nor easily implemented. For

example, when using the Z39.50 targets to search for new acquisitions, it was difficult to come

4

up with search results. Even with very common search terms, a search came up with no results. It

is unclear what could have been done differently.

V. Cataloging Module

We created a ten-digit number scheme for assigning barcodes instead of having Koha

generate all of them. However, while creating records, we discovered that we could add one item

with our created barcode and then choose the option to add multiple copies. The system would

then generate barcode numbers automatically based on the number scheme that we had entered

with the first copy.

In some ways, we found that cataloging was almost effortless in respect to adding books

and music CDs. Serials were somewhat more challenging, but, with the American Library

Association added as a vendor, we were able to add a subscription to “American Libraries”.

Visual materials were more difficult, because these types of resources tend to be more scarce

when searching Library of Congress and Polaris. The Library of Congress brings back some

actual film as opposed to DVDs and this is something that we did not always realize unless we

carefully examined the MARC record. Inventory lists for the collection can be created in Koha.

VI. Patrons Module

We created 13 patron accounts in the following categories: Staff, Retired Library

Employee, Adult 3-Year, Adult New User, Adult Non-County Resident, Juvenile 3-year,

Juvenile New User, and Juvenile Non-County Resident. Before entering patrons into the system

these types had to be set. A list of those is shown below. Other types are included because we

found that when we tried to eliminate categories, Koha would not allow that as they were being

used by other libraries.

5

The next step in the process was entering cities for our patrons. Since one city had

multiple zip codes, it is entered more than one time to accommodate that. Pictured below is our

list of cities. Cities outside of the county were added for our non-county users.

6

At this point we began creating patron accounts. At times, the process of adding patrons

was very time consuming because Koha seemed to be running rather slow. This was not always

the case, however. Below is a sample of a staff patron record we created.

Once we had several patrons added to the system and we tried accessing patron records

by name, we found that accessing them in this way would yield no results. Entering numbers

would, however, bring the results we were seeking. Overall, working with patron and item

records in Koha has shown us that the system tends to respond more to numbers than text.

VII. Circulation

Early in experimenting with checkouts we found that if parameters are not set that the

system will show an alert that the patron is now allowed to check out. This message could be

overridden to allow for checkouts.

We found check ins and checkouts to be a straightforward process for the most part. One

exception, and the reason for this is still not clear, was a checkout of Jane Austen’s Pride and

Prejudice that is checked out to the patron “John Wilson”. Any attempt to check the item in ends

7

with the record being highlighted in red with the message that it is unable to check in. There

appears to be nothing wrong with the record or the account, however.

We found some degree of difficulty in placing holds when attempting to do so from the

patron’s account. So far, we have had to go to the item from the inventory list and access the

item record. From there a patron request can be placed.

8

Here is the hold request reflected in the account for “Matthew Jackson”.

We were also able to assess and remove fines from patron accounts. In the following

example, we assessed a 25.00 non county resident fee to the account of a non-resident user.

“Elizabeth Phillips” and then removed it.

9

10

VIII. Acquisitions

The acquisitions functions seem to be the smoothest and one of the easiest functions to

execute. A good feature to point out is the fact that the budget and funds appear on the

acquisitions main page:

It also updates once you have placed orders and displays how much of those funds you have

already spent.

As instructed, we set up the American Library Association as a vendor, filling in as much

information as possible.

11

All information listed is accurate for the American Library Associations Publications

Office. A variety of contacts were added - the reason for this was to mimic what a real library

would do to keep track of who to contact regarding different types of publications within the

same vendor organization. Below is a screenshot of the basket created for ALA. Both of these

were created using the Library of Congress as an external source.

We included Amazon as our second vendor and also set up a contract with them for

eBooks. A screenshot of that contract is pictured below:

12

Orders were also placed with Amazon based on the suggestions made in the Patron view

from the OPAC:

One of the best parts of working with Koha was adding vendors and placing orders. This

was one of the few instances in which two separate functions (Suggestions and Acquisitions)

seemed to work together fluidly. Furthermore, it proved rather easy for patrons to make

suggestions from the patron portal in the OPAC. Below is an example of some Patron

suggestions:

IX. Lists

Two lists were created for this library. One includes the adult fiction available in the

catalog and the other was created for children’s materials.

13

Both were made public and can be accessed from the OPAC by clicking the Lists button in the

top left corner. This is how they currently appear in the OPAC:

The screenshot below shows how items are displayed in one of these lists:

Once again, these lists proved to be one of the easier functions to execute in Koha. The

process of setting them up was intuitive, though it was important that I had the items barcodes or

biblio numbers ready to add to a list. There did not seem to be another search option. A Title or

Author search option would be beneficial here to make this experience more user friendly than it

already is.

14

X. Tools

Two of the tools we had the most success with were the Inventory and News tools. The

inventory tool assisted us in keeping track of what we had added to the catalog. Below is a

screenshot of our entire catalog from the Inventory page:

15

This inventory list proved incredibly useful for creating the lists mentioned above, as we

could easily access the barcodes needed to create those lists.

Another fun tool that was used for this library was the News tool. It appears that a user

can set News messages on both the Staff interface and the OPAC. Since there were two

messages set for the staff interface already, a News message for the OPAC was created. Here is

how it appears to Patrons:

Many of the other tools were confusing and not very intuitive to use. For example, the Tags tool

did not seem to work or provide many options for creating tags. This is how it appears in the

Staff interface:

16

There does not appear to be a place here to add tags. The same goes for the Patron view of this

tool:

17

There doesn’t seem to be much one can do with this tool. Many of the other tools listed behaved

the same way. It is our understanding that these tools may be better utilized by someone much

more familiar with Koha than we are.

XI. Reports

Reports for Acquisitions, Circulation, Catalog, and Patrons were created and can be

found under “Saved Reports”. The guided option was used to create these reports, however

creating these proved to be a challenge regardless. The Circulation report was the most difficult

to create as the values provided to build the report were not easily identified. The goal for the

Circulation report was to show which titles had been checked out. It was difficult to identify

which values represented item titles and authors. The resulting report is very rudimentary,

however it does represent the results we were looking for. Below is a screenshot of those results,

listing the title of the book checked out and when that book is due.

18

Those items with no “onloan” value listed have not been checked out. The other three

reports were much easier to configure and gave reliable results. A positive aspect of the Reports

tool is that queries can be saved and run whenever necessary. The query can also be edited using

the SQL editor, as shown below:

XII. Conclusions

As an Open Source Software, Koha seems user friendly, but only to a certain extent. It

seems that the critical functions, such as adding users, setting permissions, placing acquisition

orders and creating reports are easier to navigate for someone with little Koha experience. This is

important because an OPAC/ILS cannot function without these things, and ease of use is critical

when programming them. Aspects that are meant to improve the user experience, such as

searching, the look and feel of the site, as well as tag creation and book cover uploading were a

bit more difficult to achieve and make functional. It is our conclusion that these functions require

someone with experience not just with Koha but with web design in general. This expertise is

required in order for Koha to work for a library and meet the needs of staff and patrons alike.