Get Tooled Up: Xerxes at Royal Holloway, University of London
Rarely is software a purely technical issue, though it may be marketed as ‘technology’. Software is embedded in work, and work patterns become moulded around it. Thus the use of a particular package can give rise to an inertia from which it can be hard to break free.
Moreover, when this natural inertia is combined with data formats that are opaque or unique to a particular system, the organisation can become locked in to that system, a potential victim of the pricing policies or sluggish adaptability of the software provider. The speed of change in the information world in recent years, combined with the actual or expected crunch in library funding, has made this a particular issue for library management system (LMS) users. While there is general agreement on the direction to take - more ‘like Google’ - LMS suppliers’ moves in this direction can prove both slow and expensive for the user.
Open source software has often been suggested as an alternative, but the nature of lock-in means that the jump from proprietary to open system can be all or nothing; in effect too big (and complex) a risk to take. No major UK university libraries have yet moved to Koha, Evergreen, or indeed any open source LMS [1].
The alternative, which brings its own risks, is to take advantage of the pressures on LMS suppliers to make their own systems more open, and to use open source systems ‘around the edges’ [2]. This has the particular benefit of creating an overall system which follows the well-established design practice of creating a clean separation of ‘view’ (typically the Web interface) from ‘model’ (here the LMS-managed databases) and ‘controller’ (the LMS core code). The ‘view’ is key to the user experience of the system, and this separation gives the ability to make rapid changes or to integrate Web 2.0 features quickly and easily, independently of the system back-end. The disadvantage of this approach is that it is relatively fragile, being dependent on the willingness of the LMS supplier to provide a detailed and stable application programming interface (API).
There are several current examples of this alternative approach. Some, like the Vufind OPAC, allow the use of plug-ins which adapt the software to a range of different LMSs. Others, like Xerxes, are specialised front-ends to a single system (MetaLib from ExLibris [3]). This has an impact on evaluating the software: in particular, the pool of active developers is likely to be smaller in the latter case.
Royal Holloway Library Services
Within this general context, Royal Holloway Library Services were faced with a specific problem. The annual National Student Survey had given ratings to the Library well below those expected, with many criticisms centred on the difficulty in using the Library’s MetaLib federated search system.
MetaLib is a key access point to the Library’s e-resources, incorporating both A-Z lists of major online databases available to library users, and a federated search tool. Feedback showed that many users found the interface less than satisfactory, with one user commenting that:
‘MetaLib is possibly the worst and most confusing library interface I have ever come across’
The Library Management Team decided to remedy this as a matter of urgency and set a deadline of the start of the 2009 Autumn term. There was no funding available to acquire an alternative discovery system so the challenge was to identify a low-cost, quick-win solution for the existing one. With this work in mind, the incoming Associate Director (E-Strategy) had already recruited two new colleagues over the Summer vacation: a systems officer with Web development experience, the other an experienced e-resources manager.
The first possible route to the improvement of MetaLib was modification of the existing MetaLib Web interface. This was technically possible but presented several major difficulties: the underlying ExLibris designs were based on the old HTML 4.0 and pre-dated current stylesheet-based design practice; the methods to adapt the designs were opaque and poorly documented, based on numbered variables with semantics that changed depending on context; and perhaps most importantly, the changes were to be made over the summer months, giving no time for user feedback on the details of the changes to be made.
The second possibility was the use of Xerxes [4]. Xerxes offered the advantage of an interface design which had been user-tested on a range of (US) campuses, partially solving the user feedback issue. It was not, however, entirely cost-free, as ExLibris charges an annual maintenance fee for the MetaLib X-server API on which Xerxes depends.
Evaluation
The questions that arose before deciding whether to adopt Xerxes were those needed to evaluate any open source software:
- Are the software dependencies easy to satisfy?
- How reliable is the distribution method for updates?
- Is the development team large enough to ensure continuity?
- What is the quality of the software?
- How responsive is the development team to feature requests and bug reports?
- How responsive is the community to requests for help?
- What is the quality of the documentation?
- Are there any licensing or trademark issues?
- Will the software need modification for local use?
Consequently, there is a mix of social, technical and legal issues to consider. They comprise a subset of the questions asked in formal methodologies such as the method for Qualification and Selection of Open Source software (QSOS) [5]. A full-scale formal QSOS evaluation was not felt appropriate for two reasons.
Firstly because of the lack of other options: this was a decision on whether or not to use a particular piece of software, rather than a comparison between competing options. Secondly, because the use of Xerxes did not represent an irreversible decision: since it was simply providing an alternative view of the MetaLib back-end, it was always possible to revert to the native MetaLib view. The local implementation could itself be considered an extended evaluation.
The approach taken instead was to carry out test implementations on different systems. As the final intended host was running RedHat Enterprise, only Linux- based systems were used; although Xerxes is also known to run on Microsoft Web servers.
The first installation was on a laptop running Gentoo Linux. The installation with all basic functions supported took one morning with no significant interaction with the development community. As a result of this experience, most of the technical evaluation questions could already be answered. The software was then installed on a pair of machines running CentOS (a free equivalent to RedHat Enterprise), one to be used for testing and development, the other to be employed in user evaluation. This installation was required to provide the full functionality needed for the local environment, which led to significant interaction with the development community.
The initial questions could now be answered:
Xerxes depends on recent versions of the PHP language with its PEAR libraries, and the MySQL database. Not a problem for our new Linux installation (though it would have been for our former elderly Solaris host).
The software is available as an official release or as the development version available from a subversion repository [6]. As the repository version was known to be a significant improvement on the last release, this was adopted as the basis for development work with the intention of switching to a stable version later. The development version itself was found to be kept in a good, working state, and its use has not presented difficulties (though no direct updates from this version are made to our live server, as described below).
There were only two main Xerxes developers. Normally this might have proven problematic, though it was inevitable that the pool of developers for a project that depended on a particular proprietary product would be smaller than that for an equivalent standalone one. Fortunately the two developers were energetic and involved, worked in different institutions, and the project also benefited from a larger periphery of occasional contributors who might step in when problems arose.
The software was well organised (being built around standard PHP design patterns such as the FrontController pattern) and clean, without accumulated bug fixes. In particular it was designed to allow parts - particularly the XSLT templates - to be overridden without any need to touch the core code. This meant that difficulties in integrating local changes with updates to the main codebase were kept to a minimum.
The development community turned out to be a dream to work with (even though, so far, we have been nearly all ‘take’ and very little ‘give’). Requests for help were answered within hours; and requests for advice on local changes were more likely to be answered with ‘that’s now added to the core code’ than ‘here’s how to do it yourself’. We never found the need to report any bugs to the developers, although we observed that bugs reported by others were fixed within days or even hours.
Documentation proved perfectly adequate: installation and configuration documentation was placed on a wiki, which for once is kept up to date. The code was reasonably well commented. Moreover, the application was in any case small enough to be comprehensible.
The licence was the GPL [7], one of the two most common free software licences, which therefore did not attract any legal surprises. Xerxes is not trademarked (and did not even then have its own logo). As a courtesy, a ‘powered by xerxes’ link was added to our installation.
This left the final issue: what changes needed to be made to the software for local use?
Local Development
Local changes divided into two main categories: changes to the Xerxes interface itself, and changes required in the categorization of content in MetaLib to suit the simplified user interface.
Changes to Xerxes
Almost any implementation of open source software needs some adaptation to local requirements; the goal here was to minimise the number of local changes that would impose long-term support and complicate future updates. Xerxes is designed to make this simple: the output from the Xerxes code is XML, which is then processed by XSLT scripts to generate the Web pages the user sees. In many cases all that is needed for local changes is to override the supplied XSLT code, which does not even need to be replaced. This technique was used both to apply the Royal Holloway branding and to split the list of displayed categories into two lists - one organised by format, the other by topic: to add new menu options in order to integrate Xerxes into the Royal Holloway Library Web site, and; to add short descriptions to the search results (which defaulted to title/author information only).
Other changes needed some coding; this was either done by request to the developers (e.g. incorporation of an SFX journal list, which was made easier by building in support for locally defined ‘actions’) or in Royal Holloway (e.g. addition of a facility to stop long searches while still in progress, a change which was fed back to the developers for incorporation in the trunk). The end result has been a system for which locally developed material consists only of XSLT scripts and a short script to integrate with the Patron Directory Services (PDS)/Athens authentication system used by Royal Holloway. This minimises the work needed in applying Xerxes upgrades.
Changes to MetaLib Category and Content Organisation
As well as difficulties with the federated search interface, feedback showed that users had difficulty navigating the A-Z database lists in MetaLib. Our first step was to review the resources included in the A-Z list. MetaLib listed over 600 resources, over 75% of which were freely available Internet resources. Usage statistics showed that few users were interested in the free resources, so we removed the low-use free resources to leave a more manageable list of around 150 resources, most of which were high-quality, paid-for resources.
Our second step was to review the subject categories. As well as single A-Z browse list of all resources, MetaLib supported subject A-Z lists, each of which was further divided into multiple sub-categories. We simplified these categories by reducing the number of sub-categories to just two per subject - ‘Core’ for key resources, and ‘More’ supplementary resources, creating more easily browseable lists which highlighted the key resources for each subject. We also added new categories grouping by format, for example adding A-Z lists of all resources for ‘e-journals’, ‘e-books’ and ‘newspapers’.
The result was a set of A-Z menus which made it much easier for users to locate key resources, either by subject or by type. Combined with the improved Xerxes interface, it also made it much easier to select resources for federated searching.
SWan Partner Access
One extra element of complexity was introduced to the implementation late on in the process. Royal Holloway is a member of the SouthWest London Academic Network (SWan) [8] along with Kingston University and St Georges’s Medical School, University of London. SWan was established to offer joint courses in biomedical, health and life sciences. Each member was asked to provide library access to their individual collections of electronic resources for SWan users for the start of the 2009⁄10 academic session. Once legal advice on licence conditions had been taken from JISC Collections, the challenge for each institution was
- how to ensure SWan users had access to only the subset of each institutions’ e- resources they were entitled to access, and;
- how to present such access in an efficient and simple way without confusing users.
In the case of Royal Holloway, the Library needed to identify SWan users, authorise those users employing AthensDA to access a selected set of its e-resources subject to licensing arrangements, and present that set of resources in MetaLib, clearly indicating that SWan users could use them.
The first step was to identify SWan users. The Library added new user statuses to its Aleph library user database. Then, SWan user information was added to Aleph. In the case of SWan students, details were obtained via a feed from the College’s student record system.
The next step was to create SWan permission sets at Athens. Then, the script, handling authentication for MetaLib and Athens authorization, was changed to identify SWan users when it looked up user details in Aleph, assign them to the appropriate permission sets, and transmit this information to Athens. At this point SWan users would be authorized to use the resources in the SWan permission set to which they had been assigned.
The final step was to change the MetaLib log-in process so that SWan users were identified in the MetaLib database, thus enabling resources to be clearly designated as being available to SWan users. This was done using MetaLib’s secondary affiliation mechanism. Data from the script was used to assign SWan users with a SWan secondary affiliation. The SWan secondary affiliation was also added to resources available to SWan users. This enabled MetaLib to display the resources appropriately, depending on whether the secondary affiliations of the users and resources matched or not.
The independence of Xerxes from the MetaLib back-end meant that this work could be carried out in parallel with the Xerxes implementation, with Xerxes enabled to discretely signpost user entitlements for each resource and offer an automatically generated browse list of SWan resources that could be linked to from the College Portal.
Final Setup
Our final configuration involved four hosts: our Solaris host running MetaLib; then a test server running our development version of Xerxes; a staging server, with a version of Xerxes guaranteed to be running; and the live Xerxes host, a virtual Linux server. Local enhancements were developed on the test server, backed by a local sub-version repository, tested on the staging server, and then uploaded to the live server. Updates to the core code were downloaded from the remote repository to the test, staging and live servers in sequence.
Now development work is largely complete this configuration will probably be simplified by removing the test server.
All three servers connect to the MetaLib X-server to carry out queries. But Xerxes also holds information locally: users’ saved searches and records are held in a local database since the ExLibris API does not allow them to be queried remotely, while subscription databases and subject categories are also listed locally for speed of lookup. These latter data need to be syncronised periodically with MetaLib’s own database (for which a script is provided).
At this point both Xerxes and the MetaLib native interface were available to end users. Just before the start of the September 2009⁄10 term, we switched the links from our Library Web site to the native interface to point to Xerxes instead [9].
We had made the decision not to confuse students by introducing yet another library application name (in addition to MetaLib, SFX, Refworks, the OPAC..). So we decided to retain the ‘MetaLib’ name and existing students users were simply told that there was an updated interface to MetaLib.
Initial reactions were largely positive. A small number of users gave concrete feedback; e.g.:
‘[I find] the new MetaLib significantly improved… the interface is obviously much better (even paging backward and forward was an issue before)… research is quicker and more focused.’
and
‘I used MetaLib to find material on Molière for an essay; I’m impressed by how easy it was to find things, including material in French.’
One existing user found there was functionality missing from Xerxes which we could not provide immediately (namely a user-specific list of frequently used journals). That user was simply pointed to a link to the MetaLib native interface, and a request for the extra functionality was sent to the Xerxes mailing list.
Next Steps
The relatively painless introduction of Xerxes has encouraged us to experiment further along these lines. Future anticipated projects include:
- Improving our user statistics: we can only justify continued work if we can show a quantifiable impact on user behaviour (before the next National Student Survery comes around!). The Xerxes installation showed up the weakness of our current collection of statistics.
- Work on the SFX user interface. Here we believe that that simplifying the native interface may provide many of the benefits of switching to the open source front-end Umlaut [10] with less support work. But Umlaut also offers new integrated functionality such as article citation data and pre-populated interlibrary loan forms. We need to evaluate both options.
- Work on the Aleph OPAC user interface. This suffers from some of the same issues as MetaLib, but as we are currently upgrading to a more recent version of Aleph, we are taking advantage of this process to try local improvements directly on the Aleph interface itself. At a later stage this will give us a fairer comparison with the two open-source alternatives, Vufind and Blacklight.
Conclusion
It seems likely that we are moving with the grain of current developments and thereby addressing some of the recommendations in the JISC/SCONUL LMS report (e.g. increasing interoperability and ‘sweating assets’) [2]. If, in future, LMS suppliers will be concentrating on the core LMS functionality with an increasingly large proportion of the periphery occupied by other options, almost certainly largely open source (though the same changes that make open source applications possible in this role open a space for niche suppliers of specialised proprietary software; the development of Serial Solutions’ Summon [11] in conjunction with Vufind is an early sign of this trend). If this situation is financially viable for LMS suppliers in the long term, then the mix could be a healthy one for libraries, with a range of competing proprietary and open source products reducing the risks inherent in dependence on a single supplier. On the other hand, if this situation proves not to be stable (or financial constraints change greatly) early usage of open source products at the periphery of the system will put libraries in a better position for a larger transition. Our experience with Xerxes has shown us that such early usage is relatively low risk and low maintenance, and can provide a positive contribution to the user experience.
References
- Some smaller libraries have already begun to take this step; see Bissels, G, Implementation of an open source library management system, Emerald Group Publishing Ltd http://www.emeraldinsight.com/0033-0337.htm
- A tendency discussed in Adamson, V., et al, “JISC & SCONUL Library Management Systems Study” 2008. Sero Consulting Ltd with Glenaffric Ltd and Ken Chad Consulting Ltd http://www.jisc.ac.uk/media/documents/programmes/resourcediscovery/lmsstudy.pdf
- MetaLib http://www.exlibrisgroup.com/category/MetaLibOverview
- Xerxes Metasearch http://xerxes.calstate.edu/ The lead developers of Xerxes are David Walker, Library Web Services Manager, California State University and Jonathan Rochkind of John Hopkins University.
- The QSoS methodology has recently been used for an evaluation of three open source LMSs http://www.qsos.org/
- Subversion is a widely used software version control system http://subversion.apache.org/
- The GNU General Public License - GNU Project - Free Software Foundation (FSF) http://www.gnu.org/licenses/gpl.html
- SWAN: SouthWest London Academic Network http://www.swlacademicnetwork.ac.uk/
- Actual use requires a University account, but the front page can be seen at http://xerxes.rhul.ac.uk/
- Umlaut http://wiki.code4lib.org/index.php/Umlaut
- Summon http://www.serialssolutions.com/summon/