2019-8-1 Resource Access Meeting Notes

Date

01 Aug 2019

Attendees

Discussion Items

Time	Item	Who	Description	Goals
5 min	Housekeeping	Andrea Loigman		Notetaker - Andy Horbal
5min	Check-in	Emma Boettcher	Check-in volume	How many items are likely to be checked in during a given session?
45min	Requests	Cate Boerema (Deactivated)	Delivery requests	At the requests re-ranking meeting, we discussed possibly coming up with a very simple delivery request design that could meet go-live requirements for institutions that need it. In particular, we discussed: - A "for delivery" flag that would alert the circ staff upon check in that the item needed to go for delivery. They would then need to look up the address themselves or something... - Would still need to have a special notice for the patron letting them know the item will be delivered Goal: To design a simple delivery request solution. Original delivery UXPROD for reference: https://issues.folio.org/browse/UXPROD-113 Some notes to get the discussion started: https://docs.google.com/document/d/1jPhVAOVuhsCcYKaLh0uqpciNw9_qAWD6NSsO5a60eMA/edit Also related, let's review mockups for request preferences on the user record: https://drive.google.com/drive/folders/1NYzSOG_wMPyT9p0CgnjLo1wWiisIm7Fi
10min	Inventory	Cate Boerema (Deactivated)	RA needs for Inventory	Met with Charlotte and select MM SMEs to discuss criteria for deciding which additional data elements and search features are must-have for MVP - Decision criteria: data elements and search criteria are needed if required by non-catalogers (e.g. RA and RM folks) to do their day-to-day jobs. MM SIG did a "gaps analysis" for inventory a year ago when they identified data elements that needed to be added to inventory. Institutions were supposed to consult with their RA and RM SMEs to determine which elements to add - But given where we are and how little time we have left, it is probably worth refreshing our take on whether elements and features are needed for MVP by RA and RM folks - Thoughts on how best to do this? If the UXPROD features are broken down enough, the institution ranking is an obvious place to capture importance, but there is only one ranking per institution. It would be kind of nice to track which items are needed just for RA (and possibly RM). This would also help with the definition of the RA-view of inventory (UXPROD-1877) Thoughts on how best to capture RA input on Inventory features?

Meeting Outcomes

Functional Area	Product Owner	Planned Release (if known)	Decision Reached	Comments

Notes

Emma Boettcher - Check-in volume:

Quick question about anonymizing loans: for a user (read: staff member) checking in items at a service point, what would be the upper limit of the number of items they’d be checking in during a session? Cheryl Malmborg: at UChicago, potentially hundreds. Andrea: at Duke at the end of a term, several hundred. Emma asks if a 1,000 would be a reasonable number to use to define the upper limit (not for official purposes, but just to get an idea of the scale). Consensus = yes.

Cate Boerema - Delivery requests:

Cate is gathering requirements for features that were ranked highly, one of which was delivery requests. Not all institutions do this, but it will be a go-live requirements for those that do. Cate created a notes document to get conversation started. To test current state, Cate created a request on an available item and selected fulfillment option delivery, then selected home address type for delivery and saved request. Page request was created and item status was set to paged, just like it was supposed to. Unfortunately, things started to go awry at this point: it seems that when you select delivery, routing behaves as though there is no request for the item and tries to route it back to its home location. Cate asked if the following constituted the ideal state: when an item is checked in at any service point, “Route for Delivery” modal displays in FOLIO, item is checked out and changed to “Closed - Filled,” delivery slip is printed, and an “on its way” notice is set to patron. Group confirms that this is accurate.

Currently, all requests can be filled by “hold shelf” or “delivery.” Multiple addresses can be entered as delivery options. Andrea: how do we limit options that patrons can select? Don’t want to deliver to people’s homes, except in special cases such as people who are disabled. What is desired is an equivalent to “Default Service Point” feature used for hold shelf. Currently at Duke ability to receive deliveries is determined by patron type (e.g. faculty can receive deliveries) and delivery location is logically extrapolated from their status (in case of faculty, for instance, delivery location is based on department affiliation). Cate will work on incorporating default address feature into delivery option.

Cate Boerema - RA needs for Inventory

Question: how much are RA folks weighing in on rankings for inventory features? If we have granular UXPRODs that can be ranked at the institution level, does that work for this group, or should a separate process be developed?

Group indicated that situation varied by institution. At Five Colleges, for instance, RA is not part of Implementation Team. Duke and UChicago are involved in ranking, though.

Cate will forward emails from Charlotte to RA mailing list so that members can go in and comment on whether or not things are needed for MVP.

Discussion of UXPROD-1923: Implement material type category. Right now just a flat list. Would be nice if it could be organized hierarchically in settings, which would improve search and filter view. Question: how important is hierarchical display (not an easy fix)? Consensus that it would be good, but probably isn’t MVP. Similar issue and priority with location.

Brief discussion of UXPROD-1924: Andrea shared a link to the associated JIRA (https://issues.folio.org/browse/UXPROD-1924) for this issue and noted that you can navigated to any JIRA by changing the number at the end of the URL.

Cate shared a link to sign up for the FOLIO-RA mailing list: https://ole-lists.openlibraryfoundation.org.

Cate demoed rag-and-drop re-sorting of request queues, which the group liked. Consensus that we would want to limit which users have this ability: anyone who has access to circ should only be allowed to view the queue, but only some people should be able to edit it. Cate will talk to the developers about this.

Group confirmed that no one can think of any instance in which a hold should be prioritized ahead of a recall (re-sorting is only possible within these two categories, not across them).