UXPROD-1835 Reading Room Feature DRAFT vs UXPROD-4070 Reading Room Access OPEN - Library of Congress priority (Charlotte)
Requirements the Swedish National Library (Andreas Mace)
Current Library Workarounds
Closing
Any actions or follow through?
Notes
Time
Topic
Notes
TK
...
2:20
Housekeeping
Next week's session is on Australian Libraries
No news on ongoing projects
03:12
Agenda
Lynne requested a meeting on Reading Rooms functionality in FOLIO. We are generally interested in what functionality is planned, and if anything coming can be used without barcodes.
4:29
Presentation from Charlotte
(See Slide Deck above)
The feature that covers the functionality we're discussing today is UXPROD-1835. This feature is still in draft. It has gathered some discussion since 2019 and includes several workflow outlines. National Library of Sweden's workflows seem to represent what is needed broadly. There's significant common ground.
Just to avoid confusion: there is also a "Reading Room Access" ticket (UXPROD-4070) that covers different functionality for the Library of Congress–not what we're discussing today.
10:14
Overview of functionality (Andreas Mace)
National Library of Sweden is not currently on FOLIO–they have been looking into FOLIO for some time, but have not yet decided/implemented. NLS is currently on Aleph, and contributed significantly to the development of reading room functionality in Aleph.
We look at a flowchart representing the NLS's workflows:
View file
name
Reading room NLS flowchart.pdf
height
150
Blue represents activities in the OPAC, green represents the local system, and white represents a human process. Yellow is staff/FOLIO interactions.
Andreas outlines the process at NLS step by step (13:42)
We note that reading room loans constitute the majority of loans for NLS–this is the bulk of their circulation.
NLS had explored using actual loans instead of tagging to manage the cycle of active reading room loans, but that is significantly more difficult and involves manipulating the request queue.
(16:47) David asks how/why this process is different from the item status "awaiting pickup." It's different because NLS needs to keep the item charged to the patron while tracking whether the item is actually with the patron (in active use) or if it's charged to the patron while on the hold shelf (not in active use).
21:13
Questions from NLS
How do you prevent mistakes in stacks retrieval?
What should the tags be?
Can you limit what service points you can check out certain material types from?
Reporting needs–what do we want to keep for these operations?
What views/displays are needed? i.e. User Loans, current reading room loans, etc.
22:51
Interlibrary Loan Analogues
While the University of Chicago has special collections, the closest analogue is "in house use" or "building use only" interlibrary loan. This is similar to the situation at Cornell.
David suggests a new request type: a reading room request type. There would also need to be reading room request statuses.
Generally, the request would follow the diagram above: when the item is returned by a patron, the request would stay live until explicitly made complete, such that multiple loans for the same patron could be completed on the same request. It may actually be easier to extend requests than to automate the workarounds as described in the diagram.
(29:30) Thomas thinks maybe this could be done with current request types and an additional flag ("persistent"). Further discussion would be needed to determine which approach would be cleaner.
Should the feature be renamed?
32:16
Terminology Check
What is the difference between "in-library use" and "reading room loan"?
Some libraries (Cornell) have a connotation of rare or an increased level of control over reading room items. In-library use items stay within the building and are generally charged out. Rare items are often limited to one room, and in some cases are checked in/out, sometimes not.
It really depends on the library. In general, the process is similar.
Tom asks if folks hold IDs. Cornell does. Others do not, or only in some circumstances.
Charlotte asks if this might be covered by the LOC IDs. Chicago wouldn't be able to implement the LOC's process because each of their IDs is TWENTY DOLLARS OH MY GOSH.
42:22
Too Many Steps!
Andreas notes that this process is often manual at many libraries. What is needed is a scan-in functionality–there are too many manual steps.
Anders notes that this process happens over and over during the day. It is a lot of transactions. Borrowers must also always show a borrower card.
David thinks that extending requests functionality would save a lot of steps.
44:38
Stanford's Method
Darsi says that at Stanford the user places the request, an available notice goes out to the user. When the book arrives, they do not check the items out in order to keep the item on hold. When the request is finished (when the user is done with it) they cancel the request in order to send it back.
Some ILSs have a sort of special check out that handles reading room loans, sometimes tied to a service point.
David thinks that this would fit into the new request type scheme outlined above. This raises the statistics question, of how this should be counted. Tom thinks that special collections at Cornell tracks how many hours an item has been used.
47:20
Limit Service Points
Is it possible to limit which service points you can check items out from? Not currently in FOLIO, but the ability to limit requests to certain service points is coming soon. This will have similar effects in practice.
Loan service point limits would be useful for Reserve items as well.
51:32
Next Steps?
We think that this conversation properly belongs to Resource Access. Would this be a good candidate for the breakout sessions?
Stephanie says that the more worked out the feature is, the better chance there is of it being picked up. However, Vega has a lot of work ahead of them.
54:35
No Pop Ups!!!
Andreas notes that we do NOT want pop-ups. Those would need to be a configurable setting or handled differently in order to support libraries with a large volume of "persistent" requests.