Really interesting discussion the other week with a company that LSE has contracted to provide university services on smartphone platforms (iPhone, Android platforms, etc). Part of what they want to do is to provide library self-service options on the mobile. We talked about the middleware that we’ve developed and suggested this as a way of hooking up to our library management system. Their developer was very interested! We still need to thrash out whether this is a feasible / desirable way to go, but it shows that the API has real possibilities for working in lots of platforms.
In November we emailed some information about the Library Widgets toolkit to the Voyager lists (prime targets for the early versions of the middleware) and caused a minor controversy: it turns out that several US sites don’t have the Voyager SIP2 server, which is not part of the standard contract and must be purchased separately. It’s essential for self-service (and for our API), and fairly commonly used in the UK, but there was enough interest in what we were doing to provoke at least one Voyageur to write an open letter to Ex Libris asking for a change to the SIP2 pricing model!
We’d made a conscious decision to tackle the easier parts of the project first – starting small and building up functionality of the API as we learned more about the technologies we were using. The really big goal, for the end of the project, was to get online fines payments working. Unlike the other modules in the middleware, this would represent functionality that we couldn’t currently replicate through any other system, and would open up a completely new service – allowing students to pay their fines online.
Getting the basic fines payments to work actually turned out to be a lot simpler than we had feared – probably because by that stage we’d learned enough about SIP2 to be able to integrate the payment calls into the API relatively seamlessly. We had to use our development ILS server, which is on a later version of the Voyager software than the production server, as it is only this later version that supports the correct SIP2 calls. It took a little tweaking of the SIP2 server on Voyager before we could connect through, but it was a wonderful moment when we finally managed to pay off a fine using the middleware.
As it stands the middleware does not support end-to-end payments by itself – individual sites will need to integrate with their own local payments systems before it could be used. However we still think this was a real breakthrough moment for the project. For Voyager sites our experiment has proved that the SIP2 changes in Voyager v.7 really do work, and that the ILS does now have the potential to hook up to fine payments services. We think this part of the Library Widgets Toolkit could potentially be an incredibly useful bit of code for libraries that not only want to spread self-service out to alternative platforms, but that also want to expand the range of services accessible online. For us – and we believe for many other sites – this functionality has been the missing component in our online services, so getting the SIP2 part to work was a real step forward!
Getting the VuFind widget working was a particularly sweet moment for the project team. We’d experimented with the basic SQL / SIP2 functionality already, and knew that we could carry out transactions on the the Voyager ILS. We’d started to pull that together in an early iteration of the iGoogle gadget. But developing the renewals widget for VuFind meant pulling the technology into a completely different environment (PHP) and integrating with another existing complex system. It showed that the middleware we’d constructed really was robust enough to allow us to integrate self-service into a variety of environments and web applications.
Perhaps more importantly than that, the renewals widget was the first time we’d really seen major usage of the software in a live production environment. Plugging it into VuFind meant that the middleware – which we’d previously hit with a few hundred calls a week – was suddenly being used by thousands of students every day. That did throw up a few quirks: we quickly discovered that the way Voyager dealt with hyphenated surnames didn’t work the way we had thought, and we had to do some rapid troubleshooting to sort the problem, but after that the widget worked smoothly, and has been a major success in making core functionality available from the VuFind interface. As of November c.6,000 students (66% of LSE’s entire student body) have used this widget at least once!
With the exception of Ofer, our part-time developer, the project team all work together in a single office, meaning that communication was always straightforward. However we still had regular weekly meetings where we could ensure we were all up to date with developments; could review progress so far; and decide on priorities for the coming week.
Although we had a very broad idea of the sequence of developments, and a rough guesstimate of how long each might take, we mostly decided priorities on a week-by-week basis. That gave us a lot of flexibility about how we progressed compared to fortnightly or monthly review meetings, and meant that we could turn on a dime: it was during the weekly meetings that we made decisions such as abandoning investigation into OpenAuth, and on shortening our internal deadline for the iGoogle gadget.
We endeavored to keep the meetings as short and snappy as possible (most were half an hour or less), often gathered around Shiraz’s computer, squeezed between desks – which seemed to focus everyone’s thoughts, and led to very clear decisions on priorities.
This became a favourite phrase of Mike F.’s during the project: timeboxing meant giving very clear limits on how much time could be spent on different aspects of the project. If we timeboxed a part of the project and couldn’t complete it within the timeframe we’d given ourselves… we dropped the work and moved on. As with the short weekly meetings, this really seemed to focus our minds and led to very clear decisions about our priorities. This was an excellent discipline, which probably saved us from getting bogged down in some peripheral technical issues (the iGoogle gadget, for example, could have taken weeks more work and still not worked entirely as we wanted; the Moodle widget was interesting, but we had to limit development in order to leave enough time for proper work on the fines payments API).
For most of the project the development was being carried out by a single person, Shiraz. It was impractical to ask him to write long blog posts explaining the technical intricacies of the work he was doing – or he wouldn’t have had time to actually do any developing. A compromise that seemed to work really well was for Shiraz to tweet rather than blog: short, snappy messages, that recorded the basic detail of what areas he was looking at, and the wins and losses he experienced as he experimented with different technologies.
We collected the tweets into the blog using a WordPress plugin, and then Michael F. would go in and flesh them out a little, putting them in the context of the project, or adding useful details. These expanded tweets became the core of the blog, with occasional longer posts when particularly interesting events happened.
For those of us involved in the project this was really our first practical use of blogging / tweeting project work, and it was great to use a medium that encouraged a slightly less formal approach. We’re all used to producing quite dry project reports, but knowing that at the very least our poor programme manager would be reading our words made us focus on making the blog readable, interesting, and useful. It didn’t hurt to have a little competition from some of the other JISCRI projects either: we certainly started using more images after seeing how effectively they helped to illustrate the work that some of the other rapid innovation teams were doing. The result was that we stopped treating the blog purely as a formal project requirement, and started having a lot more fun with it.
Part of what we were about was getting other libraries to pick up and use the toolkit, and to start experimenting with the middleware and perhaps even developing their own widgets. We used our own interests and requirements to construct the user case for other libraries: we assumed that, like us, they would:
- Want to expand the use of self-service
- Want to provide self-service in the most convenient place for their students
- Want something that could be easily picked up and used, with very low maintenance and support costs.
We publicised the API directly to mailing lists for the Voyager ILS as the core API was written to work with Voyager, so early adopters would have to come from this pool. We also publicised it several times on the mailing lists for VuFind, as we felt sure that the kinds of libraries interested in experimenting with this open source OPAC would be more likely to be willing to experiment with our middleware – and the API was offering functionality that didn’t work in the native VuFind interface. This did provoke expressions of interest from several libraries – most notable Edinburgh University, and we had three different institutions (Plymouth University, Open University, Aberystwyth University) who each, at various times, experimented with the API. Perhaps unsurprisingly the key thing for every one of them was documentation – asking us to improve and expand the documentation so that implementing the middleware could be as close to a plug-and-play experience as possible. Towards the end of the project I think we got a lot closer to that ideal. Plymouth unfortunately didn’t really have the time to experiment with our software beyond initial downloading and perusing the code; the OU got the basic middleware working on a laptop, but didn’t get a chance to pursue any further; but by the end of the project Aberystwyth, with a little help from Shiraz, were able to set up the middleware from a standing start in just one day – emailing us in the morning, and then getting a working system by the afternoon.
I really appreciate the library app. really awesome and making my life so much more convenient…are you going to do something for the iPhone too?
LSE Student, commenting on the Facebook application.
The Widgets project was focused on two different types of ‘users’: the students at the LSE who would be using the widgets we were plugging into VuFind, Facebook and Moodle; and the library staff in other institutions who we were asking to experiment with the API, and who we hope will eventually want to write their own widgets and / or expand the middleware code. This post focuses on the students.
For this group of users the project was essentially about transferring functionality from one place to another: making the renewals button and loan information that was already available in our classic catalogue available from other websites and applications. As a result we didn’t spend a great deal of time thinking about the user case from the students perspective: it seemed to be a proven case, which library ILS’s had been attempting to meet for decades. The result has been a fairly utilitarian look and feel to the widgets, with basic information and a big button that says ‘renew’ (which you click on if you want to, you know, renew your books…) – very similar to the equivalent screens on our classic OPAC interface.
On the whole we seem to have met the basic needs of the students. Feedback has been limited, but where we have had comments it has mostly been to tell us that we haven’t been quite ambitious enough, with requests for additions to the display functionality, or even requests for integration with other applications (iPhone, etc), rather than complaints about the core middleware. For example we’ve been asked to add options to sort loan information by loan-date, due-date, or by level-of-fine; we’ve been asked to provide totalled summaries of outstanding fines; and we’ve been asked to add due times as well as dates. The latter was easily remedied, but time pressure has meant we haven’t been able to revisit other aspects of the interface in great detail, and this remains an opportunity for development after formal project completion.
Seeing a widget working on a test version of Moodle was an exciting moment, which really helped to emphasise how useful the widget approach could be. Moodle is essentially a ‘control panel’ for students, giving them access to the teaching-related material they need. Plugging in the Library widget, to allow them to renew, check their loans, and eventually pay fines, really made it clear how seamlessly students would be able to experience the library as part of this overall learning application.
The VuFind widget was great, but was fundamentally replicating standard OPAC functionality. The Facebook and iGoogle gadgets were also good, but still required the students to go out and find the widget and to then choose to plug it into their iGoogle dashboard, or add it to their Facebook apps.
The Moodle widget was different because it sits permanently as a block on the main control panel of the Moodle page – a permanent, easy-to-use, entry point to library services. It really got us thinking about ways of presenting the information in a more useful way as part of a wider interface: perhaps the initial block should just contain summaries of basic loan information (e.g. “You have 10 books on loan, 3 overdue, 2 nearly due”) with further information and functionality when you clicked on the link. The Moodle widget was the first time we really saw how the software we were developing could enhance other educational and learning services – and be a useful cog in a much bigger machine.
Comments (0) 
Themocracy