Gary Brewerton

Gary Brewerton

This user hasn't shared any profile information

Posts by Gary Brewerton

A kick in the teeth

Just heard that one of our existing LORLS users is stepping up to the challenge of developing their own reading list system. This is great news and as they have secured JISC funding it should mean in time that there is another open source solution out there. The project even has a snazzy screencast available.

Unfortunately the screencast does somewhat dis (“their implementations suck”, “it has a badly designed data schema”, “user interface a bit of a nightmare”, etc.) our past efforts which is a bit of a kick in the teeth.

Ho-hum!

Second meeting with Talis

When I met with Mark and Ian from Talis back in January they’d suggested hosting a follow-up meeting later in the year. So yesterday when I went to visit them I was expecting it to be somewhat of a “blast from the past” what with me being an ex Talis customer. But everything was different: new offices, lots of new staff and lots of new ideas.

Ian played host and introduced me to Chris, a lead developer for Talis Aspire who went on to give me a demonstration of the system which I must admit is very impressive. I wasn’t able to reciprocate with an online demo of LORLS as we haven’t yet knocked any holes in our institutional firewall to allow external access to our development server. However, I was able to show Chris and Ian some screenshots.

One thing I noted at our first meeting was the similarities between our two systems. This became even more evident after I showed Chris a simplified E-R model of our data design as he went on the say that apart from the entities relating to access control it was basically the same as theirs. Hopefully this means that “great minds think alike” and we’re both on the right track.

After the meeting I met up briefly with Richard Wallis (one of the few faces I recognise from the old days) who went on to explain about his Juice Project. This is in effect a piece of middleware that can sit between your website and various external resources. The benefit being that instead of everyone writing their own method to access the resource you can instead use someone else’s code that already does it. This sounds like a great idea and one I think we should consider using for LORLS.

Meeting with Talis

Had a really interesting meeting this afternoon with a couple of folk from Talis. Mark Bush, who is new to the company, contacted me a few weeks ago to arrange it. The purpose of the meeting was to gain greater understanding of different approaches to reading list management. Mark was accompanied by Ian Corns who despite his job title of “User Experience Champion” didn’t arrive wearing a cape or with his underpants over his clothes.

The first part of the meeting turned into a show and tell: with me detailing the birth of LORLS and our ongoing project to redevelop the system, and Mark showing me a little of Aspire, Talis’ replacement for their existing Talis List product. The thing that struck me was how similar in concept their new solution is to what we’re doing with LORLS.

The second half of the meeting was given over to discussing the various possible strategies to use when implementing a reading list solution. Obviously selecting an appropriate system is important. However many of the key issues that will determine whether it is success are not necessarily system dependant.

For a listing of some of these key issues send £12.99 and a stamped self-addressed envelope to Ga… OK OK I’ll tell, please just stop hitting me Jon 🙂

  1. Involve all stakeholder as soon as possible in the implementation process – pretty obvious I know but still important to remember
  2. From a Library perspective it’s much easier to work with academics if you’re not seen as the ones forcing the system upon them
  3. Pump priming the system with academics’ existing (often Word based) reading lists can be a real winner – once a list is on the system is much easier to get academics to update it or at least be aware if they haven’t so you can then nag them about it!
  4. Training, training, training
  5. Local champions can often do more for the success of a project than official promotions – identify your champions and support them
  6. It’s important to know the lie of the land – what may work with one department won’t necessary work with another. For example Engineers have a very different approach to reading lists than Social Scientists.
  7. Competition between academic departments or faculties can be a useful means of encouraging adoption of the system but needs to be done with care
  8. Use every opportunity to stress the importance of reading lists to academic departments, for example: bad module feedback, that’s because of your lack of reading lists on the system; external review approaching, why not invest some time in updating your reading lists to demonstrate clear communication between academics, librarians and students.

New Blood

Introducing the latest member of our development team: Jason Cooper!

Jason  has been around for a while and is a survivor of our data design wars (it’s all just structural units! why do we need data type groups?). We’ve given him the task of developing a new wizzy interface which will communicate with Jon’s APIs.

Like Jon, Jason is a PhD which means I’m now in the middle of a doctor-doctor joke.

Going nowhere fast

We’ve been working on designing a new and improved database structure  for LORLS which allows for greater flexibility. Unfortunately work on this hasn’t really progressed due to the implementation of RFID-based self-service here which is occupying all our time at the moment.

But on the plus side we have come up with a name for the backend (DB+APIs):

<Drum roll>

LUMP

What! (we hear you shout)

Yes LUMP it stands for Loughborough Universal Metadata Platform which we realise may sound a little pretentious but how can you not like an acronym like LUMP!

Version 6: A new LORLS

Jon and I have begun to think about the future of LORLS. At the moment we seem to keep coming up against issues with the data design whenever we try to implement a new feature. So we’re thinking it might be time to (warning scary thought coming) throw anyway what we’ve got and start again from stratch.

Having spent a couple of late Monday evenings discussing this we’ve come up with a new data model. This is still very much at the play stage – so things are likely to change.

One thing we’d be keen to do this time round is to seperate the backend that provides access to the databse from the frontend, or rather frontends –  assuming that with a XML+HTTP based API at the backend there could be multiple frontends for different tasks, institutions, mash ups, etc.

Of course a well defined XML+HTTP API could even mean that there could be multiple backends.  For example traditional Perl based CGI scripts for use with Apache for those of us with a modicum of common sense, or Java+Tomcat for people who like smacking their foreheads against walls (you can tell we might have a small bias, can’t you? 🙂 ).

Interestingly we’ve just had an email from one of the other LORLS sites asked about forking the existing code. So maybe this is an opporuntity for some cross institutional development of LORLS.

Gary Brewerton's RSS Feed
Go to Top