Versions Compared

Old Version 2

changes.mady.by.user Cate Boerema (Deactivated)

Saved on

compared with

New Version Current

changes.mady.by.user Cate Boerema (Deactivated)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

Attendees

Discussion Items


TimeItemWhoDescriptionGoals
5 minHousekeepingAndrea Loigman
  • Notetaker
-  
  • -  Andy Horbal
5minCheck-inEmma BoettcherCheck-in volumeHow many items are likely to be checked in during a given session?
45minRequestsCate 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/

 

Jira Legacy
serverSystem JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-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

10minInventoryCate Boerema (Deactivated)RA needs for Inventory
Met
  • Cap planning group 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 (
    Jira Legacy
    serverSystem JIRA
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyUXPROD-1877
    )
  • Thoughts on how best to capture RA input on Inventory features?
10minRequest queue page with reorderingCate Boerema (Deactivated)Request queue page with reordering


Meeting Outcomes

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Comments

Inventory features for RA

Cate Boerema (Deactivated)

Q3, Q4 and beyond
  • Per agreement with Charlotte and select Inventory SMEs, the key criteria for deciding whether a feature is must-have for Inventory for MVP is whether it's needed by non-catalogers (e.g. RM or RA staff) to do day-to-day work
  • RA SMEs are sometimes but not always involved in ranking Inventory features
  • RA SIG will do a comprehensive review of existing and proposed Inventory features to indicate which are needed by RA staff. 
  • This will help with Inventory prioritization and serve as requirements for the "RA view of Inventory" feature 
    Jira Legacy
    serverSystem JIRA
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyUXPROD-1877
  • Since that will take some time, Cate asked that the RA SMEs review the new Inventory features Charlotte just split and provide input on those either through ranking (if they are involved) or in the comments. (Emails were forwarded to RA SIG mailing list with links to the various issues)

Delivery requestsCate Boerema (Deactivated)Q4, if approved in MVP proposal
Request queue reordering

Cate Boerema (Deactivated)

Q4, if approved in MVP proposal
  • Reviewed mockup here: https://drive.google.com/file/d/1VBGboSPqwuaZH5k0k4dH5xWdPEjVCG8y/view?usp=sharing 
  • SIG agreed this looked good
  • Very important that not all staff can do this
    • Since we don't have "action-based permissions" yet, we could just wrap this capability with Edit requests (people seemed okay with that)
    • But there is potentially value in people who don't have edit access being able to view the queue (but not edit it)
    • Then again, there was concern that staff might view the queue and tell requesters things like "well, you're second in the queue, but the person before you is a lowly undergrad" which would, obviously, not be good.  But that could be handled through training.
    • Cate to consider design and discuss permissions with developers
  • Reviewed mockup for how this page would look AFTER we have auto-sorting of recalls above holds: https://drive.google.com/drive/folders/13QEa5qC8seKkGmVcFwfG1glStoHUiuKs
    • People agreed this looked good
    • There's still consensus that there isn't a use case for a Hold being positioned above a recall


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://folio-org.atlassian.net/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 Boerema - Request queue reordering

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).