LORLS

Meeting the Reading List Challenge workshop

On July 14th 2011 a workshop was held at Loughborough University entitled “Meeting The Reading List Challenge”.  42 people attended and, after a couple of presentations on reading lists in the morning, the afternoon was spent in group discussions looking at various aspects of reading list design and implementation.

The groups were each asked two questions, and each question was asked of two groups.  The questions were:

  1. What makes a perfect read list? And how can an academic keep it relevant?
  2. Who should be involved in the development of a reading list and what are their roles?
  3. Who do you want to view a reading list and who don’t you want to see it?
  4. How do you get your whole institution engaged with reading lists?
  5. Is there a formula that describes the relationship between reading list content and library stock?
  6. What other systems does a resource/reading list management system need interact with and why?

You can see the posters made from the results of the discussion online.

After the workshop, Gary, Jason and myself sat down and had a think about how some of the things that had come out of the discussions could be implemented in LORLS, and if they were things that we might find useful at Loughborough.  As a result we’ve got a list of some new things to investigate and potentially implement:

  1. Produce a report that is emailed to library staff and/or academics that flags when a new edition of an existing work is available.
  2. Report back to academics on the usage that their reading list is getting.  As we don’t ask the students to log into our LORLS installation, this will have to be anonymous usage information, either from the webserver or from data recorded by the API.
  3. Look at options for purchasing formulae to assist library staff in placing orders for works.  These formulae would be based on various facets such as the number of reading lists a work is on, how many students are on the corresponding modules, the importance attached to the work by the academic(s), the cost of the work, etc.  We might even factor in some simple machine learning so that past purchasing decisions can help inform the system about the likely outcome of future ones.
  4. Importing works from existing bibliographic management tools, especially from RIS/Refworks format.
  5. Provide the students with an ability to rate items and/or lists.  This would provide academics with feedback on how useful the students found the works on the reading lists and might also help the purchasing decisions.
  6. Do some work on the back end to get cookies, Shibboleth SSO and JSON(P) supported to provide a more integrated system.
  7. Sending suggestion emails to academics when new works are added to library stock that cover similar topics as ones already on their reading lists.
  8. Do some W3C accessibility and mobile web support testing.
  9. Introduce a ‘tickstamp’ data type that is set with the current date/time when someone ticks a check box.  This could then help support workflow for the librarians (ie a list of check boxes that have to be ticked off for each list and/or item).

We’re not at the stage of attaching time scales to the development of any of these, and indeed we might find that we don’t actually implement all of them.  However this list does give an idea of where we’re looking to take LORLS now that we have v6 out in production use at Loughborough.

LORLS v6 unleashed

In the early hours of yesterday morning LORLS v6 slipped its keepers (Jon and Jason) and escaped into the wild. LORLS v6 is described as flexible open source resource/reading list management system. Alongside LORLS v6 its three children (LUMP, CLUMP and BibGrab) also successfully made their breaks for freedom.

Members of the public are advised to check the following safety guidelines before approaching the beast.

Momentous events

Well, OK maybe they’re not that momentous but…

A couple of months ago we (Jason and I) met up with Ian Corns of Talis Aspire fame and had a bit of a catch-up session. Much has changed at Talis: their Library Management System division has been sold off, what was Talis Aspire is now called Talis Aspire Campus Edition, they are launching talisaspire.com and Ian has a new job title (which is no laughing matter :-)).

We also bemoaned the lack of any reading list events happening this Summer. So in light of that we were particularly pleased when the Department of Information Science at Loughborough University (i.e. them upstairs) decided to host a workshop on “Meeting the reading list challenge” especially as Ian and myself will be giving a presentation on reading list systems at the event.

As we’re now involved in helping to organise the event I thought advertising it here might be a good idea!

Meeting the reading list challenge: A workshop
Department of Information Science, Loughborough University
Thursday 14th July 2011, 10:30am – 3:00pm

Do you know what resources your academics are recommending to students? How easy do your students find it to locate these key resources?

These issues (and many others) will be discussed at this forthcoming workshop.

Your host for the day will be Dr Ann O’Brien from the Department of Information Science, Loughborough University. The morning session will consist of presentations on “What is a reading list?” and “A magical mystery tour of resource/reading list management systems” given by Gary Brewerton, Project Manager for LORLS (Loughborough online reading list system) and Ian Corns,Customer Liaison Manager for Talis Aspire.

A free buffet lunch will be provided after which there will be wide ranging discussions on topics such as: what makes a good list? How do you engage with academic staff? And, what roles does the library actually have with regard to reading lists? There will also be opportunities for you to ask questions of those present.

This is a free event. If you would like to attend please email Sue Manuel (s.manuel@lboro.ac.uk) to reserve a place stating your name, institution and any specific dietary requirements.

We look forward to hearing what others have to say about reading lists and associated systems on the day.

Twitter hash tag for event: #mtrlc

Finding things that aren’t there

Jason noticed a bug in LUMP last week (just one I hear you cry? 🙂 ).  When non-admin/non-library staff created a structural unit for something like a book, there wouldn’t be any “Held by Library” flag data elements created, as these have a data type that lives in a data type group that the academics don’t have edit rights to.  This means that some of the backend scripts that were looking for works with this flag set to “N” were missing some records that don’t have the flag at all.

The long term fix for this was relatively easy – I just got EditStructuralUnit to create data elements filled in with the default value if such a thing exists in the data type table for any data type groups associated with the structural unit type of the structural unit being created (and breathe… honestly it makes more sense than it sounds like it does!).  It does this even if the user creating the structural unit doesn’t normally have edit rights to data types in some data type groups.  This should be quite safe to do as we’re creating a new structural unit so having defaulted data elements where possible should make library staffs’ lives easier.

However there was still a gotcha – we needed to go and find all the structural units that were missing their “Held by Library” data elements and create a suitable data element filled in with the default (in our case “N” as we assume we don’t hold works until proven otherwise).  Now I could have knocked out a Perl script with several selects and subqueries in it, but I decided to exercise the old SQL muscle and see if I could do it straight into the database, preferably in a single SQL statement.  So after some cogitating, here’s is the resulting SQL:

insert into data_element (structural_unit_id, data_type_id, value)
select su.id, dt.id, dt.default_value
from structural_unit as su
inner join data_type_group as dtg
on su.structural_unit_type_id = dtg.structural_unit_type_id
inner join data_type as dt
on dt.data_type_group_id = dtg.id
and dt.name = "Held by Library"
left outer join data_element as de
on de.data_type_id = dt.id
and de.structural_unit_id = su.id
where su.structural_unit_type_id in (1)
and de.id is null;

Hmm, that’s some serious joining going on there!  The basic idea is that we’re doing normal inner joins to link structural units, data type groups and data types together, and then a left outer join to spot data_elements.  As the left outer join has the data element columns set to NULL where the data element doesn’t match in a row, we use that in the where clause to limit the output to just the missing structural unit and data type information (plus a limitation on the types of structural unit we’re interested in – in this case just books).  This is then used directly in an insert.

Phew!  Seems to work though – we found 434 books on the live system that this corrects.  Relatively quick as well – less than 20 seconds on our production database. If anyone can see any better way to do this (or issues with this one!) please leave a comment.

Still, similar SQL can now be used on other structural unit types and other data types as well.  But I think I need a walk round the library first… 😉

Improving usability via popups

An area of CLUMP that we felt needed some work on was the length of time it could take for a list to reload after a user had gone into an item. Having discussed it for a while we decided to try using a popup for leaf nodes rather than actually moving into them.

Identifying if something is a leaf node or not is quite easy, we just need to see if its structural unit type can have any children. If it can then it isn’t a leaf node and we treat it as normal. If it can’t have any children then it is a leaf node and rather than putting in a link to move into the item we put in a link that displays it in a popup box.

The popup boxes have made a great improvement to the usability of CLUMP for both students and staff. When viewing large lists there is no longer any need for users to wait for a reading list to reload just because they decided to look at an item’s details.

Speeding up liststats

The LibrarianCentre contains a script called liststats that trawls back though editing events in the LUMP database and tries to determine how many lists in each department have been edited by which types of user.  Our library staff use the resulting statistics for a variety of tasks, such as distributing workload amongst teams and planning future loads.

The trouble is that liststats can be a bit slow, especially on a busy production database.  Today I’ve been doing some tweaking to speed it up, and got some pretty good results (mostly by creating some new methods to find the maximum priority a user has, either associated with a particular SU ID or in general).

All well and good, but it still takes some time to run so I decided to be flash and put a progress bar on the page whilst the script is running.  Hmmm… but the liststats script is just a plain old bog standard CGI script written in Perl, rather than one of Jason’s whizzy AJAX Javascript jobs.  A bit of hacking reveals that you can run Javascript whilst a page is loading though… so you can do a bit of sneaky Javascript and CSS to give us a nice graphical progress bar (with a textual incrementing percentage completed for the folk with no images/CSS/screen readers).  Cool – worked fine on our test server.

Then I moved it to our live server and all my progress bar loveliness disappeared.  What?!  Turns out that whilst Apache 2.x does unbuffered output by default (unlike some of the older Apache 1.x web servers of yesteryear that needed nph- scripts to do it), if you’ve got on the fly compression turned on the buffering is turned back on.  Rats.  Luckily there’s a handy way of turning it back off for particular scripts (so I don’t cock up Jason’s AJAX calls that benefit from compression, espeically on IE with its limited connection limit):

SetEnvIfNoCase Request_URI liststats.test no-gzip dont-vary

This just needs to sit somewhere appropriate in the HTTPd config files – on our CentOS box its in the included ssl.conf config file fragment.  Everything works again – hoorah!

Integration with the campus bookshop

A recent addition to CLUMP on our live system is the inclusion of a message informing users how many copies of a book are available in the campus bookshop. If there aren’t any copies in the campus bookshop then the message isn’t displayed.

 

New bulk functions and flags

Having gone live over a month ago there has been quite a few new features added and old features tweaked. The two biggest new features are bulk functions and flags.

Bulk Functions

Bulk functions help editors of large lists who want to move/reorder/copy/delete multiple items.

To select items the user simply clicks on the items rank number which is then highlighted to show which items are selected. When any items are selected the bulk functions menu appears at the top left. There are currently three bulk functions

Move
Moves the selected items to a point specified in the list. The items being moved can also be sorted at the same time.
Copy
Copies the selected items to the end of the specified reading lists.
Delete
Deletes the selected items.

Flags

Another new feature is the inclusion of flags for certain situations.

Private Note
If an item has one or more private notes attached to it and the user has permissions to access them, then this flag is shown. If the user hovers the cursor over the flag then they get to see the private notes without having to edit the item.

Librarian Note
If an item has one or more librarian notes attached to it and the user has permissions to access them, then this flag is shown. If the user hovers the cursor over the flag then they get to see the librarian notes without having to edit the item.

Not Held
This flag is a little more complicated than the previous ones. If the user is able to see the library only data for the item and and item is a book or journal and it’s marked as not being held by the library and it doesn’t have a URL data element and is not marked as “Will not purchase” then this flag is shown.

Or to put it another way it highlights to librarians the items on a list that they may want to investigate buying.

And we have a launch!

At approximately 11:40 this morning we launched LORLS v6 to students and academics at Loughborough. This was done using our standard importer which extracted data from our previous LORLS 5 installation. We then ran a number of local modification scripts (e.g. to remove years and alter the metadata layout).

This seems like an opportune moment to say a few thank yous to those who contributed to the development and implementation of this new version:

  • Jon and Jason, who in the best traditions of a pantomime horse developed the back and front ends
  • Ginny and Jenny, for producing promotional and training material
  • Theresa, Vicky, Karen, Lynne and Sue, for testing and critiquing the new system
  • Sue 2.0, for putting up with us during the database design war process
  • And to all the other library staff, academics and students who provided invaluable input and support for this new version.

And finally as it is Valentine’s Day a little (and I do mean little) poetry:

Roses are red, violets are blue,
LORLS 6 is here, just for you!

T minus 7 days (and counting…)

We are now just one week away from the new version of our reading lists system going into production use here at Loughborough. As part of the build up to this library staff have been engaged in various promotional activities such as: liaising with key staff in departments, distributing flyers to academics, attending departmental meeting and placing announcements on relevant noticeboards.

In addition to these activities, Ginny (Academic Librarian) and Jenny (e-Learning Officer) have produced an excellent four minute video demonstrating some the features of the new version.

Go to Top