François Renaville
My feedback
38 results found
-
182 votes
Hi all,
We would like to update that we are planning to add this functionality to the Primo Next Discovery Experience User Interface.
We are currently evaluating it together with the Alma team.
More details on the plans for the new interface can be found here:
Best regards,
Yael.
An error occurred while saving the comment An error occurred while saving the comment François Renaville commentedHi Nili,
Thanks for asking! We had a look at the new Request type filter in My Library Card (Primo February 2020 Release) that allows users to select one or more request types to filter requests based on the selected request types. We consider this as a nice new feature, but it does not meet our original expectations in my institution that came to create this idea.
An additional Status filter could maybe be interesting, but this would probably require an action from patrons who do not want to see completed/rejected/inactive requests. We would like to avoid patrons to systematically use such a filter to hide completed/rejected/inactive requests they don’t want to see. So, if a new Status filter could be (1) set by default to only display Active requests and (2) remain across sessions, that would be great.
Additionally, there could be other possibilities. For example:
(A) By providing the Purchase Request type and the Purchase Request status with specific IDs that libraries could use to hide by default any completed/rejected Purchase Request in My Library Card by using the Customization Package (CSS).
(B) By adding a new true/false setting in the Primo BO / Primo VE Discovery Configuration tables that would allow libraries to decide whether or not they want completed/rejected/inactive requests to be displayed in My Library Card.Generally speaking, we are a bit confused here to see that Purchase Requests are not processed in the same way as the other requests (Hold, Digitization, Booking) that are not visible anymore in My Library Card once they have been completed or canceled. If you add a new Status filter, does that mean that all completed and canceled requests will suddenly become visible for patrons in My Library Card?
I appreciate your efforts to find a lasting solution to the situation.
As always, any comment or suggestion from the community would be most welcome!
Regards,
François
An error occurred while saving the comment François Renaville commentedThanks for the update, Nili. A Request Type Filter may be a good option in several cases.
I would like however to draw your attention to the current inconsistency in the MyAccount: Completed or Canceled ILL, Digitzation or Hold Requests are NEVER displayed in the MyAccount, only *Active* ILL, Digitzation and Hold Requests are, while Purchase Requests are ALWAYS displayed, whatever their status (Active, Completed or Canceled).
(1) Do you plan to display in the future all Requests, whatever their Status? -> Also completed and canceled requests would be displayed.
(2) Do you plan to add also a Status Filter? For example only Active Requests (whatever their Type) would be displayed by default.
Kind regards,
Fr.
An error occurred while saving the comment François Renaville commentedThere is also the following idea:
Sort purchase requests in Primo, by newest
https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/34676683-sort-purchase-requests-in-primo-by-newest@Stacey: Thanks for your comment and the link. I don't understand why Primo is so important. Wouldn't your librarians be happy if their purchase requests would rather be visible in *Alma*?
I wish it would be possible to hide completed/rejected purchase requests with the Customization Package (it would make me happy), but we have not been successful in achieving that. Any hint?
François Renaville shared this idea · -
77 votes
An error occurred while saving the comment François Renaville commented@Moshe: Even without the 'User List View' privilege, the users search option remains available (tested on the Circ Desk Ope Limited in our Sandbox). I suspect there might be another privilege in conflict. We have a case about this. Thanks.
An error occurred while saving the comment François Renaville commentedThanks, Moshe. I found an old case where I can see that this had also been explored, but I don't remember all details.
However, I'm going to open a new case and ask to disable both ALLOW USERS SEARCH (for CIRCULATION_DESK_OPERATOR_LIMITED and REQUESTS_OPERATOR) and USER LIST VIEW (for CIRCULATION_DESK_OPERATOR_LIMITED) in our Sandbox. Thanks for your suggestion.
François Renaville shared this idea · -
51 votes
Thank you for your suggestion. The Rialto team is reviewing this idea to determine how it might fit into our future plans. We cannot provide a timeline for these ideas, but be sure to check back often and vote for the ideas you support to receive status and comment updates.
Best,
Heidi Whitehead
Rialto Product Manager
François Renaville shared this idea · -
79 votes
This is in development as part of the 2024 NERS enhancement process: 8530 (Prevent multiple requests from a same borrowing library within a short period of time)
Thanks!
-Mike
François Renaville shared this idea · -
174 votesFrançois Renaville supported this idea ·
-
106 votesFrançois Renaville supported this idea ·
-
461 votes
For full transparency, the commitment we made for this idea is to do the analysis for this feature in 2024. Based on that analysis, we will craft a solution that we can deliver in early 2025. We will keep you updated via this idea.
François Renaville supported this idea · -
40 votes
An error occurred while saving the comment François Renaville commentedThanks for the update, Manu! ;-)
François Renaville shared this idea · -
18 votesFrançois Renaville supported this idea ·
-
35 votesFrançois Renaville shared this idea ·
-
60 votes
An error occurred while saving the comment François Renaville commentedWhen we reported to the Library Mobile project implementation team that it was not always possible to go back to search results with Primo PI, we were replied the following:
"This is a known issue and can't be changed. The behaviour follows Android developer best practices for navigation hierarchy and the usage of hardware back button as a local back within the feature, and the application back as a feature back button."We still do think that the current behavior does NOT follow best practices from a UX perspective and that app users should not be forced to click on the History button to re-run their initial search to find their search results back... Primo PI should NOT provide less options and possibilities that using Primo in a browser in responsive mode.
François Renaville shared this idea · -
72 votes
An error occurred while saving the comment François Renaville commentedWhen we reported to the Library Mobile project implementation team that there was no Advanced Search option (with Primo PI) in portrait mode, we were replied the following:
"This is the expected behaviour. It is Primo VE's styling kicking in for the device display size/width. If you resize the web app, you will also see that the advanced search link does not display."
We still do think that Primo PI should NOT provide less options and possibilities that using Primo in a browser in responsive mode.François Renaville shared this idea · -
64 votesFrançois Renaville shared this idea ·
-
69 votes
An error occurred while saving the comment François Renaville commented+1
François Renaville supported this idea · -
186 votes
Hello, this is on our roadmap for 2024, thanks!
François Renaville shared this idea · -
118 votesFrançois Renaville shared this idea ·
-
322 votes
We’re looking at adding an indication in the Manage In Process Items next to a request where there are more digitization requests for the same item in the queue. A row action will allow the staff to complete the current active request and activate the next.
An error occurred while saving the comment François Renaville commentedThank you very much, Moshe! Looking forward to seeing this indication.
All the best,François
An error occurred while saving the comment François Renaville commentedHere is a recent use case that we encountered within our Alma/RapidILL integration:
1) 4 RapidILL lending requests are created in Alma for several book chapters published in the same book available in print in the library
2) Resource Sharing operator creates the necessary digitization requests to get digital copies.
3) Circulation Desk Operator sees the Pick from Shelf notification in the Task List. Since all chapters are in the same item, there is just one barcode to scan. Operator sees the *first* digitization request information and fulfills the request. There is NO ALERT about the fact that 3 other requests are waiting for process...
4) The completed digitization request is sent back from Alma to RapidILL for the requesting library. The other 3 requests remain in Alma until an operator monitors and checks if there is no forgotten or problematic request…
Unfortunately, this comes up to often and is not nice for RapidILL libraries either.
François Renaville supported this idea ·An error occurred while saving the comment François Renaville commentedI submitted case 00845121 and I got this reply:
"yesterday I discussed your request with our product management department.
While we understand why the current workflow is suboptimal under the described circumstances, there is currently no way to change it as it would require some design on the developers' side.
So I need to ask you to submit your product idea via our idea exchange website."I see the current situation more like a under-developed process rather than like a bug. I wish that could have been managed by the default digitization process :-/
François Renaville shared this idea · -
222 votes
Dear all, we are currently looking into the possibility of a re-design of the quick cataloging functionality - we will take this request into consideration as part of this future change.
An error occurred while saving the comment François Renaville commentedThis would indeed be a nice enhancement!
François Renaville supported this idea · -
62 votesFrançois Renaville supported this idea ·
-
21 votesFrançois Renaville shared this idea ·
Great news! Thank you!