Resource Access Parking Lot
This Parking Lot is obsolete! Product Owners should create all Parking Lot items as issues in the UX PRODUCT JIRA Project.
| Date raised | Issue | Area | Comments/Questions | Entered By | Date Moved from Parking Lot | Status |
|---|---|---|---|---|---|---|
| 2017-07-?? | Use of enter in place of click | checkout | SIG has asked that one click be required on pop-ups for checkout and check-in. This came up while discussing the proxy pop-up. If the person doing checkout hits enter, the items being checked out will be charged to the person standing at the desk, who may not be the intended borrower. | Holly Mistlebauer | ||
| 2017-07-?? | Lost items process | partly Fees/Fines | While discussing fines and fees, the issue of lost items was raised. It was pointed out that charging the fine is just one part of a multi-step process in reporting an item as lost. We need to develop this process. | 3/22/2018 | This is JIRA issue UXPROD-87, which is in progress (Holly) | |
| 2017-07-?? | Historical item details for fees/fines | Fees/Fines | When we add /fines for overdue items, we will need to have historical information available about how the item looked at the time the overdue was charged. We need to know when the person checked the book out, when it was due, when they finally brought it back, etc. | 4/13/2018 | The loan information is being saved with the fee/fine data, so this is being taken care of as part of the process. (Holly) | |
| 2017-08-?? | Localization of currency | Fees/Fines (and other monetary functions) | Not all currencies use a period between the 1 and the change like the US does ($1.20). For example, in Germany they use 1,20 to represent 1 euro and 20 cents. We need to allow for the library specify what they want to have displayed. My understanding is that this feature is not slated for v1. Holly: you might want to double check the internationalization tab in the roadmap. My understanding is that v1 should handle currency, currency codes, decimals, and financial localization properly, since it will be needed for acquisitions financial management as well. Ann-Marie Breaux (Deactivated) | |||
| 2017-08-?? | Patron blocks | checkout | When discussing the patron checkout display data the issue of patron blocks arose. We need to determine how these will be handled, which includes entering a block, displaying the block, and enforcing the block. | 3/22/2018 | This is JIRA issue UXPROD-82, which is in progress (Holly) | |
| 2017-08-17 | Permission overrides | checkout, Fees/Fines, (and other places) | There needs to be a consistent way of doing overrides for circulation functions. When students or other workers don't have permission to do a certain task the supervisor needs to be able to step in and override the system to allow the task to be completed. | 3/22/2018 | User Story UIU-445 is first request for override feature. A shared component will be developed for use by checkout, loans, etc. (Holly) | |
| 2017-08-24 | Calculation/display of accruing fines | Fees/Fines | How do we represent fines that are still in the process of being calculated? e.g. an overdue fine for an item that has not yet been returned | Andrea Loigman | 3/22/2018 | This is JIRA issue UXPROD-392, which is in progress (Holly) |
| 2017-08-24 | Bursar rejects the transaction and sends it back to the library | Fees/Fines | We need to be able to handle this situation. If the fee/fine is marked as closed it will need to be reopened. | 3/22/2018 | Holly has added this as a question to be addressed by Fees/Fines sub-group and/or RA SIG. | |
| 2017-08-24 | Keeping information about an item when a fee/fine has been paid | Fees/Fines | We want to keep loan history for items that have unpaid fees/fines, but what about items with closed fees/fines? We need background information supporting the fee/fine, but we don't want full loan history. | 4/13/2018 | This is covered by UXPROD-447, which is assigned to Emma. (Holly) | |
| 2017-08-24 | Use of terms fee and fine | Fees/Fines | Some places we are using fees/fines, others just fees, and still others just fines. We probably need to be more consistent. comment - Fines and fees are two different things, so all for consistency, but we also need specificity. | October 2017 | We have agreed to use "fees/fines" everywhere. (Holly) | |
| 2017-09-26 | Tenant setting for how much loan history to retain | Loans | Different institutions will have different rules around how much patron loan history to maintain. Need to design/discuss the setting. Also part of this discussion: if we clear patron data from loan history, should we retain general loan history for an item (scrubbed of patron identity) for reporting. | Cate Boerema (Deactivated) | January 2018 | Discussed with RA SIG. FOLIO-1017 captures high-level requirements. Need to review with RA and Privacy SIGs. |
| 2017-09-26 | Tenant setting for hiding the profile pic box | Users and Checkout | Many institutions won't have profile pictures/avatars in FOLIO. We need a tenant level setting for disabling this so the real-estate isn't occupied by a big empty box or generic avatar | September 2017 | For checkout picture was moved to right side–it's absence won't leave a hole. There is a setting now as well. (Holly) | |
| 2017-09-26 | Normalized call number | Loans; Fees/Fines | Need a normalized call number stored and used for sorting on Loans page. We are currently displaying a concatenated call number on the Loans page to save on real-estate. But sorting by this concatenated string isn't going to work. FOLIO needs to store a "normalized"call # and use that for sorting on Loans and elsewhere. From experience, this data really needs to be stored as opposed to generated on-the-fly. This is a must-have for v1. | Cate Boerema (Deactivated) | 3/22/2018 | Holly created related JIRA issue UXPROD-393 on 3/22/2018. |
| 2017-09-26 | More than one preferred contact method | Users | Some SIG members thought it would be useful to allow users to have >1 preferred contact method so they could receive, for example, both texts and email notifications. The current design only supports one preferred contact method. Will come back to this. | October 2017 | User story in backlog awaiting prioritization: UIU-275 | |
| 2017-09-25 | Sort by first author | Loans | We decided we wanted to support sorting by "first author" when there are multiple. I am going to hold off on entering this story until we have finalized the instance metadata and have a sense of how authors, creators etc will be made available. Parking for now. | |||
| 2017-10-23 | Change due date from Checkout screen | Checkout | We were looking at the new checkout screen and Wendy mentioned that she'd like a way to change the due date right from this page (as opposed to having to go to the Loans page to do this). Voyager allows right click to change date or something. Need to discuss further. | Cate Boerema (Deactivated) | ||
| 2017-12-12 | Option to backdate check in date and time from the “check in” screen | Checkout | For example, if you are not able to check your campus book drops for several days due to weather (or whatever reason) and you need to check in all the books you finally are able to fetch out of them, you need to be able to “back date” the check in by date and time to avoid fines that may have accrued while sitting in the book drop. | Cate Boerema (Deactivated) (proposed by Rameka Barnes) | ||
| 2017-12-13 | Solution for auto-checkout or remote/delayed checkout of In Transit for Delivery items | Requests / Checkout | When items are In Transit for Delivery to fill a Request with fulfillment preference of "Delivery" the items need to be checked out to the requester at some point, but facilities may not be available to actually perform the checkout when the item arrives at its delivery destination (e.g. a department mail room) Some systems have the option to do an automatic checkout for delivery items, which is not an ideal solution. SIG would like to design something better. Amazon lockers came up as an idea. | Tania Hewes | ||
| 2017-12-13 | "Recently Returned" status | Check in | Need the ability to set a period for a "recently returned" status to be automatically applied to and removed from an item after it has been checked in at home and is available for loan. This period should be configurable by location, possibly by material type? The status is used to indicate to the public and to staff that, though the item has returned home and is available for loan, it may not have been reshelved yet | |||
| 2017-12-13 | Item statuses - some need to be manually editable | ?? | Some item statuses need to be manualy changed by eligible staff, and others need to be sacrosanct and only changeable by system actions like checkin, etc. The list of item statuses which can and cannot be manually changed needs to be defined. | |||
| 2018-01-11 | Request List page (need to revisit) | Requests | Need to revisit this page and make sure that we have all the data we need displaying here, filters etc. Also related, there are some request-related reports that may be launched from this UI or may be generated elsewhere. | |||
| 2018-01-11 | Check-in page when patron data is scrubbed from loans immediately | Check in | How does the Check In page look different for institutions that immediately scrub patron info from loan data after check in? Relates to anonymizing work (FOLIO-1017) as well as to Darcy Branchini's work on the Check In page. | |||
| 2018-03-06 | Requests: undo cancellation | Requests | an Undo function to un-cancel an accidentally cancelled request | |||
| 2018-03-06 | Requests auto-cancel reasons | Requests | Capturing some kind of cancellation reason when a request is closed automatically by the system, e.g. when it expires. This would be in addition to the request status. We tabled this for a future discussion since it is a post v1 type of idea | |||
| 2018-03-15 | Cancel Loan | Loans | Not for V1. Cancel loan would be used as a way to remove accidental loans, but would need to be locked down to prevent nefarious use. Currently, Aleph may be the only system that allows this (referred to as "delete loan".) | Emma Boettcher | ||
| 2018-04-12 | ILL in-library-use | Requests / Loans | When ILL items are marked for "In Library Use Only" we'd like to devise a way to check the item in and out to the requesting patron without fully "fulfilling" the request. It's similar to reading room or special collections functionality but not identical. The sequence of events might look like this: ILL In-Library-Use-Only item arrives. Item receives an ILL ship-me-back due date of YYYYMMDD which is the date the item need to be shipped back to the lender. Item is placed on a hold shelf for the requesting patron. the patron comes to the library to use the item, staff check the item out to the patron so that the system and staff know that the patron currently has the item in hand and that it isn't on the hold shelf. If there is a Request associated with this ILL transaction it should NOT be closed at this point. The patron uses the item, returns it to the service point. Staff check in the item but it does not go back to the lender, but instead is placed on the hold shelf again for the next time the patron visits to use the item. This checkout-checkin-hold-shelf sequence could repeat multiple times. Any request associated with this ILL transaction should not be closed until staff act on it - either because the item's ILL ship-me-back due date has been reached, or the patron indicates they are finished with the item and it can be shipped back to the lender. |