Date
Attendees
- Andrea Loigman
- Andy Horbal
- Jana Freytag
- Holly Mistlebauer
- Elizabeth Chenette
- David Bottorff
- Kai Sprenger
- Cate Boerema (Deactivated)
- Laurence Mini
- Joanne Leary
- Emma Boettcher
- Kimie Kester
- David Larsen
- Sharon Wiles-Young
- Darcy Branchini
- Mark Canney
- Magda Zacharska
- Donna Minor
- Cheryl Malmborg
- Rameka Barnes
- Cornelia Davis
- William Weare
- Regina Frindt
- mey
Discussion Items
| Time | Item | Who | Description | Goals | |
|---|---|---|---|---|---|
| 5min | Housekeeping | Andrea Loigman |
| ||
| 10min | Blocks | Holly Mistlebauer | discuss 2 additional types of patron blocks | Answer question about patron notices for manual and automated patron blocks. Also mention two type of blocks not previous discussedForgot to ask these two questions when discussing blocks on September 30 | 1) Should patron notices be sent for manual patron blocks? Automated patron blocks? 2) Patty W. (a PO) recently asked me about these types of blocks:
|
| 15min | Claims returned | Emma Boettcher | User record notes for claims returned | Gather requirements for ending claims process and adding note about claim returned to user record. Decide how many notes fields are needed. | |
| 15min30min | Requests | Cate Boerema (Deactivated) | Delivery requests: checking in should automatically check out item to requester | For delivery requests, we had a requirement that said that, when the item was checked in, it should be automatically checked out to the requester (when top request in queue is delivery request). Questions:- Do we need to present the check out notes? - Would check out notes ever prevent check out and, if so, what should happen to the item and request status? - Need to focus on very thin thread here, but this is in development and getting somewhat complicated due to these questions The challenge we have run into is that check out can/should be prevented for a variety of reasons:
Given this, we really can't auto-check out items. Instead, we may need to do the following:
Introducing the new request and item state make this feature significantly more complex. Do people have ideas for how to simplify for MVP? If we do decide to introduce the new states, we need to:
|
Meeting Outcomes
Functional Area | Product Owner | Planned Release (if known) | Decision Reached | Comments |
|---|
Notes
Item based inventory search:
- Small Group meeting topics: search box, filters and item segment
- What we want to have: Segmented control (like in Finance app, Orders app), default unfolded filter options (further description see also: UIIN-758)
- No advanced search for mvp but query language search (UIIN-724)
- For now: multi column list for results, long term: see philips ux prototype
- Item segment (UIIN-761) (requirements were discussed in the smallgroup) please comment on the slides/questions:
- Search terms - on Item search
- Order of the filters
- Other observations, comments ideas
- Filters can be very long lists, but a search box with just the first few results should be good
In transit report:
- If an item is in transit and a request is made on it from another service point, should the service point also be exported? And the destinations service point?
- David: you would want to have the service point where the item was before/last and the destination service point
- Info: last send in transit to, Pick-up service point for request
- from where should the report be run?
- Check-in-app, inventory
- Would be helpful to have automatical reports - but this is not going to happen soon
- Should we cut the patron information and have it in inventory or do we keep them and leave it in check-in?
- there is just patron group in the report so it can be in the inventory app
- Check-in-app, inventory
Review notice triggering events and tokens for automated fee/fine:
...
- optional would be good
- for some german libraries it is the case, that every book in the third reminder circle is on the third printed notice
...
| Fees/fines | Holly Mistlebauer | Post-MVP | Holly created 2 JIRA issues: UXPROD-2109: Allow for patron notices to be sent on request for manual patron blocks UXPROD-2108: Expand patron blocks to allow blocking of borrowing by material/item type | Informational blocks will be handled by user notes |
| Loans | Emma Boettcher | Q4 | Add additional field for patron-facing (notice) information in declared lost & claim returned resolution actions When resolving a claim returned item, create a note on the user record with the outcome of the claim and a link to the loan. | |
| Requests | Q4 | Above described solution with new item and request state seemed like best approach to SIG. We updated the request whitelist And we specified some other key requirements in this document: https://docs.google.com/document/d/1iWhEAxd3hvlvqmDgXmbJ2a3A_J2ahQHaMN2RKvDLvWI/edit?usp=sharing I have enough to go on for now. May come back with follow up questions later. |
Notes
- Blocks - Holly Mistlebauer
Q: Should patron notices be sent for manual patron blocks, whereby the block is set by someone in the library (because, for instance, we don’t have a valid address for them)? Should patron notices be sent for automatic blocks, whereby the block is set automatically by the system (because, for instance, they have exceeded a fine limit)?
Cornell indicated that they have never sent notices like this in the past? Chicago indicated that they would like this OPTION, but don’t want it to happen every time. Not needed for MVP. Holly reminded everyone that we can already display these blocks in the patron view in the discovery system if we choose to. In response to feedback from Chalmers, Holly clarified that blocks aren’t currently working in self-checkout because it’s not in the API, but this is a known issue that is being worked on. There’s also an issue with EDS, for which Chalmers will create a JIRA.
A: Holly will create a feature for post-MVP giving people the option of sending notices.
Holly also asked about two types of blocks that we haven’t previously discussed:
- Informational block where nothing is blocked, you just want the patron's attention -- would this be a note or something else?
- A way to block the patron from checking out laptops due to their bad past behavior with laptops.
Chicago indicated that OLE treats these as notes, not blocks. Erin and Jana from User Management will present to the RA SIG on this topic next week. The consensus in the SIG is that something that gets staff attention (such as a note) is needed, but it doesn’t need to be a block per se.
- Claims Returned - Emma Boettcher
For claims returned items, does information entered into “additional information” field anywhere other than the comments on the loan itself (which is the only place it displays now)? For instance, should we write an automated note that appears on the user record? Consensus is that this would be a great feature, but is not needed for MVP.
When applying a “Lost” status, the option is given to “notify patron.” The SIG discussed whether or not this notification should include the notes entered in the additional information field and a consensus emerged that the functionality we want is to have the option to enter additional information for both the patron and staff (which might be different) to view. This definitely should be consistent across FOLIO.
- Requests - Cate Boerema
The notetaker instigated a brief discussion of the reasons why patrons couldn’t be blocked at the point of placing the delivery request instead of at the point of checkout. Mainly, it is because things can happen between the time when the request is placed and when the item is ready to checked out, and these things happen often enough and are great enough significance that this should be avoided at all costs. The SIG was not able to think of an alternative to the solution Cate described in the agenda. The SIG indicated that by and large items with the new status “Awaiting Delivery” should have the same properties as an item “Awaiting Pickup.”
...