Date
...
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 | |
| Requests/Check In | Cate Boerema (Deactivated) | Q1 | Some members of the SIG (5 Colleges) definitely needed different modal popups for the different in transit scenarios (in transit home vs in transit for request). For this reason, I created a new UXPROD feature: UXPROD-1411 For Q1 2019, we will stick with a generic transit modal (Chalmers doesn't need separate modals to go live). | Different popups are needed is because they have different workflows for the different types of transits and, in the case of 5 colleges, they don't print transit slips so they can't rely on the info those slips contain. Other members of the SIG also preferred two different modals. | ||
Notes
Fixed due dates and renewals (Sean):
Q: How to calculate the due date when the fixed due date is sooner than the minimum guaranteed loan due date? Options:
- Create an alternate due date that would apply in such circumstances. The alternate due date could be a rolling due date.
- Renewal date would be the next semester’s fixed due date
- Other?
It was decided to discuss this issue with reps from the U of Chicago, who had requested the alternate due date feature
Modals for In-Transit discharges (Cate):
When an item has a request on it and goes in transit to a pickup library, what information do we need on the modal? Currently, the modal does not indicate there is a request, but simply says to route to <library X>. Cate said that to include additional information would require considerably more programming. Is this piece of information necessary? The Five Colleges do need this because of their work flow (they also need the actual patron information); most other libraries felt that having a statement that the item had a request would be helpful, at minimum. Cate asked if it would be enough to have the requestor information print out on the routing slip? Five Colleges: no, since they don’t print the slips; William, no, because of privacy concerns in a public-facing workstation; Susan and Andrea, no, because they must have the information before the routing slip is printed; Cornell does not need patron information on the modal, or even the fact that there is a request, because all in-transit processing goes through the same channel; but it would not hurt to have it. Cate concluded that we may need an additional in-transit modal for items with holds – save for future discussion