2021-06-21 Resource Access Meeting Notes

Holly Mistlebauer 16:27 Uhr (via Slack in #ressource-access)

Looks like I didn't ask about check-ins/check-outs, but Cate did. Please go to the "Performance" tab of the spreadsheet at https://docs.google.com/spreadsheets/d/1oa5PnM9HqbKQl1lAe08aKojz29Go_-amQCNiMzwPnZc/edit?usp=sharing. The expectation is that it will take less than 1 second. At Cornell is painfully aware, we aren't there yet. I have created two Spike JIRA tickets for this and assigned them to the sprint that starts on Monday. The tickets are UICHKOUT-726 and UICHKIN-269. I have named Cornell and MO State as "Affected institutions". Other institutions should add themselves as needed.

45 Min

Title level requests

Stephanie Buck

Continued discussion and updates on TLR

Link to Google folder of mockups. We looked at 15-request-on-instance.png. It has been updated based on our conversation.

Meeting Notes (David Bottorff, notetaker)

Response times for checkins and checkouts (Andy Horbal)
- What is the slowest you could tolerate
- Cornell 2-3 seconds every time for both in test system
- Jana-that would not be acceptable gbv
- Andy would you pull the plug?
- Cheryl I don’t think this would be acceptable
- David I don’t know that I could say that but would be loathe to go forward without a plan to reduce timing in short timeframe
- Erin pdf describing functions-can do 20 or more API calls at a time
- Erin thought process will be is this a business need or a staff expectation?
- Lehigh has consistently had a second or less
- Chalmers also faster has not measured
- Cheryl Cornell was real world testing with other actions happening
- Cheryl It becomes a problem if staff are doing the checkout, more of a problem with self service checkout
- Jana something to discuss further to our next meeting?
- Andy hit me up in chat or slack but having idea of consensus of what would be tolerable
- MO state is not regularly seeing >1 second unless doing data import or export
Title Level Requests (Steph Buck)
- Mock-up combining into one queue
- This is most complex mock-up. Item and title level on same instance
- David do we need something to indicate when something is a title level request?
- Header “awaiting fulfillment” seems confusing to several.
  - What about in progress? Confusing with in process?
  - Could we move in transit to lower accordion?
  - Andrea separate queue of awaiting pickup or delivery?
  - Bottom list can be reordered. Top list cannot be reordered
  - Assigned requests? For first accordion Marie
  - Fulfillment in progress seems to be consensus - translation will work for GBV?
- David less concerned about language and more about the logic of what goes into each accordion. In transit would stay in top accordion
- Questions around title level paging workflow, and title level hold requests (would these appear in paging list?)
- Is there logic that weights things geographically or otherwise? item level logic in place at Chalmers
  - eventually we would want some logic based automatic reordering. Also some flag for manual reordering so that automated reordering would not reset and bump something back down.
  - David - also as we move away from requests for staff needs (reserves, preservation, etc. needed for) to determine whether staff needs trump patron requests or vice versa. Perhaps a flag in the staff request as to whether it trumps or not?
- position queue number in first accordion should match second accordion?
  - Brooks - depends on perspective - title level is dynamic and changes things
- UI - could we get hold shelf expire date in first accordion?
- Will continue TLR discussion on June 28

Meeting Outcomes

Functional Area	Product Owner	Planned Release (if known)	Decision Reached	Reasoning	Link to supporting materials
e.g. loans, fees/fines	Name	e.g. Q4 2018, Q1 2019	Clearly stated decision	Because... Because...	e.g. mock-up, JIRA issue