2020-08-10 Resource Access Meeting Notes
Date
Attendees
Discussion Items
| Time | Item | Who | Description | Goals/Info |
|---|---|---|---|---|
| 2min | Administrivia |
| ||
| 30min | Circulation log | Follow up on: Decide what actions and what information about those actions relevant to requests is worth recording in circ log | ||
| 20min | Notices & Circ log | Decide how to display notices that were sent for multiple items in the circulation log |
Meeting Outcomes
Functional Area | Product Owner | Planned Release (if known) | Decision Reached | Reasoning | Link to supporting materials | Comments |
|---|---|---|---|---|---|---|
| e.g. loans, fees/fines | Name | e.g. Q4 2018, Q1 2019 | Clearly stated decision |
| e.g. mock-up, JIRA issue | |
| Circulation log | Emma Boettcher | For all request actions, display type and pickup service point/address type in search log. In addition, canceled requests should show the cancelation reason, edited requests should show the old and new values for what was edited, and queue reordering should only be logged when done manually. | ||||
Notes
- Needs more feedback related to the circulation log.
- Related to requests, which information should be included in the circulation log?
- Created: can choose from type, expiration date, position in queue, fulfillment preference, pickup service point/address type
- David Bottorff : thinks fulfillment preference and type would give vital information to discern whether or not he needs to click into the request for more information.
- Andrea Loigman : agrees with those information points, add to that the pickup service point/address type. Would love all information, but thin thread would be type (hold/page/recall), pickup service point/address type (can help infer fulfillment preference), fulfillment preference.
- Expiration date and position in queue are less essential because many institutions set expiration date far in the future and current queue position is typically more useful than snapshot queue position at creation.
- Decision on thin thread: type (hold/page/recall), pickup service point/address type, fulfillment preference
- Cancelled: should reason for cancellation and additional information be included in the log or just a click away?
- Andrea Loigman : thin thread should be reason for cancellation; additional information can be a click away. What is the information I need to see in a group (sorting, etc.) versus what do I need to know about a single request?
- Joanne Leary : agrees that cancellation reason is most important info point here.
- David Bottorff : is there a distinction between a cancelled request before it's on the hold shelf versus after? Emma doesn't think there is, but will check with Cate.
- Decision on thin thread: : what's needed for thin thread: cancellation request, type, pickup service point/address type
- Moved: when viewing the circulation log, do you want to see the requests moved to a particular item or moved from a particular item?
- Emma Boettcher : whichever item displays in the item ID column (new or old), potentially the opposite item ID (new or old) could be displayed as information in the log description itself.
- Brooks Travis : is there an option to drill down to a specific request ID to see all actions on that particular request? - Emma will check.
- Emma Boettcher : clarified that the multi-ID search and filter does not exist elsewhere; proposes merging the fields to be a search similar to inventory. If you enter a user and item barcode in the same search field, it could act similar to a title/contributor search. (This pattern exists, where the multi-ID search pattern does not yet exist.)
- Jana Freytag : combining the searches is not bad, but would like to see it visualized. Emma will frame it for a future RA SIG discussion.
- Joanne Leary : when you're searching for something, it's more likely you'll have access tot he new barcode; proposes having this in the item ID field.
- Decision on item ID placement : discussion seems to support new ID in the item ID field, with the old ID in a description.
- Delineating actions when an item is returned that has an active request:
- Separate the closed loan from the request status change from the check in (all on separate lines)
- On check in line, resulting item status and in-transit destination are important, but backdating is not as important in this context
- On request line, new request status has greater priority than old request status; also important is the type, pickup service point/address type, and fulfillment preference
- On closed loan line, 'resulting item status' should be duplicated (even though included in check-in) because this can differentiate loans closed via an alternate method to check in (e.g. claims returned to missing or checked out to claims lost)
- Edited: have new and old values reflected (for type, expiration date, fulfillment preference, pickup service point, address type)
- If old values aren't retained elsewhere, it's helpful to have them displayed here
- Decision on thin thread: include both old and new values
- Reordered: should this include only those acted upon to reorder or the "reordering" that happens naturally as holds are filled/expire
- Decision: only include reordering by staff intervention; include old queue position and new queue position
- Created: can choose from type, expiration date, position in queue, fulfillment preference, pickup service point/address type
- Move "Decide how to display notices that were sent for multiple items in the circulation log" to next Monday. Emma Boettcherwill update planning document.