Comments (0)

By admin, February 1, 2010 4:59 pm

The JISC project formally came to a close at the end of November 2009, but that’s not the end of the road for Library Widgets. We’ve got a number of things we’re planning to develop further.

JISC extension

There was a small amount of money left in the budget at the end of the project, and JISC have very kindly agreed to let us use this underspend for some targeted work on some parts of the widgets that we didn’t have time to complete during the six months of the project-proper:

We can’t replicate the same rapid innovation approach immediately, because staff have already been assigned to other projects and tasks, so we’re still working out exactly who is going to do the work, and when, however by August 2010 we aim to have completed the following:

• Update to the Facebook widget, to allow for display of recall information.
• Update to the Moodle widget, so that it displays information and alerts about overdue and nearly-due books in a “traffic light” display.
• Similar functionality to be added to the VuFind widget.
• Updated documentation, particularly for Facebook, but including the additional functionality in other widgets.

Further work

Beyond that we’re still intending to continue work on these in-house. We’ve been helping a few other sites who have been experimenting using the middleware and widgets in a few different contexts, and we’re finalising an internal project to get the end-to-end payments working with LSE’s in-house finance system: so that eventually we can use the widgets to offer online fines payments to LSE staff and students.

Comments (0)

By admin, November 27, 2009 10:07 am

A formal summary of the project for JISC:

• Title of Primary Project Output
  • JISCLSWT: The Library Social Widgets Toolkit – allowing libraries to embed core self-service functionality into the online applications that their students use.
• Screenshots or diagram of prototype
  Screenshot of the Moodle widget in production:
  
  
  

  

• Link to working prototype
  • Although the widgets are in production use, a demo prototype is not available as it would require an LSE library account. However we have created some brief Youtube screencasts of the Library Widgets in action.
  • Google Gadget:
    YouTube clip
    
    Add the production Gadget (LSE account required)
    
  • VuFind Gadget:
    YouTube clip
    
    Use production widget (LSE account required)
  • Facebook App:
    YouTube clip
    
    
  • Moodle Block:
    YouTube clip
    
    Use production widget (LSE account required)
    
• Links to end user documentation
  • About the project
  • Moodle block
  • Google gadget
• Link to code repository or API
  • Code Google
• Link to technical documentation
  • Installing the middleware: Code Google wiki
  • Using the middleware
  • Widget documentation
• Date prototype was launched:
  • The current middleware sourcecode was released on November 12th.
    
• Project Team Names, Emails and Organisations
  • About the team
  • Shiraz Azizali, s.azizali@lse.ac.uk -London School of Economics & Political Science, Lead Developer
  • Ofer Engel, o.engel@lse.ac.uk – London School of Economics & Political Science, Developer
  • Michael Fake, m.fake@lse.ac.uk – London School of Economics & Political Science, Project Manager
  • Tim Green, t.green@lse.ac.uk – London School of Economics & Political Science, Project Sponsor
  • Michael Hallas, m.hallas@lse.ac.uk – London School of Economics & Political Science, Technical Coordinator
• Project website
  • Library Widgets website
• PIMS entry
  • https://pims.jisc.ac.uk/projects/view/1391
• Table of Contents for Project Posts:
  • Value added
    • First public widget
    • Moodle
    • Fines payments
  • Technical standards
  • User participation
    • The students
    • Other libraries
  • Day-to-day
    • Pair programming
    • Twitter and Blogging
    • Timeboxing
    • Weekly meetings
  • SWOT analysis
  • Wins & Losses
    • ‘WIN’ posts
    • ‘‘LOSE’ posts

Comments (0)

By admin, November 26, 2009 4:25 pm

Encouraging statistics from the Moodle widget: within one day of going live – and without any advertising or publicity – 45 new students have found the link and used it.

Comments (0)

By admin, November 26, 2009 2:37 pm

All four of our widgets are now in production, but unfortunately we can’t give you a demo account access – all transactions are live on our library system. However we have made four very short screencasts of the widgets being used:

The Google Gadget:

The VuFind Plugin:

The Facebook App:

The Moodle Block:

Comments (1)

By shiraza, November 25, 2009 6:05 pm

Here’s a look at the space immediately behind my cup of redbush:

Core Technologies: Groovy and Grails!

Grails is a modern open source full-stack web application framework for the Java platform.
It employs a DRY (Don’t Repeat Yourself) and ‘convention over configuration’ approach to reduce complexity; very quickly allowing you to get on with iterative agile development.

Furthermore, it allows you to take advantage of the following best-of-breed technologies without necessarilly needing to be an expert in them:
Spring, Hibernate (Object Relational Mapping), SiteMesh (view templating/decoration), jUnit (testing), log4j (logging), etc.  The Groovy programming language is used, though you can always mix in Java, because it integrates seamlessly.

Grails comes with support for unit, integration and functional (via. the G-Func plugin) tests.

Development Tools: IntelliJ IDEA, Firebug, Poster.

I use Jetbrain’s IntelliJ IDEA IDE for Grails development on the Ubuntu linux distribution.
Along with good language and framework support it eases code management through a SVN plugin and a fully integrated and interactive visual diff tool; check this out:

There are plugins to do everything save launch spaceprobes!

Also essential on a daily basis are Firefox’s Firebug and Poster add-ons.

Quake Guake

During the course of the project I have become heavily dependent on using a Quake-style drop-down terminal for GNOME called guake.  It’s main benefit is that it can toggled on and off through a key combo – simple eh?  I now never have to hunt around for multi-tabbed terminal windows.

Twitter

Many of the posts in this blog were fed in from tweets, TweetDeck and gwibber are the clients that I gravitated to.

jQuery

I have adopted  jQuery as my JavaScript library of choice.  It’s lightweight, fast and fosters the  separation of a site’s  behaviour cleanly into a separate layer.  Furthermore, it eases the development skinnable user interfaces via. jQuery UI.

REST

Our API tries to implement ideas from the RESTful approach to web services in it’s reliance of HTTP methods, status codes, and resources.  The book ‘RESTful Web Services‘ by Richardson and Ruby is an essential read.

Comments (0)

By admin, November 25, 2009 10:20 am

We tried to track ‘wins’ and ‘losses’ throughout the course of the project, but looking back we seemed to be a lot more ready to record the wins than the losses! Probably because when we hit a snag we were more busy trying to sort it out than to blog about it.

We did post about some hiccups we encountered, but looking back, these are some of the other problems we hit, and roadbumps we ran into:

Google gadgets: dude where’s my $JAVASCRIPT_LIBRARY ?

Maybe I’ve been spoiled but I found gadget development frequently frustrating:

• Documentation was quite fragmented; some important info. was only to be found in the dev blog or forums; for example, I eventually found out that there is a regular and production sandbox controlled via. a URL param: ?force_prod=1
• Code can silently fail making debugging difficult, even when using the sandbox/dev gadget.
• There’s no option to use a common javascript library (dude where’s my jQuery?)
• Linking to include external JavaScripts often caused performance issues!
• I identified a lack of hooks for my events in various places,  for example I’d like to run code if the user decides to delete our gadget (a RESTful DELETE request to our middleware)
• Significant differences between the Development sandbox and Production environments. It meant that what seemed to be working in the sandbox would fall on its face in the production environment.
• Took time to work out that the Google Gadget Editor was a waste of time: it didn’t fully support OpenSocial or allow makeRequest calls to be made.

Timeboxing literally
We ran out of time on quite a few things:

• ‘Dear user: 10 of your books are going to become overdue in 24 hours time! Wouldn’t you like to renew them?’ We ran out of time to incorporate this sort of helpful alert to users into our Moodle Block;  we even finished writing the API call!
• We had intended to implement OAuth because it appears to offer a standard for enforcing trust between the provider of an API and it’s consumers, and for delegated user authorisation. In practice OAuth wasn’t necessary to deliver the functionality we wanted.
• The Widgets included in the toolkit could have been shinier and prettier.

Facebook

We didn’t put together Facebook documentation in time for the project deadline – unfortunately our part-time developer who was doing the Facebook work had too many other commitments.  More significantly we had to row back on going into production with the Facebook widget: we already had a technologically inferior Facebook app, that used screen-scraping technology, but the screen-scraping meant that it could display reservations / recalls which our middleware API did not. It would be difficult to ‘lose’ this function, so whilst we’ve made the widget available for other sites, the LSE’s Facebook app is still using the screen-scraping methodology for now.

Comments (0)

By admin, November 20, 2009 5:46 pm

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.

Comments (0)

By admin, November 20, 2009 5:29 pm

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!

Comments (0)

By admin, November 20, 2009 12:36 pm

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!

Comments (0)

By admin, November 20, 2009 12:34 pm

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!