Introduction and Overview
Koha is a free and open source integrated library system, released under the GNU General Public License. Libraries may install Koha on their own systems (it requires Perl, the Apache Web Server, and MySQL 4.1 or above) or contract with one of several vendors to host and maintain the software. This report contains observations on performing a series of common library operations using an installation of Koha, which in this case is hosted by PTFS (formerly LibLime). PTFS offers a slightly modified version of the standard Koha software which also includes support for the Zebra text-indexing and retrieval engine.
The first task undertaken was to define a new library branch, under which the remaining steps would be done. We were given a coding parameter for new branches which had to be followed (and which is used throughout the software to identify the library quickly). The library creation process was painless and provided a wealth of information fields which would be of significant value in a real library system with many branches. One aspect of the library branch interface that was not immediately obvious was the fact that, if already logged in, the new branch would have to be set using the link at the top right of the page. Of course, when logging in under a new session this choice would be available at the login screen.
Setting up a new fund for the newly-created branch, and establishing a budget for that fund were also simple and intuitive processes. However, at this point in the process it was not obvious what would be done with these created budgets, and the page which lists budgets for all branches does not direct to applicable pages in a really useful way. That is, funds and budgets can be viewed, searched, and edited, but the interface does not take you from that view to a page that lets you apply the new budget. This will be covered in more depth below in the section on the Acquisitions module.
Next, as recommended by the Koha interface, a new town/city was added. The only observed effect of this town definition is to enable that location as an auto-complete option in the Patron creation screen, as outlined below. It is likely that options exist to modify patron rights or other attributes based on the town chosen (this is observably possible to have this play a role in Report generation).
The administrative module contains many other tools which were not explored in depth. For instance, the software has the ability to precisely control how different branch libraries may or may not request item transfers. These options are customizable down to the level of item type and for every combination of branch, which is very powerful. The ability to micromanage patron types and how circulation alerts are handled would also allow a library system to configure the Koha interface to perfectly suit their requirements. Finally, the administrative Cataloging options would be very relevant in making sure records are properly imported, handled, and classified.
The final task under Administration was to add several new Z39.50 Client Targets for use in adding and cataloging new items. This allows Koha to pull MARC information from existing databases rather than having to generate the MARC records from scratch. Adding the targets (from http://irspy.indexdata.com/ ) went smoothly, although in some cases the field-to-field correspondence from the indexdata.com entry to the Koha interface was not perfectly clear (for instance, host vs hostname is the same field). Fortunately using initial judgments about field correspondence met with success and the targets were added successfully.
The cataloging interface is quite user-friendly overall, although many of the options would definitely be clearer to an experienced cataloger. The first task undertaken here was to add MARC records and catalog entries for several new items. For this exercise, Z39.50 searching was used to import the items into Koha. Experimenting with the different frameworks, unfortunately, created error messages (it was easier to make the changes after the record had been created). An interesting observation at this point is that the Koha presentation of the MARC metadata makes it much easier to grasp the overall structure, as opposed to simpler text-based representations.
Actually adding the new items was quite simple especially given the low level of detail and accuracy needed for a purely hypothetical project. There were some problems with the type field being set by default to 2-Hour reserve, which in some cases was unfixable. In other cases, the existing user-set types and categories could lead to conflicting records (because of difficulty matching appropriate terms). This is likely a result of many people using this installation of Koha for different projects, rather than any inherent problem with the software, however.
Once added, creating new items for each record was quite simple, with the exception of the automatically-generated barcode being in all cases unusable. Entering a barcode by hand, however, made it quite simple to create one or even several new items, with Koha incrementing the barcode as appropriate. The interface at this stage was not the most fluid, in some cases requiring several steps to get to the right sub-page to make edits on a particular item, for instance. In a real implementation, though, it is almost certain that most users would not have access to this functionality, so only cataloging and collection-development staff would likely need to be expert in navigating the interface.
Patrons and Circulation
Several new patrons were created, which again was quite easy and intuitive since the individuals involved were hypothetical. It may be that this would have been more intimidating to a user who had never looked at a library borrower record simply due to the large number of fields, and possible confusion over the relative importance of filling them. It would be vital for a library using Koha to establish strong policies about the creation of new patron records to help solve this problem. Another option would be to edit directly which fields are required to be filled by the software, but it was not apparent how such an adjustment could be made.
Checking out materials to the newly-created users was also extremely simple and user-friendly. Koha’s interface for finding a patron (with auto-completing search!) is highly useful, although in most practical applications staff would probably be using a barcode scanner or other automated method of identifying the patron. The patron information view screen is probably the most streamlined portion of the interface – the only change that would be excellent would be the ability to search for an item and interface that search with the patron record, for instance to check out an item without the barcode. This might be an intentional limitation however, to only allow physically-scannable or present items to be checked out. The similar “Search to Hold” function is extremely useful for placing holds for a patron.
The Acquisitions module was the most problematic of the areas of Koha, as was already mentioned above. The primary task here was to place orders for publications using the already-created ALA vendor. This process was, honestly, horrible and non-intuitive. The simple auto-complete elements prevalent throughout the Koha interface actually cause problems for the non-expert when placing orders. In other words, using the search function for items to add is very streamlined but actually has nothing to do with the vendor – the acquisitions staff member would actually have to know what items were being purchased, and the relevant information for each, and enter these manually. This isn’t a problem, but the interface does not make that fact apparent so a new user could easily place orders for items not actually provided by the listed vendor. Acquisitions is definitely an area that should only be unlocked for authorized staff.
Another glaring problem with the Acquisitions interface was the non-intuitive interaction with the Funds and Budgets that had already been established. The order interface has a drop-down menu with Fund choices, but only three are actually present – General Book Fund, Replacements, and Serials. The way the software seems to work is that the purchase order can be duplicated for each fund – placing an order for 5 items sometimes results in a shopping cart with 30 or more items distributed between the different funds previously defined. Other orders do not show this effect, and the difference is not clear.
Overall, it would seem that the Acquisitions module is, unlike most of the other areas of Koha reviewed so far, really intended only for those with training or experience with purchasing and acquisitions. It seems likely that an experienced purchaser would be able to navigate the menus and options, but for the uninitiated the interface is not intuitive.
Reports and Tools
Koha’s Reports and Statistics areas are powerful but not highly user-friendly. One serious usability flaw, at least for the new user, is the lack of ability to go back and forth between parameters and results. Once one finishes the wizard all one can see is the SQL code. This code can be tweaked manually, but that is really an expert function. In other software, for instance in something like SirsiDynix WorkFlows, one can open up a previously saved report and edit the parameters in the same GUI as before, and either make a new report from that or update the existing report. That ability would be hugely useful in a situation like this one, where users are trying to experiment and learn about the system – to try out a report, see if it does what is intended, and then make changes. Instead, once a report is created the only option if it does not work as intended is to examine the SQL code and restart the wizard. However, the reports interface is very powerful and apparently quite extensible, so if one spent time and energy learning all the parameters and design functions (by looking at other libraries’ existing reports, for instance) one could set up some really good canned reports to get the needed data. Still, Reports are the area most likely to need instructions or manual reading to make them work.
The Tools module contains a variety of advanced features that don’t fit in naturally elsewhere, but connect to the other modules (Cataloging, Patron information, Circulation, and even Reports). Some interesting options are the spine label printer, which helps automate the process of adding new books to a collection (assuming they don’t come pre-labeled from the vendor). Batch functions such as the patron anonymizer or the batch item editor would come in handy in larger libraries that regularly have to handle significant volume of operations. Finally, for data-gathering, the task scheduler tool allows for the automatic generation of reports and other statistical operations so that this doesn’ t have to be done by hand. The Tools module is clearly also a prime area for customization and extension via user-designed add-ons specific to a particular library’s needs.
Overall, Koha has an extremely user-friendly interface which makes many tasks that are challenging in more traditional ILS systems quick and easy. In particular, the browser-based nature of the software means that multilple operations can be performed at once, letting the user share information back and forth between browser tabs. The wiki-like hyperlinking of each area to other possibly-related tools is also excellent. Ultimately, while there are some areas of the interface that are not transparent to inexperienced users, this is really to be expected as these are specialized functions that would only be used by specialized staff with the appropriate training and skills.