Primo
Your feedback matters to us. Help us improve Primo by telling us what you’d like to see using the message areas below. You can also can support something already posted.
We would love to be able to respond to every idea that is submitted, but this is not feasible. We are, however, committed to responding to the most popular ideas—those that have received the most points.
For more information please review our FAQ and guidelines. Thank you.
- or
4 results found
-
Include the item barcode as part of the data published from Alma to Primo in the AVA field to improve item search in Primo
Request for Alma item barcode be included in the data that is published to Primo as part of the Alma publishing functionality to enable barcode searchability in the Primo keyword search. We have discovered that items migrated from our previous ILS do contain the item barcode(s) in the MARC 945 $$i and is written to the search:general field of the PNX. As such, those items are keyword searchable via their barcode in Primo. However, for items created in Alma, the item barcode is not written to the bib record and is therefore not searchable in Primo. Adding the item barcode manually to the bib 945$$i for each item as part of our processing is not a viable alternative.
We would like an enhancement to Alma publishing that would add the item barcode to the data published in the "AVA" field. This functionality would improve workflow for staff when they need to search a record in Primo without having to navigate out of the items screen in Alma to retrieve the OCLC number, the MMSID or the ISBN, or to pull up the record in Primo when the book is in-hand without needing to key in the title or ISBN.
Examples of migrated records with the item barcode in the 945 $$i:
http://alliance-primo.hosted.exlibrisgroup.com/CC:cc_alma:CP71153242760001
http://alliance-primo.hosted.exlibrisgroup.com/CC:cc_alma:CP71188416360001451Request for Alma item barcode be included in the data that is published to Primo as part of the Alma publishing functionality to enable barcode searchability in the Primo keyword search. We have discovered that items migrated from our previous ILS do contain the item barcode(s) in the MARC 945 $$i and is written to the search:general field of the PNX. As such, those items are keyword searchable via their barcode in Primo. However, for items created in Alma, the item barcode is not written to the bib record and is therefore not searchable in Primo. Adding the item barcode…
465 votes -
Less duplicate records in Primo Central Index results
Primo Central grouping is based on the existing FRBR workflow, including the grouping process at the database level (the way the Search engine handles grouping) and the Front End functionality. It is used to prevent duplicate records in the results list.
Unfortunately, many records are not added to FRBR groups because the system considers the metadata are not rich enough. With the increase of records provided by (Open Access) aggregators and repositories, the number of duplicate records will certainly not decrease.
Could Ex Libris improve the FRBR workflow for Primo Central records in order to reduce the number of duplicate results and consolidate the FRBR groups?
Examples of duplicate records:
Accuracy of prediction of gene content in large animal populations and its use for candidate gene detection and genetic evaluation
3 results (2 FRBR groups):
- TNproquest195858157 and TNfaoagrisUS201300875183
- TNcrossref10.3168/jds.2007-0231, TNscopus2-s2.0-42449094585, TNsciversesciencedirectelsevierS0022-0302(08)71293-1, TNmedline18349258
- TNorbi2268/23076Linguistic symbiosis between event loop actors and threads
2 results (1 FRBR group):
- TNsciversesciencedirectelsevierS1477-8424(08)00024-9
- TNscopus2-s2.0-51649125887 and TNcrossref10.1016/j.cl.2008.06.005Efficient control of transient wave forms to prevent spreading depolarizations
2 results (1 FRBR group):
- TNarxiv0705.3398
- TNscopus2-s2.0-39649117125, TNsciversesciencedirectelsevierS0022-5193(07)00579-6, TNcrossref10.1016/j.jtbi.2007.11.019, TNmedline18177900Le traitement de la modalité épistémique dans les traductions françaises de On the Origin of Species de Charles Darwin
3 results:
- TNerudit1038687ar
- TNscopus2-s2.0-85017546223
- TN_proquest1870219718Primo Central grouping is based on the existing FRBR workflow, including the grouping process at the database level (the way the Search engine handles grouping) and the Front End functionality. It is used to prevent duplicate records in the results list.
Unfortunately, many records are not added to FRBR groups because the system considers the metadata are not rich enough. With the increase of records provided by (Open Access) aggregators and repositories, the number of duplicate records will certainly not decrease.
Could Ex Libris improve the FRBR workflow for Primo Central records in order to reduce the number of duplicate
…203 votesHi all,
We are moving this idea to "Closed" to release your votes, as it is no longer relevant with CDI.
Best regards,
Yael.
-
Ensure that CZ & CDI Metadata is Linked Data Ready
I was advised by the Linked Data Group to post this idea here because I submitted the following for the LOD Working Group webinar in December:
Broader strategic and commercial alliances required to ensure that data is ready to be linked?
To engender confidence in CZ and make it linked-data ready, why don’t the Company do business with e.g. Backstage Library Works for authority control clean-up and maintenance?
Metadata is a global commodity so all stakeholders have responsibility for creating, sharing, enriching and maintaining it, and of course there are costs for all of these elements which we could share.
Isn’t this the best way to ease the burden on libraries and leverage our metadata improvements for mutual and sustainable benefit?
I note that this document alludes to the Company taking a lead in creating a new open metadata platform and preserved data in an open format.
https://knowledge.exlibrisgroup.com/Alma/Product_Materials/010Roadmap/Linked_Open_DataPreserving metadata is not the same thing as maintaining it because metadata evolves e.g. authorities are deleted, changed and new ones created.
In light of this I would ask that the Company explore strategic commercial partnerships to ensure that any metadata that they manage (knowledgebases, platforms) is properly maintained.
Jane
I was advised by the Linked Data Group to post this idea here because I submitted the following for the LOD Working Group webinar in December:
Broader strategic and commercial alliances required to ensure that data is ready to be linked?
To engender confidence in CZ and make it linked-data ready, why don’t the Company do business with e.g. Backstage Library Works for authority control clean-up and maintenance?
Metadata is a global commodity so all stakeholders have responsibility for creating, sharing, enriching and maintaining it, and of course there are costs for all of these elements which we could…
16 votes -
Allow multiple custom CSS stylesheets per view
At the Digital Theological Library, we have multiple campuses, each of which has its own view. All of the views use the same basic custom design, but each one needs its own specific CSS tweaks. Maintaining this would be much simpler if all of the views could have two custom CSS files: one with the basic design rules and one with the specific design tweaks. That way, when the base design is updated, the view-specific CSS can't accidentally be disturbed by copying and pasting within a single stylesheet, and Primo UI managers like me won't need to copy and paste across all of our views in the first place. The view-specific stylesheet would need to be listed after the main CSS in the <head> of the page to avoid incorrect cascading.
Another option that would be even easier to use from my perspective but would probably be harder to implement would be to have a set of system-wide view styles that could then be overridden with individual custom.css stylesheets. Either solution would greatly improve my workflow for maintaining multiple views and would also benefit other Primo institutions with multiple campuses or customized views.
At the Digital Theological Library, we have multiple campuses, each of which has its own view. All of the views use the same basic custom design, but each one needs its own specific CSS tweaks. Maintaining this would be much simpler if all of the views could have two custom CSS files: one with the basic design rules and one with the specific design tweaks. That way, when the base design is updated, the view-specific CSS can't accidentally be disturbed by copying and pasting within a single stylesheet, and Primo UI managers like me won't need to copy and paste…
3 votes
737 results found
-
Make the Resource Recommender initial expand/collapse display configurable
In NDE, the Resource Recommenders (Recommendations) area can be collapsed/expanded. By default, the display is expanded, and the user can collapse it. We would like the option to display the area collapsed by default, allowing the user to expand it only if they want to see the recommendations. The justification is that the Resource Recommenders area takes up a good deal of space and many users would prefer to get directly to searching. A collapsed default display would present a more streamlined search experience. Institutions can opt to "expand by default" or not the different areas in Full Record Services, and we would like to see this configuration option for the Resource Recommenders (Recommendations) area, as well.
In NDE, the Resource Recommenders (Recommendations) area can be collapsed/expanded. By default, the display is expanded, and the user can collapse it. We would like the option to display the area collapsed by default, allowing the user to expand it only if they want to see the recommendations. The justification is that the Resource Recommenders area takes up a good deal of space and many users would prefer to get directly to searching. A collapsed default display would present a more streamlined search experience. Institutions can opt to "expand by default" or not the different areas in Full Record Services,…
1 vote -
Allow configuration of the default expanded/collapsed state of facets in Primo NDE
In Primo NDE, we would like administrators to be able to configure the default expanded or collapsed state of individual facets in the All Filters panel.
Currently, the location_code facet is automatically expanded whenever the All Filters panel is opened.
There is no supported configuration option to control the default state of individual facets.
We suggest adding a configuration option that allows administrators to define, for each facet, whether it should be:
expanded by default
collapsed by defaultIdeally, this could be configured at view level together with the other facet settings.
3 votes -
create a book showcase without logging into Primo
It would be helpful if the book showcase could use a search/set from Alma, a collection ID, or a search URL from Primo, rather than a Primo saved search. We are not able to log into Alma with the same accounts we use in Primo.
1 vote -
Rank records within FRBR group by relevancy to search terms (not just highlight one preferred record)
Description:
This is a follow-up to a previously "completed" idea: "Relevancy sorting in FRBR version list display should use terms searched" (209 votes). That idea was addressed only for Preferred Record mode, by highlighting a single matching record at the top of the version list. We don't think this fully solves the underlying problem, in either display mode.
The problem:
A FRBR group can contain several records that are all relevant to the user's original search terms. For example, multiple translations by the same translator, or several relevant editions.
In Generic mode, opening the group shows an unranked list of all versions. Relevant matches can be buried many pages deep, with no connection to the original search.
In Preferred Record mode, the fix implemented only surfaces one matching record. This can make the problem less visible: a user sees one confidently displayed match and has no indication that 2-3 more equally (or slightly less) relevant versions exist inside the group. It looks solved, but the ranking problem is just hidden rather than fixed.
Grouping records according to FRBR principles in general is good and something we want to keep recommending to our institutions. However, if it negatively affects users’ attempts to reach a known item or semi-known items by placing these unintuitive roadblocks in their way, it is not good enough. In many cases, the user would be better off if the search had never been FRBR’ized.
The proposed solution:
Rank/sort the records within the FRBR group itself by relevancy to the original search terms, in both Generic and Preferred Record display modes. That way, the user will immediately spot the relevant results after opening the FRBR group but will still enjoy the benefits of a less cluttered initial results list.
Example:
Searching "Iliad Richmond Lattimore" returns a FRBR group for Homer's Iliad. Opening the group should surface Richmond Lattimore's translations at or near the top based on its relevance to the search the user made, not require paging through many unrelated editions/translations to find them.
We hope that you will vote for this suggestion! Feel free to add other examples in the comments below.
-The BIBSYS-consortia
Description:
This is a follow-up to a previously "completed" idea: "Relevancy sorting in FRBR version list display should use terms searched" (209 votes). That idea was addressed only for Preferred Record mode, by highlighting a single matching record at the top of the version list. We don't think this fully solves the underlying problem, in either display mode.
The problem:
A FRBR group can contain several records that are all relevant to the user's original search terms. For example, multiple translations by the same translator, or several relevant editions.
In Generic mode, opening the group shows an unranked list of…
180 votes -
Add the option to create a Primo AI Research Assistant search box
Add the option to create a Primo AI Research Assistant search box. Our library would like to create a Primo AI Research Assistant search box on our homepage. We were told this is not possible due to authentication issues and the lack of deep linking.
1 vote -
DOI autofill on the Book Chapter request Resource Sharing form
We would like a DOI autofill feature for Book Chapter requests on the stand-alone Resource Sharing form on Primo NDE.
This already exists on the Article request RS form.3 votes -
Display the resource types filter bar in Primo NDE advanced search results
In the pre-NDE UI of Primo VE, the resource types filter bar was displayed inside the basic search bar at the top of the page, just under the search term input field. It functioned primarily as a pre-search filter. As such, it made logical sense that one wouldn't see the filter bar after conducting an advanced search.
But in NDE, the filter bar appears just above the search results. It only shows up once the results have loaded, so it's only possible to use it as a post-search filter. Despite this difference of use in NDE, the resource types filter bar only displays above search results when a basic search is conducted. It's absent when an advanced search has been conducted. This is confusing our users because while they expect a different search form for advanced search, they don't expect the results display to lack a familiar feature.
As I understand it, the resource types filter bar did at one time display in NDE, but it was removed because it was causing problems. I don't know the nature of those problems, but if they could be resolved and the filter bar returned to the advanced search results display, it would improve the user experience greatly.
In the pre-NDE UI of Primo VE, the resource types filter bar was displayed inside the basic search bar at the top of the page, just under the search term input field. It functioned primarily as a pre-search filter. As such, it made logical sense that one wouldn't see the filter bar after conducting an advanced search.
But in NDE, the filter bar appears just above the search results. It only shows up once the results have loaded, so it's only possible to use it as a post-search filter. Despite this difference of use in NDE, the resource types filter…
27 votes -
Hold and Booking Request Form Needs More Customization
The Hold and Booking Request Form should have more customization options or branching logic to help libraries that have multiple branches.
For example, we have a main library and three branch libraries that are all on the same Primo discovery (we also have a law library that is on their own Primo). Our main library branch got book lockers last year for our users so they can easily pick up their holdings. However, user services noticed that some patrons were struggling to access higher or lower lockers. They asked if we could have a check box on the holdings request form to indicate that they want a more accessible locker. However, we ended up finding a couple of issues with this request.
1.) Due to the way the form is built, it is all or nothing. Our Fine Arts Library does not have lockers, so the check box appears when users select their library for book pickup, even though they don't have lockers. We worry that this will cause some confusion for both the users and the branch libraries (see image below). Ideally, the form should be able to change based on the chosen location.
2.) The verbage from the check box appears along with additional comments made by the requester. When we receive the request, everything is jumbled into the request notes field, making it messy, and quite frankly, a little ugly. 😆 (see image below)
If even one of these changes could be made, that would be amazing!
The Hold and Booking Request Form should have more customization options or branching logic to help libraries that have multiple branches.
For example, we have a main library and three branch libraries that are all on the same Primo discovery (we also have a law library that is on their own Primo). Our main library branch got book lockers last year for our users so they can easily pick up their holdings. However, user services noticed that some patrons were struggling to access higher or lower lockers. They asked if we could have a check box on the holdings request…
3 votes -
Allow Journal Categories to be Expanded by Default
Currently the categories on the Primo Journal search page show parent categories that must be expanded manually to see the nested categories (i.e. Social Sciences > Education). It would be helpful if all categories could be expanded by default or certain categories could be made more prominent if they are relevant to our library's population.
Thank you for considering this idea.
3 votes -
Enable users to select records from multiple pages of results
Currently if a user selects a few records from a page of results and then navigates to the next page they lose their record selection. This idea is to enable users to navigate through their results list, page by page selecting records as they go and then when finished complete the desired action on the selected records.
3 votes -
Add navigation to the top of the search results
Currently users need to scroll down the full page of results before being able to move to the next page of results. This becomes laborious if users have chosen to display 25 or 30 results per page.
3 votes -
Research Assistant
For AI declarations, it has become standard now for lecturers to ask their students for a chat link as proof of using an AI tool at a certain time.
It is currently not possible to share a chat link from a Primo Research Assistant search session. Please can the functionality of creating and sharing a chat link from a session be added.
4 votes -
Allow multiple custom CSS stylesheets per view
At the Digital Theological Library, we have multiple campuses, each of which has its own view. All of the views use the same basic custom design, but each one needs its own specific CSS tweaks. Maintaining this would be much simpler if all of the views could have two custom CSS files: one with the basic design rules and one with the specific design tweaks. That way, when the base design is updated, the view-specific CSS can't accidentally be disturbed by copying and pasting within a single stylesheet, and Primo UI managers like me won't need to copy and paste across all of our views in the first place. The view-specific stylesheet would need to be listed after the main CSS in the <head> of the page to avoid incorrect cascading.
Another option that would be even easier to use from my perspective but would probably be harder to implement would be to have a set of system-wide view styles that could then be overridden with individual custom.css stylesheets. Either solution would greatly improve my workflow for maintaining multiple views and would also benefit other Primo institutions with multiple campuses or customized views.
At the Digital Theological Library, we have multiple campuses, each of which has its own view. All of the views use the same basic custom design, but each one needs its own specific CSS tweaks. Maintaining this would be much simpler if all of the views could have two custom CSS files: one with the basic design rules and one with the specific design tweaks. That way, when the base design is updated, the view-specific CSS can't accidentally be disturbed by copying and pasting within a single stylesheet, and Primo UI managers like me won't need to copy and paste…
3 votes -
Improve Database material type assignment in a Network Zone Consortia
Problem description
In a Network Zone consortium, bibliographic records are shared across all member institutions. Currently, the "Database" material type in Primo VE is assigned to a bibliographic record whenever that record is linked as the descriptive/display record for any Electronic Collection with a populated Level URL. This includes Local Electronic Collections created by a single member institution in their own Institution Zone.
Because the underlying bibliographic record is shared in the NZ, this single institution's local configuration choice changes the material type of the record for every institution in the consortium, even though only one institution actually intended the title to function as a database entry. This creates a situation where a shared title (e.g. a journal) can unexpectedly display under "databases" instead of its correct material type in another institution's discovery layer, with no clear explanation available to that institution.
Impact
Member institutions have no visibility or diagnostic tool to determine why a shared title unexpectedly displays with the wrong material type. A single institution's local Electronic Collection setup can silently override discovery behavior for the entire consortium, with no warning, log, or notification to affected institutions.
Troubleshooting is currently difficult. Only the consortium's network administrators have a way to identify the source, but it requires checking every library that has the record in their IZ.
Suggested improvement
We would like Clarivate to investigate ways of making this behavior more transparent and manageable in an NZ consortium setting. One option would be through better visibility into cross-institution record usage, or some form of notification when a shared record's material type is affected by another institution's configuration. An even better solution would be to change the underlying approach to how the "Database" resource type is determined for shared NZ records in a way that would let each IZ control the behaviour in their own IZ. Such a solution would increase the customizability of the database list for each individual IZ without risking resource type contamination across the consortia.
Problem description
In a Network Zone consortium, bibliographic records are shared across all member institutions. Currently, the "Database" material type in Primo VE is assigned to a bibliographic record whenever that record is linked as the descriptive/display record for any Electronic Collection with a populated Level URL. This includes Local Electronic Collections created by a single member institution in their own Institution Zone.
Because the underlying bibliographic record is shared in the NZ, this single institution's local configuration choice changes the material type of the record for every institution in the consortium, even though only one institution actually intended the…
150 votes -
show notice in GetIt when patron is blocked from requesting
This is also CERV PENH-I-28495.
Currently, users with item or global blocks can have their request permissions removed, and the physical and digital request buttons for local materials can be hidden (similar to Rapido for resource-sharing requests). Rapido allows users to communicate a reason why they might not be able to make a request. We believe we should display a similar HTML-based message/banner for requesting local materials, without needing interface customization.
This follows the design principle of "instruction at the point of need". We have had patrons with blocks think that items are not requestable when they are, but just not to them. The goal is to encourage patrons to resolve their blocks, not just keep them from requesting more. Ideally, request buttons should be made inactive rather than hidden, as this would indicate the request status of the item/title while still communicating to the patron that there is an issue with their library account.
This is also CERV PENH-I-28495.
Currently, users with item or global blocks can have their request permissions removed, and the physical and digital request buttons for local materials can be hidden (similar to Rapido for resource-sharing requests). Rapido allows users to communicate a reason why they might not be able to make a request. We believe we should display a similar HTML-based message/banner for requesting local materials, without needing interface customization.
This follows the design principle of "instruction at the point of need". We have had patrons with blocks think that items are not requestable when they are, but just…
6 votes -
Priority of pickup locations
We would like to have the possibility to set the order of pickup locations. Now the owning library is always on the first place. We would appriciate the possibility to put other pickup location at the firt place intead of the owning library e.g. the library box as the first possibility to pickup the resource.
6 votes -
Separate the success message labels for resource sharing requests and hold requests
Currently, both resource sharing requests and hold requests use the same label, nui.request.success, after a request has been successfully submitted. As a result, the same message is displayed for both types of requests.
We would like to have a separate success message label for resource sharing requests, distinct from the one used for hold requests. This would allow us to display different messages for the two types of requests and provide patrons with specific reminders or instructions regarding each service.
4 votes -
Support searching by index in Collection Discovery
In Collection Discovery, users can sort items by Relevance, Date-newest, Date-oldest, Title, and Author, but they are unable to search by these indexes. This affects the user's ability to retrieve specific and known-items in a precise way. The existing "search" option functions based purely on keyword across all data fields (including full text).
Users need access to specific index searching for full use of Collection Discovery, especially the Title index.
5 votes -
Lateral linking for uniform titles
Please let us add lateral links for uniform titles.
This seems to have been possible in Primo BO: https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/Primo/Highlights/026Primo_November_2017_Highlights#Enhanced_Hypertext_Linking
"Hypertext linking has been extended to the following PNX display fields: [...] unititle [...]."I attach our display rules to show which fields to include.
For search: hypertext links
11 votes -
Add alert to User Area (NDE) - My Library Activity for requests awaiting collection
The addition of an alert to the My Library Activity page of the User Area of Primo NDE when a request(s) is waiting collection by the user would be a welcome addition to this area. Please see attached document detailing how this proposed feature could appear.
1 vote
- Don't see your idea?