Page Comparison

Date

08 Jul 2021

...

Meeting Notes

FOLIO RA SIG MEETING NOTES 2021-07-08

Steph Buck – Title Level Requests

TOPIC - Request mockup screen.

Changes to the accordions – possibly renaming column order and adding some kind of indicator in the type column in the first accordion to indicate whether it was initiated as a title level hold or an item level hold  -- but may make screen too cluttered.

Because that information is available in the request detail, it seems it adds a layer of information that we already have access to. We want this to be a great overview, but we don't want to put so much in it that it becomes overwhelming to look at.

TOPIC - Request details screen

Comments on “8 of 3 items”? Is this understand that this is a position and the title level queue, and it is position eight of three items? What are we trying to say here? Patron is in position number eight, for the title level and there are a total of three items that could fulfill the request -- position eight parenthesis three items would make more sense

So position eight, a parenthesis, three items. – 8 (3 items)

8 with 3 items?

Just an indicator of how many items exist that could fill this request.

if it were an item level request, it would just say, position eight one item – 8 (1 item)?

Suggestion is to change the bold text to position in queue. And then the text underneath that would be position, eight parentheses, three closed parentheses items. – 8 (3 items)

TOPIC - View Request? or View Requests?

View request queue?

View reorder queue?

Change View requests in queue? No seems fine as is

TOPIC - Original (or initial) request type info?

Discussion about this and homework assignment: If we were add some field or an indicator to describe what state the request originated in (item level or title level), where would that go? How would it be displayed, And what would it be called?

TOPIC - How to work with reserving monographs versus multivolume titles.

For example, DVDs where you have multiple copies of a DVD. How does how does that work?

DVDs of TV series and multiple copies of the single volume. So the patron wants a specific volume, but they don't necessarily care which copy. So they could be on the same instance.

Would something like volume-level holds work, or is there a way that we are thinking about working with multivolume titles and multiple copies of specific volume with requests that would work as the same solution? Thinking was that we were considering holdings-level requests out of scope for this piece.

Whole thinking was to push that off on to the discovery interface to decide how to present that, and when to present it. Treating it as an item-level request. Then if you need to move things between items, you could manually rebalance

Uncertain where we landed on how to manage reserving monographs versus multivolume titles, particularly when there are multiple copies of the volume. But if that is pushed to the discovery interface and then manually rebalanced by moving things around in the queue, just want to make sure I'm understanding that that's what's decided.

We were talking about this before in the smaller subgroup, and one of the issues that we were worried about is because volumes and issues vary so differently even within a within a standard institution. Like for instance Cornell might have a B before their numbers are some of them might not, that this will be extremely difficult to do on the folio side of things and that it would be a discovery layer issue.

TOPIC - How many title-level requests and item-level request should be allowed to be made by one patron? Could it be configurable as a patron block? If we have to hard code that it should be a high number. We’ve already got a few:

• whether or not to turn on title level requests
• whether or not you want the title level request box checked automatically for requests being placed.

It will vary from institution to institution. What does the group think? Is the question how many title-level requests and item level requests a patron should be allowed to make on one instance, or all together? Both. The original issue was on one instance, not a complete or total -- can they place 12 title requests on the same title, or should it just be limited to one? Is there already a request count automated patron block? No, not for number of requests. There is one for number of checkouts.

Why would a patron place multiple title level requests on the same instance? To game the system, and sometimes it is a mistake; they forget they did it and they do it again. In the same way that if you have an item level request and you have already placed a request on that item, it should just stop you from doing that.

It gets complicated when you get into the multivolume titles where it really has to be an item. How do you do that, like, I need volume 10 and there are three volume 10s? And I also need volume 11 and there are three volume 11s.

The override function there is important for staff to manually override that.

So, what I'm hearing is that, eventually, we want an automatic patrons block to limit the number of requests per patron. But for the time being we want to make sure that patrons are only able to place one request on one instance, and that library staff need the ability to override multiples if they occur.

Back to the multivolume titles, for example volume 10 but there are three copies. Is that just placed as an item request? As a series of items item requests? So if somebody wanted multiple, volumes, they would have to put in multiple requests? What if they were just requesting from among three copies of the same volume, then they would just place and item request a one of the volumes? Correct. But if they needed volumes, 8, 9 and 10, they would have to do three separate item requests if there were multiple copies of volumes 8, 9 and 10.

Wrapup

Maybe on Monday we can try to tackle how we handle recalls and some of the questions that have come up in the Title Level Request channel.

Chalmers raised the concept of renewals and requests -- if there is one request for one instance, no other items that should be possible to renew, so their request is prioritized.

Cornell – Andy Horbal -- mentioned that their implementation is going better than they could have hoped for. They’ve had lots of issues, but so far they’ve been able to resolve most of them in a pretty timely manner.

Missouri State – Brooks --So far things to be seem to be going okay with their Iris upgrade but he doesn't think they’ve applied hot fix 2 completely at their environment so haven't had some of the fun that Cornell's been having with that

Meeting Outcomes