Brainstorm page for the availability interface
- Uwe Reh
- Marie Widigson
- Robert Scheier
What's needed to display proper actions(buttons) and information to an item in a discovery system.
This intended as a unstructured collection of needs, wishes, use cases, etc.
Please add any thoughts. Don't care about duplicates or potential already supported functions.
In the upcoming discussion it's much easier to drop a point than to find a missing one.
| # | Title / Key | Who (optional) | Description | Open questions | Tickets, facts and comments by the investigators | Priority item? | |
|---|---|---|---|---|---|---|---|
| 1 | Individual availability (Availability in different contexts) | Different media types have different types of availability. To respect this, this availability should only published with the context.
| Meeting: R3 | ||||
| 2 | Limitations | The general availability of an item may be limited by some reasons. e.g.
| Uwe: R2 (perhaps solved by displaying notes) | see #10 see #4 | y | ||
| 3 | Pickup Locations | Sometimes items need to be restricted to as subset of all possible pickup Locations. (e.g. only into a reading room or only limit to the the pickup locations of one department/area) see UXPROD-2689 | Uwe: R3, but needs UXPROD-2689 | see #23 | |||
| 4 | Additional information | Uwe Reh | To decide which item to request, a patron might need additional information. (e.g. "First three pages are missing", "Today's newspaper as handout, might be lost.") | Uwe: R3 (Visibility of notes) | see #2 see #10 | ||
| 5 | HRID | Uwe Reh | API should accept UUID and HRID for the requested instances. | Uwe: Chalmers: ? Demian: R2 (VuFind would be less efficient/flexible without this capability) Laura: R2/R3 GBV: R1 | y | ||
| 6 | Direction to other systems - not available | If an item is not available, we want to be able to direct the patron to another request path. E.g., if all the copies of book X are unavailable, provide a button that sends the patron to an ILL system to request a copy from another library. Uwe: Is the redirection to an ILL system a task of the availability interface or a task of the discovery system? | Meeting: R4/R5 | ||||
| 7 | Direction to other systems for requesting | If an item can be used but the patron needs to request it in another system, the discovery layer should be able to support that. E.g., library uses FOLIO to circulate its main collections but AEON to provide access to special collections, the discovery system must know that an item should present the AEON request path and not the FOLIO request path. | Meeting: R4/R5 | ||||
| 8 | Provide a simple way of determining which delivery methods are available for a given item/patron combination | Determining whether an item can be paged, recalled, or put on hold requires (I think) making two API calls (to the request-policy and request-policies endpoints) and filtering the results by item status (e.g., charged or available). It would be great to be able to simplify this on the discovery system side. Uwe:
| Does this overlap with the need to be able to have a list of valid pick up locations (based on patron and item information) when the patron makes a request for the item? | Chalmers: R4 Uwe: R2 GBV: R3 | see: #17 KG: This seems like a patron interface requirement. Uwe: This wish addresses both 'rtac' like 'parton'. Or something in between like a 'PaRtac' In our consortium we are currently working on problems like this. If possible, I'll share a white paper with use cases in the next days. | y | |
| 9 | Estimate delivery | Matt Connolly | If an item can be requested, provide an estimated delivery time (number of days) for that type of request. This might be a simple setting in Circulation, or it could factor in material type, location, existing requests for the item, etc. Uwe: | Uwe: Is Folio itself providing this informations? Phil: could depend on user too. | Uwe: R2/R3 | see: #15 | |
| 10 | Terms of use | Robert Scheier | Terms of use info. from FOLIO Licenses need to be available in Discovery, e.g., concurrent use, ILL, etc. Uwe: see #2 (Limitations) | KG: This functionality is already available - UXPROD-1755 - Getting issue details... STATUS Uwe: If I got it right, the information is available in the UI but not rtac's response see #2 | |||
| 11 | Serial Data Display (Items) | jmulvaney@library.umass.edu | Relevant data from Enumeration, Chronology, and Volume fields should be clearly and uniformly displayed to patrons. Uwe: | Laura: R2 (R3 if this can easily be solved via additional API calls) | KG: Is it preferred that we always returned this information and not have the current conditional logic What gets returned in edge-rtac response? | ||
| 12 | Serial Data Display (Items) | Robert Scheier | Piggybacking on Jack's comment above, volumes should display in sequential order. Right now in FOLIO and VuFind the order is not sequential if you add items out of order. | Laura: R2 (R3 if this can be easily solved via additional API calls) | see #18 KG: MODRTAC-95 BTW - how else should sort RTAC results by? | ||
| 13 | Requests when no items | Offer an alternative solution to request instances that have no items. Uwe: no items? → buy request? Journal with just one holding but no items | Chalmers: R1 | KG: Is this possible by creating a custom link on your OPAC/Discovery service layer? Uwe: Yes a custom Link, might be a workaround for this and a lot of other needs mentioned in this spreadsheet. | |||
| 14 | Allow title level/item level request depending on instance type. | Assuming title level request is default, enable item level request when appropriate, e.g. serials, journals. (For this type of instance only show item level request.) Tod: Here is an example of multiple copies of a monograph: https://catalog.lib.uchicago.edu/vufind/Record/667120 Here is an example of multiple copies of a multi-volume monograph: https://catalog.lib.uchicago.edu/vufind/Record/203893 Tobias Gostomsky : A different Use-Case: We sometimes have media in different branch libraries and no transport between libraries. Customers are not always interested in placing a TLR everywhere, but e.g. only in a specific location. | Chalmers: R2 Laura: R2/R1 | y - especially for folks using TLR | |||
| 15 | :See number of unfilled requests | Marie Widigson kristin.olofsson | The patron should see the number of unfilled title level requests on an instance, before placing the request (not having to be logged in. Based on this information he/she can make the decision if it's worthwile to place a request or not. Uwe: Queue length? Shortest 'Estimate delivery time of all items? | Chalmers: R3 Laura: R3 for title level R1 for item level | see: #9 | y | |
| 15a | See number of already existing holds for checked-out items | If title level request is unset: With this information - in combination with the due date of the checked-out item - the patron can decide, if it is worthwhile to place a hold. | VZG: R2 | ||||
| 16 | Display adjusted item statuses | Several item statuses are very hard to understand for the patron (e.g. "Aged to lost" & "Claimed returned"). The best would be to add a "discovery display name" already in FOLIO where the library could rename statuses for the discovery layer and have these displayed to the patron instead. (See UXPROD-2636). A second best option may be to add a "translation table" for item status ID:s to library specified statuses in the discovery (e.g. "Aged to lost" & "Claimed returned" should be be displayed in the discovery as "Unavailable".) | Marie: This seems to be captured by (OLD ACCOUNT) Erin Nettifee in UIIN-1170 - Getting issue details... STATUS | ||||
| 17 | "Patron aware" information | RTAC should provide information relevant to the specific authenticated patron (if available) in the RTAC response (i.e. is this item loanable, the initial loan period, requestability, lost item charges, and late fine rate). Ability to retrieve preferred pickup location, preferred fulfillment method, delivery addresses, block status when attempting to place a request would also be helpful. Uwe: IMHO RTAC should be agnostic on the patron. Please, "specific authenticated patron" only as option. | patron group vs. individual patron id | GBV R4 | #see #8 UXPROD-2422 | ||
| 18 | Sorting of monographs items | Marie Widigson kristin.olofsson | RTAC should sort the holdings and items for a monograph with equivalent items by a defined logic. For example all holdings for Main library at the top, all available items at the top. This need may be different by different institutions and therefore customizable. (Currently in RTAC API response, our items are sorted in a for us seemingly random order.) | see #12 KG: MODRTAC-95 BTW - how else should sort RTAC results by? | |||
| 19 | Handling of many items |
| RTAC seems to be slow 1,600 items, Colorado Revised Statutes | see: #20
Runs fairly quickly- https://library.villanova.edu/Find/Record/90816 - | |||
| 20 | Performance | General problem? | GBV: 1 ? | see #19 | !! | ||
| Retrieve both holdings and Item information at the same time | Brooks Travis | Some institutions wish to use both holdings and items and this currently requires two calls to RTAC. Perhaps especially relevant for serials information. | Question to all What field(s) that could be used to drive what is returned in RTAC? Material type (item in Germany and FRBR always instance) Uwe: | Chalmers: R3 Laura R3 GBV: R2 | KG: We definitely need to do this and I think it may help with the above request too | y | |
| 21 | Create a fake item record to support electronic resources | Khalilah Gambrell | Discussed in 2/7/2024 meeting | ||||
| 22 | Single request for multiple items | For performance reasons we would be in favour of having a single request/response for multiple items. E.g. all items visible via AJAX. Uwe: Isn't RTAC Batching that what you are looking for? | Björn Muschall Can you provide a example or scenario of the problem that your description would solve? | ||||
| 23 | Remove patron choice of pick-up location and default to effective location's service point. | Kara Hart | Allow institution to remove display of pick-up locations for patron when making a request. For institutions that want the request's pick up location to be the effective location's service point. For institutions that cannot transport materials to other service points for request pickup. (Currently our staff have to change pickup locations of items in FOLIO when patrons choose a different pickup point, before we can process the requests) | Hey Kara Hart
2. Are you really looking for just a list of valid pick up locations for the specific item? There is a Jira for "specify the list of pickup locations for a request" - UXPROD-2689 - Getting issue details... STATUS Uwe: I assume, this is the same need as "Pickup Locations" (above). Before being able to provide a list valid locations in the API, UXPROD-2689 has to be solved first. BTW. | Uwe: R3 (as part of #3 'pickup locations') | see #3 | |
| 23 | Allow for a request to be processed as a recall even if a hold is also allowed | (OLD ACCOUNT) Erin Nettifee | Currently, if a request is associated with a policy that allows for a hold and a recall, the request will always be placed as a hold. This is undesirable if institutions want recalls to occur if the item is out on loan, because recalls trigger notices and due date changes while holds do not. Most institutions with this configuration find that the high majority of requests are ones where recalls are appropriate, but there are still use cases for holds (e.g., if staff are placing them for processing needs but don't need to require the patron to bring it back early.) | Sorry for asking, but is this a demand for the (discovery) APIs or rather one for the librarian's UX view on FOLIO? |
one possible context of my 1st. point
simplification sounds nice but we should not overlap the APIs for items and for patrons. RTAC should provide 'Limitations', 'Pickup Locations' ans 'Additional information' for patron groups (roles) and PATRON should provide the role of the particular patron. (see "Patron aware" information)