Stack Request Delivery Slots

One of the things I've learned about the Cambridge University Library is that you're not necessarily allowed to fetch a book from all the shelves yourself (mainly as a result of the logistics of managing a large collection that arises as a result of being a legal deposit library). Instead, you have to put in a stack request via the online Library catalogue or a paper slip:

Book Fetching
Items will be fetched as quickly as possible, but delays are inevitable at certain times of day (especially 12:30–14:15 and 17:15–18:20) and during busy periods. Generally fetching times fluctuate between 30 and 120 minutes, depending on demand. The current estimated fetching time is always displayed both in the room and whilst placing an online Stack Request. Orders submitted after 18:20 (16:00 on Saturdays) will be fetched on the next working day.

Once fetched, books are placed on a stand behind the staff desk area. Books are held for the remainder of the day they are fetched and one full working day thereafter before being returned to the shelves. On the second day books are placed on a shelf along the back of the staff desk area.

If you wish to order more than ten books at one time, please consult staff before placing your order.

(Hmmm - the above guidance is from the Reading Room. Stack Request guidance for the West Room uses completely different text... But presumably the mechanics of making the request are similar, at least as far as the patron is concerned?)

When you make an online request, a request appears on a Voyager Call Slip screen and prints out a request slip, the Call Slip screen shows all currently pending requests and the user is given an estimate of the time to delivery.

A fetcher collects any currently outstanding slips and goes into the stacks to collect the required book(s). A tear-off is placed on the appropriate shelf where each book is taken from (some are borrowable, many aren't, and must remain in the Library confines), returns to the desk and scans the request slip. This completes the transaction, clears it from the screen, and sends an email to the patron letting them know the book is ready for collection. It's then placed on the public recent deliveries shelf for collection, and will remain there for a day if uncollected. Books that are not borrowable may be reserved inside the library for up to three days by leaving them on a desk with a reserve slip in them.

The collection takes anything from 15 mins to a couple of hours on a busy day (I think) with expected turnaround time of 45 minutes.

A paper based reservation system is also available.

So what if I'm doing some desk research and want to request several books to browse through in a single visit, or over a couple of days?

Or what if I'm at my desk in one of the departments on the other side of Cambridge, but fancy a walk over to the main library building for an afternoon of scholarly activity? Wouldn't it be convenient if I could book a delivery slot for the books I want to put a stack request in for?

On a quiet day, fulfilling requests in a timely way doesn't seem to be an issue, but at busy periods, it may be that a bit of scheduling might help?



This could also help the fetchers schedule what books to collect when. They don't necessarily have to go and fetch a book slotted for this afternoon just yet; instead, they can maybe pick it up in an opportunistic way when servicing another requirement later in the day, or dlay fulfilling a particular request if a rush is on (or if several requests need fulfilling from far flung stacks). Indeed, the ability to request a delivery slot opens up the possibility for all sorts of complicated collection scheduling algorithms - a bit of a knapsack problem with a twist of timetabling and a dose of the traveling salesman, perhaps?!;-)

So what sort of hackery might be fun to try around this process?:-)

As far as scheduling goes, it might convenient to allow a patron to specify the soonest they want the book(s) to be available, with as soon as possible set to be the default. Specifying a later delivery slot would place the request in a queue that would hold the request until a quiet period, or release it when a more timely request for a similarly located item was made (if a fetcher is going to floor N, stack M, where a queued requested item is also located, they might as well get both at the same time).

Of course, the system appears to be working pretty well at the moment, but I couldn't help but notice that the library is building another extension, and is continually in receipt of new books, so I'm guessing the travel time spent collecting new books is only likely to increase (I don't think there's an option to locate books closer to the reading rooms depending on how often a book is requested, so presumably newer books are located further away as the library grows out?)

With interest in building library relevant mobile applications, too, it makes sense to start thinking about time and location features as part of the mobile UI, as well as looking elsewhere for inspiration.

So for example, home shopping apps like the Ocado iphone app [screenshots/walkthough], also seen here:



So that's the first possibility - accommodating a delivery slot request, and then potentially building some intelligence into the scheduling of those requests.

The second possibility, and the first thing that came to mind when I saw the collection completion step that fired a 'your item is ready for collection' email to the requester, was a hook to fire off an SMS text message, IM message or tweet instead (or as well). Yes, users can receive email on their phones, but how many have their phone set up to receive mail from their @cam.ac.uk account? How much more convenient would it be to be able to receive a delivery notification via a mobile or always on/alerting messaging client you do use? I'm not sure if the Voyager Call Slip system can be used to raise events that your own code can respond to (all the Voyager documentation I've almost found appears to be locked down in password demanding websites, which isn't very friendly and puts me off old school commercial OPAC vendors even more;-), but if so, this would be quite a nice hack to try out, although it does require additional user information, such as mobile phone number, IM or Twitter ID, etc.

Th third thing that comes to mind may only be an issue because I put a paper slip stack request for a particular book in, rather than an electronic request, and potentially also because the book I requested was borrowable, but I haven't loaned it out - the Library catalogue thinks the book I requested, and that is currently reserved on a table, is available:



That is, the Library catalogue (in this case at least) does not reflect the state of the book - off shelf, somewhere in the Library... Maybe if I'd booked the book out electronically, it would have had its state changed when the slip was scanned to complete the request? Or maybe amidst my question asking, a step was missed out? But whatever the case, there appear to be several opportunities for a book to appear as if it were available as far as the catalogue is concerned, yet for it not to be available in practical terms. (If a stack request can't be fulfilled because a book is off-shelf, or for another reason, that information is sent back to the patron in the request completion email. But the fetcher has potentially had a wasted trip.)

So the third thing I was left wondering, and something that I woke up puzzling about this morning, was how each book's status was represented in state machine terms? And what demands on the data model/required state information might be affected if RFID tags start to come in and make the Library self-aware with respect to where the books are in it?

Thanks to Lucas in the Reading Room for walking me through the stack request process.

---

Comments from @ostephens:

--
The LMS documentation issue is a frustration for me as well - I just cannot understand what the suppliers think they are really protecting here. Although obviously I can see that there is the potential of others copying their solutions to problems, I'm not sure the problems are really so difficult you are protecting any really valuable IP here :(
ModerateFlag Like Reply

--
Answering the question about whether a book is on the shelf is often not as easy as you'd hope. Library systems generally track a few statuses of a book:

On loan
On a 'holds' shelf (i.e. being held by the library for a specific user)
In transit (i.e. being moved from one library site to another)
On shelf
Missing/Lost

and that is basically it. Some systems have other types of functionality to handle some slightly different scenarios but generally these 5 are the basics I think.

Two other statuses that exist but systems aren't able to record are 'being used in the library', and 'being reshelved' (and this can be either after return from a loan, or after in library use)

I have worked with a system that implements a time delay between return of an item and it appearing as 'on shelf' in the system (don't know how many systems support this, but it makes some sense to the alternative of scanning it when you actually place it back on the shelf). However, this doesn't tackle the 'in library use' or subsequent reshelving time (which could be a day or more, as books left on desks may not be cleared immediately, especially if there is some type of 'note' system to reserve items on a desk)