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
No existing idea results
- ~ No ideas found ~
651 results found
-
Change CDI handling of Language data for Primo
CDI Language data in handled in ways which have undesirable impact on patrons in Primo, such as:
• A default language is applied to all records in a CDI feed for use in Primo in the Language field display, search, and facet. This may be done when the CDI provider feed has no record-specific Language information available automatically and the provider has not otherwise advised that all the records are in a specific known language and confirmed that this Language can be applied to the records in CDI
• Records may be allowed to merge into a CDI logical record even when the Language data differs across participant records. All of the participant record Language values are then included in the Language facet bar ‘outlier’ languages stripped out, and then one Language value may be selected to display in the record according to library full text activations, even if it contradicts the Language facet valueIt is understood that the CDI is a massive index and that strategies such as collection level normalisation rules are necessary in order to manage this scale of data.
However, it is feared that the experience of individual users is inappropriately de-prioritised and lost in these decisions focused on “acceptable” percentages of impact, which may seem tiny relative to the size of the index, but may be significant to actual people using our discovery layer.
The practical reality is that such handling of Language information at a broad scale in CDI causes a negative impact for people using Primo, as the information is clearly incorrect and features cannot be used as expected.
It may be argued that patrons are unlikely to encounter such issues on a regular basis, but this also ignores common knowledge of human nature that even one or two experiences of being presented with clearly false information is enough to build distrust in all future experiences.For example, the Language facet cannot be used when a patron is specifically trying to target results in a certain language, when they know in advance or learn from initial results that their search term may return records for multiple languages with different meanings.
ISSUE
“Persona” has different meanings in Spanish and English and the patron wants the English variation.
STRATEGY
With a search by “personas school principals” the patrons deliberately selects to include only the Language facet value of English and exclude the Language facet value of Spanish.
BUT
Ex Libris has applied Language facet value of English broadly as a default in the CDI provider feed and/or has artificially selected a Language from participant records to display in the record regardless of the Language in the facet.
RESULT
The patron sees in their results many records stating English when they are clearly in Spanish in both the metadata and full text.
Examples (screenshots attached):
• cdicrossrefprimary105944reopvol30num1201925194
• cdiunpaywallprimary1014295idonlinev15i583330
• cdijstorprimary_40654076
OUTCOME
This patron may then submit a complaint to the library or simply decide that their library provides a poor service and stops using our discovery layer in favour of other options.When opening a case to report such patron complaints with examples of unexpected incorrect information in Primo, it is advised that this behaviour is expected and that current handling was chosen over other options to mitigate the impact of insufficient provider CDI metadata in Primo.
This could be by including a Language information in the records of ‘No linguistic content’ or ‘Undetermined’ to ensure a facet count matched to a result count, not allowing records to merge when there are Language differences, and not presenting Language facet values which do not match Language display values.Ex Libris considers it a “resolution” to such cases for defect reports to document this behaviour, shifting responsibility to their library customers to explain to complaining patrons.
This approach focusing on quantity over quality does not centre the individual user as a person, and disregards the harm to the professional reputation of libraries, degrading the trust our patrons place in our services and which we are responsible to provide for our institutions, to support teaching, learning, and research.
Now that such behaviours have been documented over time as “expected”, this issue moves from hope it is resolved as a defect, to a product enhancement request that Ex Libris change the current design decisions causing this problem.
This submission requests that Ex Libris reconsider and change these practices with the individual user in mind, committing to align Language data across display, search, and facets and to consistently present only accurate Language information in the Primo discovery layer.
CDI Language data in handled in ways which have undesirable impact on patrons in Primo, such as:
• A default language is applied to all records in a CDI feed for use in Primo in the Language field display, search, and facet. This may be done when the CDI provider feed has no record-specific Language information available automatically and the provider has not otherwise advised that all the records are in a specific known language and confirmed that this Language can be applied to the records in CDI
• Records may be allowed to merge into a CDI logical record…1 vote -
Improve Primo linking to limit dead/inaccurate links
To prevent user confusion, frustration, and access delays, we would like Ex Libris' Primo to mirror a feature that LibKey calls "Entitlement Confirmation," which would help prevent delivering dead links to end users, especially when Metadata in the CDI is lacking or incorrect.
Delays between publishing and availability, especially with third-party databases (like EBSCOHost), happen often and can vary in length due to the nature of aggregation. The proposed change would confirm if content is available before indicating to end users that it is. This saves user and staff time and effort, streamlining the process and managing expectations while providing exemplary service.
To prevent user confusion, frustration, and access delays, we would like Ex Libris' Primo to mirror a feature that LibKey calls "Entitlement Confirmation," which would help prevent delivering dead links to end users, especially when Metadata in the CDI is lacking or incorrect.
Delays between publishing and availability, especially with third-party databases (like EBSCOHost), happen often and can vary in length due to the nature of aggregation. The proposed change would confirm if content is available before indicating to end users that it is. This saves user and staff time and effort, streamlining the process and managing expectations while providing…
20 votes -
Disabling automatically generated links for related records if the associated NR is disabled.
Primo VE is capable to automatically create links to related records via MARC 7xx fields.
As these links where not working well for us, we were looking to turn them off with a NR, by setting “set pnx."display"."relation" to "N/A"” for 776 specifically.
Unfortunately, this turned out not to work in all cases. As Ex Libris explained this is because
- in the related records, they differentiate between child records and parent records
- for child records, as the specific relation field is included, Display NR takes effect
- for parent records, as the specific relation field is not included, and the opposite link is added automatically, Display NR cannot have any effectThis means we can only disable links from child to parent records but not the other way around. What we would like to see is that, if a relation from a child to a parent record is supressed, the automatically added opposite link should also be supressed.
Primo VE is capable to automatically create links to related records via MARC 7xx fields.
As these links where not working well for us, we were looking to turn them off with a NR, by setting “set pnx."display"."relation" to "N/A"” for 776 specifically.
Unfortunately, this turned out not to work in all cases. As Ex Libris explained this is because
- in the related records, they differentiate between child records and parent records
- for child records, as the specific relation field is included, Display NR takes effect
- for parent records, as the specific relation field is not included,…88 votes -
NZ/IZ linking in consortia
Background: MARC 776 is used to establish a link between related records (Also available in another form:). If a link cannot be established, a title search is started instead.
In a consortial environment, there is an issue with this: Primo VE is only able to establish a link if both the linking and the linked-to title are available locally. This happens because Primo depends on Alma functionality for related records to establish a link and Alma is building them within institution scope only (Network is considered just another institution in this regard). This means that as soon as only the linking title is available in an IZ, a title search will be started.
To give an example: We have a journal with the main title “Recht” (Law), which links to an electronic version of the same title. In IZ that do not have the electronic version, a title search for Recht/law will be started instead, leading to over 27’000 results – from a link that promised to lead to a different version of the same title. See also pdf below.
This behaviour makes 776 largely unusable for consortia, where it would be important for that our patrons are able to find resources that are not available locally as well or where we’d at least want a system that can recognize if something is locally available and only displays the link in this case.
Background: MARC 776 is used to establish a link between related records (Also available in another form:). If a link cannot be established, a title search is started instead.
In a consortial environment, there is an issue with this: Primo VE is only able to establish a link if both the linking and the linked-to title are available locally. This happens because Primo depends on Alma functionality for related records to establish a link and Alma is building them within institution scope only (Network is considered just another institution in this regard). This means that as soon as only the…
144 votes -
Author/Title Index in Browse Search
Author/Title Index in Browse Search
Please include an Author/Title index which searches headings combining author/creator name and uniform title. The index usually includes:
* 100/240
* 110/240
* 111/240
* 700 where $$t is present
* 710 where $$t is present
* 711 where $$t is present
* 800 where $$t is present
* 810 where $$t is present; and
* 811 where $$t is present59 votes -
PressReader
PressReader uses Webhook functionality to enable direct search of its content within Primo VE.
In Brief Search Results the link displays as "check for available services'. This is not configurable (Salesforce #07245690).
In the Full Record Screen the default text 'Link to Resource' is used.
This is sourced from Links and General Electronic Services Labels.
Can there please be a separate label, created specifically for PressReader, with text configurable by the library?
Screenshots attached
Thank you!
3 votes -
Add ability to display item status in locations list in Get It section
Currently, the locations list displays a holdings summary for each location. To view the status of held items, users must click into each location's details. It would streamline the user journey if the item status (item in place, on loan, on order, etc.) could be displayed within the locations list itself, in addition to the holdings summary.
1 vote -
Suppress blank yellow box in "View It" section
Currently, when there are no online access links in the "View It" section on the full details page, a blank yellow box appears. Can this be suppressed when there are no links to display?
We receive numerous problem reports each year from students who are confused. Thank you!
3 votes -
Influence the algorithm in the display format for hits on large broad subject searches where local repository records appear.
In our library we have decided that Primo should also display records from a local repository. This is a database of references to research publications produced by our researchers at our university. It is not always the case that we have electronic access to the titles in this local database. And it's not always the case that we own the physical works.
So we would like to have the titles in our catalogue, but we are well aware that at best they are reference titles that have to be obtained/borrowed.
We are planning to display more local repositories through our Primo (students' theses and the like).It would actually be super user friendly if we could influence the algorithm in the display format for hits on large broad subject searches where local repository records appear.
Namely, that your own repositories that are available to Primo can be both prioritised and, most importantly, deprioritised in the display format.So we want to propose the idea that each individual library can control the display of its own local small repositories in Primo.
In our library we have decided that Primo should also display records from a local repository. This is a database of references to research publications produced by our researchers at our university. It is not always the case that we have electronic access to the titles in this local database. And it's not always the case that we own the physical works.
So we would like to have the titles in our catalogue, but we are well aware that at best they are reference titles that have to be obtained/borrowed.
We are planning to display more local repositories through our…9 votes -
Make "Subject is(exact)" a precision search that returns results based on exact subjects
Currently in legacy Primo, a Subject is(exact) search returns items that do not have the specified terms in the visible records, but returns matches from the CDI metadata that is not presented in the record. For clarity of functionality, returning only results that include the specified terms would be preferable. (Similar to NERS 8871 which was focused on the Title fields.)
(An alternative would be to increase transparency of results so that the CDI metadata that constitutes a match is visible to end users.)
1 vote -
Prioritize library locations based on the active library view?
Configure PrimoVE to prioritize library locations based on the active library view? Display the location or locations that belong to the library view first in the result list
6 votes -
Ability to add fields to request forms
Hi team,
I am Chandan from the University of Tasmania and we recently got our Ex Libris systems. One thing we noticed while working with request forms was that there was no way to add or change the fields on request forms such as purchase request, hold request etc. It would be really good if we could do that! We currently require fields such as location and number of units in the purchase request form to better track the request for the submitter.
Thank you
Regards,
Chandan
Library Systems Administrator
UTAS22 votes -
Add a “Scholarly” Search Results Facet
Adding a "Scholarly" search results facet to Primo VE or the future NDE, in addition to the existing "Peer-Reviewed" facet, would be beneficial, similar to Summon's “Scholarly & Peer-Reviewed” facet.
Not all peer-reviewed articles are scholarly, so having both facets would enable users to refine their searches according to their specific needs.
This shouldn’t require huge effort since Summon is also an Ex Libris product, and resources for implementation should be readily available.
14 votes -
Change newspaper indexing from weekly to daily
The CDI indexes newspaper content, like Proquest Newsstream, once a week. We would like to see newspaper specific content, that have daily issues updated in Primo on a daily basis. Patrons conducting newspaper searches in Primo report missing content, but need to redirect them to the individual databases for daily news.
1 vote -
Sort by date for Primo favourites - option to change sort order (newest / oldest)
We would like to be able to change the sort order (newest / oldest) when sorting by date in Primo favourites.
3 votes -
Display only the last entered Date Range facet
When a person refines a date a second time in Primo, Primo simply displays an additional date facet in the Active Filters area. For example, a person initially filters a search to Years: 1919-2025 and then decides to filter again by Years: 2024-2025. Instead of removing the first date facet and replacing it with the second, Primo simply adds the second facet underneath the first facet. This does not make sense and presents a usability problem for the end user. In all other cases, when two facets are used within the same category, they are to be regarded as having an OR Boolean between them. (Example: Books OR Articles) But in this case, the user does not want DateRange1 OR DateRange2. Their date range should be REFINED (i.e., changed/updated), as the button implies. And this is indeed what the Refine Date functionality does in actuality; it reruns the search according to the latest Date Range entered by the user. It does not run a search with the multiple Date Ranges combined by an OR Boolean. Therefore, please display only the last Date Range facet as entered by the user to match the Refine Date functionality and increase usability within the system.
When a person refines a date a second time in Primo, Primo simply displays an additional date facet in the Active Filters area. For example, a person initially filters a search to Years: 1919-2025 and then decides to filter again by Years: 2024-2025. Instead of removing the first date facet and replacing it with the second, Primo simply adds the second facet underneath the first facet. This does not make sense and presents a usability problem for the end user. In all other cases, when two facets are used within the same category, they are to be regarded as having…
3 votes -
Link Authorities in BIB Records to Local Authority Search Records
Current Situation: Local authority search allows patrons to search for authorities and obtain a list of BIB records to which they are connected. However, it is not possible to navigate from an authority in a BIB record to the local authority record in Primo.
Proposed Change: Enable navigation from an authority in a BIB record to the corresponding local authority record in Primo.
4 votes -
Enable Custom Configuration of Primo Normalization Rules for Local Authority Search
Current Situation: Local authority search records are currently displayed with hard-coded normalization rules (NRs).
Proposed Change: Allow users to configure Primo normalization rules for local authority search. This flexibility will enable us to normalize authority records and display fields according to our specific needs.
128 votes -
full text
Currently "full text" is limited to first 65K characters of an article or of a complete [!] book (along with chapter abstracts only) from CDI, or even less from Alma, and not from all sources (e.g., not from JSTOR). Thus tweak results to full text is misleading. For articles, entering from google scholar may circumvent the problem partially. For books, true research now requires search full text (possibly not available or only available in snippet view) in google books for finding the required source and pages, then searching the discovery for the book for electronic access, similar to finding a physical book.
True full text is strongly required.Currently "full text" is limited to first 65K characters of an article or of a complete [!] book (along with chapter abstracts only) from CDI, or even less from Alma, and not from all sources (e.g., not from JSTOR). Thus tweak results to full text is misleading. For articles, entering from google scholar may circumvent the problem partially. For books, true research now requires search full text (possibly not available or only available in snippet view) in google books for finding the required source and pages, then searching the discovery for the book for electronic access, similar to finding a…
3 votes -
"Peer reviewed" for academic books
Currently, there is a limiter in discovery to "Peer-reviewed articles" but using this limiter does not bring results from books even by the most celebrated academic publishers. While this information arrives from vendors, there should be a way to search peer-reviewed publications that would exclude magazines but include both peer-reviewed journals and books (or book chpaters) by any academic press.
3 votes
- Don't see your idea?