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.
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
server
System JIRA
serverId
01505d01-b853-3c2e-90f1-ee9b165564fc
key
UXPROD-1877
)
Thoughts on how best to capture RA input on Inventory features?
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
server
System JiraJIRA
serverId
01505d01-b853-3c2e-90f1-ee9b165564fc
key
UXPROD-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)
SIG also liked this mockup for Users but wanted the ability to select from address types to indicate the default address type used for delivery requests
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
There's still consensus that there isn't a use case for a Hold being positioned above a recall
...
Brief discussion of UXPROD-1924: Andrea shared a link to the associated JIRA (https://issuesfolio-org.folioatlassian.orgnet/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.