Round One Primo Enhancements 22-23

Consistent order of multi-lingual values in author/topic facets (VE/BO)

VE/BO

When the authority-based facets author/topic are in several languages/alphabets (English, Hebrew, Arabic, Cyrillic) and the facets are sorted by size, the sort of the facets with the same number of hits shows no logic or consistency (see https://tinypic.host/i/ideaexchange.JVHbg ). Multi-lingual values of the same authority should be clustered so that terms that mean the same thing will be grouped and displayed in the language-determined order. The display order of the different languages/alphabets should be determined per view. 

When several multi-lingual terms (facet values) have the same number of hits, they should be grouped so that each "cluster" will be considered one value to be sorted in the facet. Example of the suggested display in the facet (four different terms):

• Hebrew term1 (100)

• Arabic  term1 (100)

• Latin  term1 (100)

• Cyrillic term1 (100)

• Hebrew term2 (100)

• Arabic term2 (100)

• Latin term2 (100)

• Hebrew term3 (95)

• Latin term3 (95)

• Hebrew term4 (87)

• Arabic term4 (87)

• Latin term4 (87)

• Cyrillic term4 (87)

the main sort if by the number of hits (by size), the secondary sort is by the same "thing" (authority), and the third sort is by the pre-determine languages/alphabet order (in this case: Hebrew, Arabic, Latin, Cyrillic).

Provide option to 'View All' authors in the author facet (VE/BO)

VE/BO

After performing a search, users sometimes want to filter by an author that does not appear in the top 20 most frequently returned. We would like to provide users with the option to view and browse all authors returned in the search results. A 'View All' link at the base of the facet could be added to enable this. Our default search includes both CDI and institutional records 

Enable users to send an enquiry about an existing resource sharing request from My Library Account to a tasklist in Alma (VE/BO)

VE/BO

Currently if users have an enquiry about their resource sharing request they have to contact us separately via email or phone. Since they can see their current requests in My Library Account, it would be great if they could click on an option e.g. 'Send an enquiry about this request' in My Library Account, enter in their query, and Submit. This would then populate a tasklist in Alma (similar to Notes functionality in Leganto/Alma Course Reserves) that resource sharing staff could action and reply to. This would bring this communication workflow into Alma and improve efficiency and reduce email back and forth. 

Enable authorized staff to view Primo UI as a patron (VE/BO)

VE/BO

Enable staff users with appropriate permissions (for example 'Discovery - Administrator' role in Primo VE and Administrator in Primo Back Office) to toggle between how patrons belonging to different User Groups see the Primo user interface. 

When staff make changes to any functionality that is conditional according to patron User Group.

When testing configuration changes to Alma and Primo, we often need to check how the Primo VE user interface appears to patrons of different User Groups.  At the moment, this requires altering our own user groups in Alma multiple times and going back into Primo to check, or having multiple dummy patron records and using them to log in and out repeatedly.  This is time-consuming and involves a risk that staff will forget to change their User Group back to 'Staff'.

Extend lateral links for Relation, Is Part Of, and Uniform Title beyond local records (VE/BO)

VE/BO

Clickable lateral links for the ispartof, relation, and unititle fields were introduced in 2017, for NERS #5291 as part of "Enhanced Hypertext Linking". These new fields joined existing lateral links for creator, contributor, and subject. However, a key difference for the three newer fields is that they are only clickable lateral links for local records and while they are found displayed in CDI records, they are not clickable. The restriction of some lateral links to only local records causes confusion, with questions as to why some records are missing these links, which lead so helpfully into Advanced Search showing all records with this data in one cohesive results set. This is a disappointing inconsistency in our blended scope environment, especially when we see through our Primo Analytics data that lateral links are a popular feature, with thousands of clicks every week. An example use case are Relation fields for works in a series, where there may be local book records and book chapter records from CDI (example: Advances in Biochemical Engineering/Biotechnology). The outcome of this enhancement request would be for the Relation, Is Part Of, and Uniform Title lateral link fields to be consistently clickable in the full record display for all records, regardless of data source. 

Authority record enrichment for Established Headings (VE/BO)

VE/BO

Support for indexing and displaying Established Headings 7XX fields from Authority records. Primo currently indexes preferred and non-preferred terms from 1XX and 4XX fields in related Alma authority records (either local or CZ) along with the following bibliographic record authorization fields (MARC 21): 1XX, 600, 610, 611, 630, 648, 650, 651, 654, 655, 700, 710, 711, 730, 751, 752, 754, 800, 810, 811 or 830 Primo should enable enrichment with 7XX fields of Established Heading from Authority records in the same way fields 1XX and 4XX of authority records enrich bibliographic records in Primo. Example authority record: 035 __ |a (DE-101)040537323 035 __ |a (DE-588)4053732-8 ... 150 __ |a Schwangerschaftsabbruch 450 __ |a Abortus artificialis 450 __ |a Interruptio graviditatis ... 750 _7 |a Abortion |0 (DLC)sh 85000196 |0 http://lccn.loc.gov/sh85000196 |2 lcsh |9 v:MACS-Mapping. Bitte keine Änderungen vornehmen. 750 _7 |a Avortement |0 (FrPBN)FRBNF119310099 |0 http://data.bnf.fr/11931009 |2 ram |9 v:MACS-Mapping. Bitte keine Änderungen vornehmen. 

Ability for users to view their request history in My Library Card/Account in Primo (VE/BO)

VE/BO

It would be highly beneficial for users to be able to view their own request history in My Library Card. This would create parity with with loans element of My Library Card. This would be patron physical item requests AND resource sharing requests, include cancelled request (including all details) and also be able filter on type of request and status. Currently to get this information users have to request it with library staff, meaning more work for staff and delays for information to users. Currently for staff we have to either look in the resource sharing requests system (resource sharing requests) or build analytics reports (patron physical items requests) for users to extract this information. 

We receive a significant number of queries related to this and for the request to get to the correct staff member or team takes extra time too.  Therefore, making it self-service would improve the end-user experience and reduce additional work for library staff.
Currently, there are four similar IdeaExchange items with 248 votes(!!) (one has been "under review" by Primo's PM for a long time):
; ; ;

Add facets to Collection Discovery (VE/BO)

VE/BO

We suggest adding facets to the Collection Discovery and having the ability to choose which facets to display and how their values will be sorted, just like on each tab of any view. The new facets will be separately configured from the view facets. Still, they will have the same setting options one can currently find in the view Configuration for regular facets. 

There is also an IdeaExchange that got 125 votes already:

Add A-Z to Database and Journal Search (VE)

VE

Primo VE does not have an A-Z in Database Search or in the Journal Search. This is a parity issue, as this feature is available in Primo managed via Back Office. Ex Libris has stated that this is a design decision because they believe users see an A-Z as outdated. This opinion is not reflected in evidence in Primo Analytics, with up to 3,300 clicks on A-Z Database Search per month. 

Currently, there are three similar IdeaExchange items, which have altogether 272 votes(!!):

Show facet counts for top level and new records (VE)

VE

Primo VE design hides facet counts for top level facets and the new records facets. Our users report to us that seeing a count against facets gives meaning to results, and entices them to use the facet, as they can clearly see the outcome of their action by the stated number of results. This meaning is not significantly lost by minor variations for grouped records. This is a parity issue, as this feature-rich functionality is consistently available for users in sites with Primo managed via Back Office. 

Add ability to create mapping tables for use in normalization rules (VE)

VE

Primo managed via Back Office has powerful functionality to reference source data by normalization rules against custom built mapping tables and normalize accordingly from source data to target data. This has benefits for consistent display in full records, able to be used also for lateral links that bring together all records regardless of source data variation, as well as the same benefits in cohesive facets. It also enables addition of underlying search data to support return of results, such as if source data is a term which a user may not include in their query such as 'BAHons', as this can be mapped to add meaningful terms which a user is more likely to have in their query, such as thesis, honours, bachelor, bachelors. Sites can also collapse into one similar locations for multiple libraries by such mapping tables, such as all 'Stacks' locations grouped together. There are endless use cases for how sites can improve their Primo environments through dynamically built mapping tables, to meet the needs of their users and their collections. This is a parity issue for Primo VE, and it should offer the same full configuration functionality as Primo managed via Back Office.  

Add ability to manipulate availability statements and GetIt by Delivery and Scoping and Links rules (VE)

VE

Primo managed via Back Office has powerful functionality to adjust availability statements and GetIt by Delivery & Scoping rules and Links rules for all harvested data sources. This adds meaning to results for users in Primo, with an immediate indication of levels of access, and then supports the user to move forward seamlessly by offering specific pathways to either immediate access or access by request. This functionality includes the ability to build rules mapping by specific source data such as linktype when records are available in full online, when a link is provided to an abstract, or to information for a physical resource. This is in sharp contrast to Primo VE, where availability statements are hardcoded, including for digital records in institutional repositories which are all marked as full text available, regardless of actual availability. As a full use case example, we take great advantage of this ability in Back Office to mark records as 'Access conditions apply' by 'may_be_restricted' availability statement for targeted Institutional Repository records and our Archival Management System records, with an 'Access' label in the GetIt section. We also then employ a cascading set of rules by linktype for four different Link to Resource labels such as 'Citation only (Embargoed)' married with Access, 'View online for staff and students (Log in required)' married with View It, and 'View online' for open access records married with View It. We also trigger the addition of a link to a request form in the Access section for records which are 'Citation only (Request access)', for records in a few specific collections by dc:relation data, and for all our Archival Management System records. This is a parity issue for Primo VE, as sites should have the ability to display their records accurately and as they wish for their users with the same full functionality as Primo managed via Back Office for all records (including Alma records, discovery import profile records, and Remote Digital Repository records).  

Add ability to add and adjust top level facets (VE)

VE

Primo VE currently does not permit addition or adjustment of top level facets other than to disable them or hide them by customization package. Primo managed via Back Office has full ability to adjust top level facets for local records by the facets_toplevel rule specifically for just this purpose for all local data sources. We have utilised this functionality, with examples such as adding a top level facet for all Alma 'Physical Items' by Alma-P, instead of only the out-of-the-box facet value for available physical items, to blend all Alma records with a local fields of lds50 of peer-reviewed with CDI records in the Peer-Reviewed facet, and for all Institutional Repository and Archival Management System records by linktype for either fulltext to blend with the Available online facet or linktypes such as notonline to add a new top level facet of Access conditions apply (married with the may_be_restricted availability statement). We also configured relevant Alma and Institutional Repository records to blend with the Open Access CDI records years before it was done out-of-the-box by Ex Libris. This is a parity issue for Primo VE, and it should offer the same full functionality as Primo managed via Back Office for all records (including Alma records, discovery import profile records, and Remote Digital Repository records). 

Report on external data sources via Primo Analytics (VE)

VE

Analytics for Primo BO includes a subject area for Primo Pipes, which allows reporting on data sources piped into Primo. The same subject area is not available for Primo VE, meaning we cannot report on any external data sources. This would be useful for monitoring external records in Primo and allow headline figures for number of records in a particular data source, for example. 

This would be useful for monitoring external records in Primo and allow headline figures for number of records in a particular data source, for example.

Add subfield $$d to the Mapping of FRBR key 1 Author name (VE)

VE

FRBR Mapping is not recognising the subfield $$d in the authority name – this is not included in mapping of the FRBR key 1 author field. This could have consequences for grouping popular titles in Primo VE under unrelated authority duplicate names that should not be grouped together. Please see attached document for more information 

06215127 - Dedup/FRBR Groups: Mapping FRBR K1 Author is missing subfield $$d

Subfield $$d in MARC is 'dates associated with a name' .  This is an important field that can distinguish between duplicate popular names and makes them unique.  This is omitted from the FRBR process.  This could have consequence of grouping together incorrect works in Primo VE under the wrong author name.  Please see attached document for more information

Add 12-Hour Due Times Display in Library Card (VE/BO)

VE/BO

Currently, per a setting in Alma, due times in Alma and Primo can be set to display in the 12-Hour format (ex. 02/25/2023 5:45 PM PST). However, when a patron views their account in Library Card via Primo, due times display there in only 24-Hour format (ex. 02/25/2023, 17:45). Please have due times displayed within Library Card use the same format that is set in Alma. 

Full integration of Syndetics enrichment content by indexing for search (VE/BO)

VE/BO

Syndetic Unbound enrichment content should be indexed in Primo, to aid the retrieval of books (especially by chapter titles in TOCs) and displayed inline in Primo. Both products are from Clarivate so this purpose should be technically easier on the Primo "cloud" platform. This would make it possible the retrieval of physical books searching by terms of the Table of contents. 

Possibility of retrive physical books searching by terms of the Table of contents

Improvement of the "Calculate queue" function on request forms (VE/BO)

VE/BO

In 2020 a new button for calculating the patron’s place in queue when requesting a physical title was introduced. The function was a welcome attempt to make it clearer to the patron how long he/she might have to wait to get the book, but with the current design we find it more confusing than helpful. The function does not take into account if any items are available in the library or if all items are on loan to other patrons. 

When a user places a request on a title that is available in the library the current message is "Place in queue is 0". This is ambiguous and could make the patron uncertain if he/she will get the book at all. The actual meaning is "The book is available, and there is no request before mine".
We suggest that there should be two different labels depending on the loan status: one label if any item for the title is available in the library, and one if all items are on loan to other patrons. We also suggest that the label does not display until the patron clicks on the button "Calculate queue".

Ability to do a bulk export of search results (VE/BO)

VE/BO

In a recent user survey, students provided feedback they would like the ability to export all or a large number of their search results. Currently, they are limited to a maximum of 50 results at a time. Users reported they had worked to create a search strategy and were disappointed they could not obtain a full list of their search results, and were forced to move to searching individual databases instead. Please add an option to export all or a larger number of search results such as 1000 results at a time. Users have an expectation that this is 'standard' functionality for a search interface.  

Add ability to find targeted CDI Newspaper Articles in main Primo results, when currently only found in Newspaper Search (VE/BO)

VE/BO

Newspaper Article CDI records cannot be found in main Primo when in collections deemed “Newspaper Search only” by 80% or more newspaper content. The number of collections in this category increased dramatically in the shift from PCI to CDI by Ex Libris decision, with the outcome that a great deal of subscription content is not available to our patrons conveniently in our main discovery environment. We find evidence of negative impact in our Zero Results Primo Analytics, with patrons performing repeated known item searches for articles in our key national newspapers, which is now found only in Newspaper Search. The Ex Libris decision-making to separate the content is reasonable in terms of trying to find a solution for the vastly increased scale of CDI newspaper content which would flood main Primo if Newspaper Search did not exist at all. However, the current design is too strict in leaving no option to discover these resources other than by forcing use of Newspaper Search, when the site may have reasonable justifications not to implement that environment. This enhancement request proposes softening the current design by options such as 1. Adding the option for a site to configure a number of specific ISSNs / eISSNs which would return all associated CDI Newspaper Article records for those resources also in main Primo or 2. Adding a checkbox option to a current “Newspaper Search only” collection which a site could enable to return all associated Newspaper Article CDI content for that collection also in main Primo. 

Add configuration option to show more facet values in a blended search (VE)

VE

Primo VE currently is only capable of returning up to 50 facet values for local records in blended searches. In contrast, sites using Primo managed by Back Office can configure this setting, with ours set to 500 by initial display of 3 and then users may choose the Show more option. This is a parity issue for Primo VE, as it should offer the same full configuration and UI functionality for Primo VE users to filter results without such an artificially low limit. 

Add ability to configure browse normalisation rules for Virtual Browse and Browse Search (VE)

VE

Primo VE currently offers no configuration options for Browse Search and Virtual Browse by browse normalization rules. This is possible in Primo managed by Back Office, with such adjustments as removing low value subjects such as 648 chronological term, 655 genre, and 650 when bisacsh; eliminating records with incomplete call numbers such as those with only the main class and data with no browse meaning such as “ISSN RECORD” from Community Zone records; adjusting for local practices in 090; and inclusion of some non-Alma data source records for specific browse search indexes only and with normalization to remove national regulatory codes. Such configuration is important to our site as a valued user service, with Virtual Browse averaging several hundred clicks per day, and this engagement going up every year as local improvements have been made. In contrast it is notable that it is very common to find Primo VE sites have completely disabled both local browse features. This is a parity issue for Primo VE, as it should offer the same full configuration and UI functionality as Primo using Back Office, for serendipitous browse features. 

Increase number, normalization, and indexing options for local fields (VE)

VE

Primo VE currently allows only 10 local fields by ‘Normalization Rules Method’ and requires sites to ask Ex Libris to reindex the data. In contrast, Primo managed by Back Office has the ability to fully configure 250 Display fields, 50 Facet fields, and 50 Search fields, plus option to fully adjust any out of the box field rules, and sites have the ability to update and reindex their own data as they wish. Otherwise Primo VE sites must use the extremely limited ‘Bibliographic Field Method’, with such conditions as artificially limited field options and forced to take all the raw source data as is, for only 100 MARC local fields. This is a parity issue for Primo VE, as it should offer the same full configuration and autonomy options as Primo using Back Office. 

Add ability to add Links to Library Account areas, including Loans, Requests, Fines, Blocks, and Settings (VE)

VE

Primo VE currently has no option to add links to Library Account areas, including Loans, Requests, Fines, Blocks, and Settings. In contrast, Primo managed by Back Office allows for up to 3 links to be added to each area. We have used this functionality to add in-context help links to information on overdue charges, borrowing rules, guidance on different request options, and updating personal information in our upstream systems. This is a parity issue for Primo VE, as it should offer the same full configuration and UI functionality options as Primo using Back Office. 

Add ability to disable fields in Citation Linker (VE)

VE

Primo VE currently has no option to disable fields in Citation Linker (Fetch Item). In contrast, Primo managed by Back Office allows for disabling of fields by Citation Linker Definitions mapping table. We have used this configuration option to remove fields to avoid wasting patron time in filling out a great deal of information which has no purpose and is ignored given the primary match criteria of identifiers such as DOI and ISBN. This includes author fields for Books, publisher for Articles, and fields other than Journal Title and ISSN for Journal. This is a parity issue for Primo VE, as it should offer the same full configuration and UI functionality options as Primo using Back Office. 

Add ability to configure assignment of Database type in Primo by record metadata (VE)

VE

The configuration options in Primo VE are being improved over time but Primo VE still does not allow sites to determine records to be Database type in Primo by record metadata. Instead there is enforced hardcoding by Electronic Collection conditions of association with a bibliographic record that is not suppressed and an Electronic Collection URL. In Primo Back Office we have configured a rule by Leader(06-07)=a and b,i,s AND 008(21)=d, with an outcome of many more records for our patrons in both our main Primo and in Primo Database Search as Databases. Sites should be able to determine how their records appear to their patrons, and not be constrained by Ex Libris deciding this on their behalf. This is a parity issue for Primo VE, as it should offer the same full configuration and UI functionality options for sites to choose to control their own data to determine Database records as is possible in Primo using Back Office. 

Allow HTML coding in labels, public notes and collection description (VE/BO)

VE/BO

Please allow HTML coding in labels, public notes and collection discovery description, including a href for links. 

Labels
Public notes
Collection discovery description

Allow Exclusion of Institution Zone only records from Discovery Network/NZ Scope (VE)

VE

In consortial environments, the Network Scope includes Institution Zone only records such as laptops, keys, etc. We would like the capability to exclude IZ only records from a Discovery Network scope so that we can display only records that are NZ bibs, not local IZ with no NZ bibs. 

The way the Network scope currently works all resources from every institution are present.  This includes non-requestable local materials (laptops, keys, study guides, popular titles, etc.) as well as resources that may be contractually prohibited from being shared outside of an individual institution.

We would like the ability to customize the Discovery Network scope so we can create a better user experience for our patrons and control what is discoverable to other institutions in our consortium.

Add ability to configure the display at the item level and the location level in the GetIt section (VE/BO)

VE/BO

In Primo, the display of the GetIt section works currently as following: If there are only items in one location, the first display after opening the full view is at the item level (example: https://eth.swisscovery.slsp.ch/permalink/41SLSP_ETH/lshl64/alma99118073204005503). If there are items in more than one location, the first display is at the location level (example: https://eth.swisscovery.slsp.ch/permalink/41SLSP_ETH/lshl64/alma990104195490205503). Because our libraries are part of a huge consortium, our users always have to check first in which library an item is available before checking the item information. Furthermore, we believe that the user experience would be better, if the GetIt section looked always the same at first glance. We therefore wish that libraries can configure in Primo whether the first display in the GetIt section is at the item or the location level when only one library is visible.  

Include criteria from local fields and resource types in Service Availability Rules (VE)

VE

In Primo Back Office, normalized local fields can be mapped to OpenURL attributes in the delivery template for Primo's Get It section. In turn, the values of these OpenURL attributes can be used in Service Availability Rules to evaluate whether a General Electronic Service should display or not. In VE, we appear to be limited to OpenURL attributes that are mapped "out of the box" and we can't migrate some GES's that use specific local metadata. The few parameters that aren't from the OpenURL template (Library, Location, Item Policy) aren't sufficient to determine if a record qualifies for a service. We're proposing that either: *normalized local fields and resource types be made mappable to OpenURL values that are already included in Service Availability Rule parameters (similar to Primo Back Office) or *normalized local fields and resource types retrieved directly from the PNX record be included in Service Availability Rule parameters 

Display different Aeon request links (2 different GES's) for Burns library material depending upon whether the resource is published material or archival material/manuscripts.
Display a descriptive link to ArchivesSpace in the Get It section for records that include an 856$u with the string " " in it.

Add support for complex XML external data sources (VE)

VE

We would like the ability to map complex XML directly to a PNX element, as is already supported for the Primo Back Office. This should include the ability to store XML in a PNX element, which can then be manipulated for display by local angularJS customizations. For example, we'd like to store XML in a PNX element that can then be read and rendered specially using custom AngluarJS code. Example in Primo Back Office: http://id.lib.harvard.edu/via/olvgroup12512/catalog. This is a group of images, with metadata at the top level representing the group (and a thumbnail representing the group), and 64 component images, each with their own title, caption, and other metadata elements. Using AngularJS we can read the native XML that is stored in a PNX addata element, and use it to support a grid display, as well as a page for each component image that supports scrolling through the entire set, and a page that shows all images with all component metadata at the same time. This latter page is especially useful when it isn't obvious why a group record was returned through a given keyword search. The user can open this page and use Control+F to find the component image metadata in which the keyword appears.  

Import complex XML data source for images and retain complexity and specificity to support display of component images and their metadata and image hierarchy. 

This is support in Primo Back office already. Feature parity. 

Support full-text extensions for local data sources (VE)

VE

Add support for indexing local full-text data sources as extensions of Alma records. This already exists in Primo "Classic" (Back Office). For example, we can load finding aid XML from special collections as full-text extensions, and have them indexed with corresponding MARC records (based on Alma identifiers stored in the finding aid). In this scenario, a user can conduct a keyword search, and retrieve a MARC record, where the keyword appears only in the finding aid XML, and not in the corresponding/matched MARC record. This allows users to find container level information that is not cataloged in MARC. A user can search "American Committee for Cultural Freedom" and retrieve the "Daniel Bell personal archive, 1903-2008," even though that phrase does not appear in the MARC record; it appears in the finding aid XML onlyu. This functionality should include the display of "snippets" in search results for matching full-text content. As a second example, we can load a data source of vendor Tables of Contents in XML and have them indexed as full-text extensions of matching MARC records. This allows users to find materials by tables of content keywords that may not be present in the MARC record.  

indexing full-text of EAD finding aid XML with corresponding MARC record for that finding aid. 

Full-text searching is a valuable feature and already exists for CDI content. It would be especially valuable for local data too. 

Improve support for diversity, equity, and inclusion through automatic handling of non-Latin script parallel fields (VE)

VE

Non-Latin scripts are extremely important in describing and discovering collections and in MARC they exist as parallel fields. These non-Latin scripts represent languages in their authentic form, not the Latin/Roman transliterations which are often not understood by speakers of the languages that the scripts represent. Out of the box norm rules do not handle many of the MARC elements for which non-Latin paired fields may exist, thus ignoring this critical and culturally valuable information. Likewise, for custom rules, normalization rules must be written for both versions of the field (the vernacular and the romanized). This doubles the number of normalization rules that must be written for libraries with non-Latin scripts. For example, for every 246 field with non-Latin parallel fields, two rules must be written (2 for display, 2 for search, 2 for facets, 2 for browse, 2 for addata). PrimoVE should automatically recognize the existence of the non-Latin paired fields and handle them per the norm rule for the corresponding pair, so that only 1 rule needs to be written. For example, if a rule is written for field 520, and the MARC record contains a linked 880 non-Latin field for this 520, PrimoVE should automatically handle this linked 880 the same way as the 520 is handled per the norm rules, thus requiring only 1 rule. This will ensure that no non-Latin script fields/subfields are missed, and simplify the introduction of new MARC fields and subfields as they are defined. The range of non-Latin scripts that can be found in MARC is wide and includes but is not limited to Armenian, Tibetan, Ethiopic, Syriac, Tamil, Thai, Greek, Hebrew, Cyrillic, Vietnamese, Chinese, Japanese, Korean, Arabic, Bengali.  

ISBN 4000614320 for a Japanese work includes non-Latin scripts in fields 100, 245, 264, 600, 650, 700, and 765. Just to accommodate these 7 fields (which represent only a small sample of fields that might have non-Latin script) require at least 14 rules for display of both Latin and  non-Latin paired fields, another 14 for browse, another 14 for search, another 14 for facets, another 14 for adddata. 

Display non-Latin script fields in CDI, important for equity and inclusion (VE/BO)

VE/BO

Non-Latin scripts from data sources such as HathiTrust and Center for Research Libraries are not displaying in CDI. When there is non-Latin in an *article* record in CDI, the non-Latin generally displays without a problem, but not for data sources that presumably supply MARC source data. Here is an example from the CRL (Center for Research Libraries) collection in CDI: https://hollis.harvard.edu/permalink/f/hg18ek/TN_cdi_crl_catalog_b22335754 The same record in the CRL catalog shows non-Latin fields: See also OCLC number 502898363 in HathiTrust, for title Xia chuan shi chao = 硤川　詩鈔. There are 5 fields with non-Latin script in that HathiTrust MARC record, and none of them display in CDI. Non-Latin scripts are extremely important in describing and discovering collections and providing access to non-Western resources. These non-Latin scripts represent languages in their authentic form, not the Latin/Roman transliterations which are often not understood by speakers of the languages that the scripts represent.  

Improve handling of in-press articles in CDI (VE/BO)

VE/BO

CDI contains many records for in-press journal articles (articles that have been accepted for publication in a forthcoming issue). However, because these records lack publication details such as date, volume, and issue number, the link resolver cannot reliably determine whether the institution has access to these articles. We ask that Ex Libris improve the way in-press articles are managed in CDI so that the link resolver does not return false positives for content the library does not actually own.  

Improve user experience by reducing the number of availability and linking errors caused by in-press articles. 

Preserve the formatting of citations copied from Primo (VE/BO)

VE/BO

Primo's citation tool copies citations to the clipboard in plain text format, causing all formatting to be lost. In order to preserve citations in the correct formatting, this tool should be modified to allow citations to be copied in rich text format. 

Improves the accuracy of citations generated from Primo by ensuring they display in the appropriate format.

Multivolume works: show enumeration and sort the volumes accordingly (VE/BO)

VE/BO

With the March 2021 release we got "Related Link for Series Added Fields 80X-83X", which was a big improvement. // But in the list of volumes, the volumes are missing their volume number and they are sorted alphabetically. // How this looks: https://basel.swisscovery.org/discovery/fulldisplay?vid=41SLSP_UBS:live&search_scope=UBS&tab=UBS&docid=alma993707790105504&lang=en&context=L // How it should be looking: // 330 votes here and 237 votes here  

Suppress "Locations for related titles" for 8xx $w (VE)

VE

"Locations for related titles" is ok when the relation comes from field 773 $w. // "Locations for related titles" from field 8xx $w creates several problems which are misleading and frustrating for our patrons and teach them that they can't trust our catalog. We need an option to deactivate the 8xx $w relation while keeping it for 773 $w. // 554 votes here // Example https://basel.swisscovery.org/discovery/fulldisplay?docid=alma996600630105504&context=L&vid=41SLSP_UBS:live&lang=en&search_scope=UBS&adaptor=Local%20Search%20Engine&tab=UBS&query=any,contains,%22brigitte%20springmann%22&offset=0. The title is from 1989. Nothing shown under "Locations for related titles" covers 1989. // Additional problems are: wrong information in the facets, wrong information in the short title list for "Available at ... and other locations". // In addition, please make the distinction between 773_# (standing for "In: ") and 773_8 for all other cases more obvious.  

Index item level information (VE/BO)

VE/BO

Please index the information stored in the item for search. Call number for search and browse index: 360 votes Public note: 48 votes .  

Search by PubMed ID PMID and DOI in advanced search (VE/BO)

VE/BO

Currently Advanced search allows patrons to use search filters such as author/creator, title, ISSN, etc. Many users in the Sciences or Medical fields retrieve articles via PubMed ID (PMID) and/or DOI. We understand these options are available in Citation Linker, but we currently do not make use of this feature because of the poor performance when using title or author searches. For consistency, it would be helpful to have PubMedID and DOI as search filters within Advanced Search. Ideas Exchange:  

Citation Linker has the option to search by DOI/PMID, but the other search fields get poor results. To reduce confusion, we direct users to Advanced Search and having the DOI/PMID as search indexes would greatly help our Sciences & Biomedical students.

Expand Analytics for Advanced Search (VE/BO)

VE/BO

It would be helpful to have analytics available to see how patrons are using the pre-search filters - material types, language, Start Date/End Date, etc. This is a part of the URL when conducting the search - pfilter - and could be easily extracted to analyze. An example: https://catalog.library.vanderbilt.edu/discovery/search?query=any,contains,truth%20or%20dare,AND&pfilter=lang,exact,eng,AND&pfilter=rtype,exact,books,AND&tab=Everything&search_scope=MyInst_and_CI&vid=01VAN_INST:vanui&mode=advanced&offset=0 In this example, we have a pre-filter of Material Type = "Books" and Language = "English". In the URL, this shows up as pfilter=rtype,exact,books (Pre-filter of Resource Type exact Books); pfilter=lang,exact,eng (Pre-filter of Lanuage exact ENG). Ideas Exchange:  

We based a lot of the decisions we make on Analytics. If user's are not using a feature, we want to remove it; or if a feature gets heavily used, we want to highlight it. It would help us in making future decisions if the pre-filter was included in Analytics.

Improve Citation Linker (VE/BO)

VE/BO

Many patrons do not include an identifier (DOI, PMID, ISSN/ISBN) in citation searches. An improvement would be to improve the results when performing title searching or title/author searching without having to include an identifier. Similar to NERS #8132  

Non-science/medical students who come across Citation Linker do not realize that this feature works best when using a DOI or PMID. The author or title or other search fields rarely bring up accurate results leading to confusion and frustration.

Citation Styles Labeling in Analytics (VE/BO)

VE/BO

We utilize Primo Analytics heavily to assist in informing our decisions. We have discovered, however, that some of the fields are not clearly identified. For instance, we make use of a number of citation styles (MLA, APA, Chicago, etc.), but when you try to pull up statistics in Primo Analytics, all you see is "Citation Style 1", "Citation Style 2", etc. We have no idea which citation those refer to. The same can be said of the main menu links. Instead of seeing "New Search" or "Databases A-Z", we see "Main Menu Link 1", "Main Menu Link 2", etc. What we propose is the following: clearly identify in Primo Analytics what the data represents. For instance, instead of "Citation Style 1", it should say "Citation MLA". Instead of "Main Link 1", it should say "Main Link - New Search". Without these being clearly identified, we cannot truly rely upon Analytics for informed decisions. Case #06280666  

Many of the decisions we make in regards to the public catalog is based upon usability. To do this, we rely heavily upon Analytics for a lot of those decisions. We re-organized the Citation Styles, putting them in alphabetical order, but then realized that Analytics did not identify which Citation Style is which. This is problematic.

Increase facet display for languages for diversity equity and inclusion (VE)

VE

We want to show all language values in a facet for any given search result. If a search result has items in 65 languages, 4 values should appear in the facet column, and after clicking More, an additional 61 should appear. This is currently possible in Primo Back Office, but is not possible in Primo VE which supports at most 50. (In Back Office this is supported through the Static Facet feature.) For many languages, a collection may have only a few titles, but these are just as important as languages represented more frequently in the collection. It is important for users to be able to see all languages represented in the collection. For example, a search on "racism" in the Harvard local catalog has content in 77 languages. The Primo VE limit of 50 would prevent the user from seeing titles in Tatar, Khmer, Slovenian, Georgian, etc. For usability purposes, we suggest that after clicking More, up to 100 additional values display, and if there are more than 100, an additional More link should appear, and so on until all values are displayed. The list of values should be cumulative; the list should continue to grow each time a user clicks More. The More link should appear under each 100 values until there are no more values. Ideally, this feature would apply to all facets, not just languages, but we choose to highlight languages in this request because of its especially important role in supporting diversity, equity, and inclusion in the library catalog.  

Add double dashes to subject heading displays between subdivisions in Browse feature (VE)

VE

The standard display of subject headings, as seen in the Library of Congress, is to place double dashes between their subdivisions. So "$a Germany $x Politics and government $y 19th century" would be displayed as "Germany--Politics and government--19th century." Although bibliographic records viewed in Primo VE do use this punctuation, results seen in the Browse feature when browsing subject headings places the subdivisions together without distinction, only separated by spaces, resulting in "Germany Politics and government 19th century." 

Searching for any subject heading where a subdivision can be added in cataloging.

The lack of punctuation makes the subject headings less clear to users and isn't consistent with standard practice; it should be a simple matter for Primo VE to place double dashes where a subfield indicator belongs since it already does this within records.

Fill the gap of Open Access CDI records not marked with the Open Access indicator and facet (VE/BO)

VE/BO

The Open Access indicator and facet were added to Primo in May 2018, per Idea Exchange submission: . These features were applied at metadata level by provider feed first for PCI and now CDI. This was the root cause for a significant gap in the number of Open Access records incorrectly not marked as Open Access when provider data did not include this information. For example, tens of thousands of PloS One articles not marked as Open Access. At the end of 2022 a change was made in terms of the link proxy being removed when it is determined at the link level that there is Open Access. Unfortunately this change was not aligned to also show the Open Access indicator and facet when this link level Open Access determination is made. The outcome is that our patrons do have a better experience in terms of fewer linking issues but they still miss out on the immediately clear indication in brief results by the indicator that a resource is Open Access, they have no ability to use facets to filter to this content, and we have no ability as a library to do promotional activities such as sharing a URL with the Open Access facet locked in place. For many libraries, there are strategic institutional level goals to support and promote Open Access content, and these missing features mean that our core service discovery layer does not support us to align with these goals. A successful delivery of this request would be that the Open Access indicator and facet are also added to records when there is a link level determination of Open Access status. See also Idea Exchange:  

Support for truncation/wild card within quotation marks (VE/BO)

VE/BO

January 2016 I asked for this feature for Primo BO: You added it November 2016: https://knowledge.exlibrisgroup.com/@api/deki/files/46615/Primo_SP_-_November_2016_Release_Notes.pdf?revision=4 Now in this case 06534849 they answer: "Primo (not VE) and Primo Central are based on a different search engine than Primo VE and CDI, which are Solr-based products and currently do not include this option. As a result, the behavior where a wildcard is supported within an exact search is not possible in Primo VE / CDI and will require complex development. We suggest raising this in a NERS as developing this behavior will require a major effort." Observe I mean within quotation marks, not parentheses. 

Improve UX of sending emails from Primo (VE/BO)

VE/BO

1. Sending an email should trigger a confirmation text, in analogy to "Your request was successfully placed". // 2) The form needs to have a field for "Sender's email". Ideally it pre-populates with the patron's email address when he/she is logged in. // 3) Setting per view: force patron's log in to send email? yes/no. If possible, suppress reCaptcha for logged in patrons.  

Ability to edit the Out-of-the-Box search and facet rules in Primo (VE)

VE

We would like to be able to edit the Out-of-the-box (OTB) search and facet rules. This is necessary for parity with Primo BO. There are several things that we were able to do in Primo BO that we cannot reproduce in VE because of the lack of this functionality. In the Primo BO OTB author search and facet, we were able to include dates and qualifiers from names in the LCNAF, which improved precision. In the OTB language facet, we were able to include intertitle, caption and audio description languages, which are not currently included in the VE OTB index. On the other hand, we excluded languages of accompanying material, which are currently included in the VE OTB language index. We were able to limit the OTB subject facet to specific vocabularies, such as LCSH. This improved the usefulness of the subject facet because it removed near duplicates and non-English headings. This meant that users got a more helpful variety of terms within the top twenty facets. For subjects, ideally we would be able to do different things with the OTB search index and the OTB facet index, as was possible in Primo BO. In Primo BO, we included a larger number of vocabularies in the search index than we did in the facet index. 

Brief record display configurable for Collection Discovery (VE/BO)

VE/BO

Enable libraries to configure what fields display in the brief records in the Collection Discovery page. Currently only the resource type and title appear. In many instances this information is not sufficient to enable users to choose which item to view. We would like to be able to configure which fields display. For example would like to display the creator and the date on brief records on items in the Collection Discovery view. Because of the lack of information displayed in Collection Discovery tiles we have many lecturers who prefer to share a link to a search in the Primo search interface over a link to the collection discovery page. Enabling libraries to customise and choose what fields to display would greatly enhance the usability of collection discover-ability. See also the following Idea Exchange ideas: and  

1. A patron is browsing the discovery layer of Special Collections & Archives collection of artist books and needs to see the name of the creator to know which book to request.

2. A patron is browsing the Kallir Collection and sees two items with the German title "Gedichte" which simply means poems, but the creators' names are not on display.  In order to know which book to request, the patron needs to see the authors' names, and it is much easier to see that in the initial brief display, rather than having to click into the detailed view of each item.

3. A patron is browsing the textbook collection, but needs to see the publication date in order to know which version of the textbook is the one required for their course.

Having the ability to customize the display of items within a collection's results list would enhance the user's discovery experience without having to click on the icon to reveal the complete bibliographic record in Primo. 

Move Copyright limits advice to top of digitisation request form (VE/BO)

VE/BO

We are using almaDigitization.copyright.sub_title to add our copyright information to the digitisation form. This information, by default, displays at the bottom of the form before the copyright declaration. We would like to move this information and the declaration to the top of the form, above the chapter/article details so that users see/read it before entering their request details. We would want the users to know their copyright limits before adding all request details. See the attached screenshot. Salesforce Case #06565903 

Course Information Display - Brief display and full details page (VE)

VE

We would like to be able to modify the default configuration of Course Information field displayed in the brief and details view of the full record in Primo VE, adding to or deleting the default elements (Course ID, Course Instructor Name) or changing their order. For example, an institution may want to include only Course ID and not Instructor Name. This is not currently possible. Raised case and suggested to explore via NERS and IDEAS Exchange. Currently this IDEA has 136 votes and under review since Apr 2022."  

Improved Support of multilingual elements for external data sources (VE)

VE

For Dublin Core and Generic XML records that contain multilingual content, Primo VE should display the values of the associated fields according to the user's language when the language code is available as an attribute in the Dublin Core elements. For instance:  dc:subject xml:lang="fre" Phonotèque/dc:subject dc:subject xml:lang="ita" Fonoteca/dc:subject 

Ability to set Resource Type Mapping for Serials in 'Journals' search tab (VE)

VE

For Primo VE 'Journals'-search tab : ability to configure Resource Type Mapping for serials (Unimarc 110$a) according to local usages (i.e. what WE consider as 'journals', which corresponds to actual organisation/access to our collections). Currently only 2 types of serials are hard-coded amongst 13 ($aa and $ac).  

The choice of the Serials Type if made by ISSN. Primo limits furthermore this choice to only 2 which may not correspond to users/library uses. This makes a part of collections invisible from the catalogue.

Make CDI API's interoperable with Summon and Primo (VE/BO)

VE/BO

Summon and Primo API's for CDI have different syntaxes and thus must be re-created when a library migrates from one discovery product to another. The CDI content is the same, but the Primo/Summon API syntaxes differ. Additional library staff software development time is required to migrate CDI API from Summon to Primo, and instead CDI API's should be interoperable with Summon and Primo. 

Only authorised access points from authority files should be pulled into the Primo subject facet area (VE/BO)

VE/BO

When searching CDI-inclusive search scopes in Primo, results coming from the CDI systematically surface what appear to be LCSH see-references (field 450, MARC21 Authority format) as if they were separate, valid facets for subject narrowing; however, these 450s should only exist on the backend for indexing and point to the correct subject (the authorised term in the 150 field). These additional 450 fields take up valuable space in a limited display facet and place a higher burden on end users to evaluate results and access content efficiently. The 450s also complicate library DEI efforts, as they can contain offensive and outdated terminology like “Retarded children” and “Sexual dissidents.” Only the valid heading from 150 should ever appear in Primo’s subject facet. (Please see attachment.) 

Please see attachment.

LCSH cross-references being surfaced in Primo include a lot of former terms and cross-references from the LCSH that the library community would prefer not to be given such prominence. e.g. Gypsies, Retarded persons, Illegal aliens.

Limitation of facet value display to 20 or fewer for CDI (VE/BO)

VE/BO

Limitation of facet value display to 20 or fewer. a. Negative impact: Makes precision narrowing far more difficult b. Example: Patron trying to browse the graphic novel genres in the library via the catalog must select two other facets (In the Library and the Graphic Novels location) before the "Genre" facet will include some less-frequently used genres like "School comics" https://marist.primo.exlibrisgroup.com/discovery/search?query=genre,contains,graphic%20novels&tab=Everything&search_scope=MyInst_and_CI&vid=01MARIST_INST:01MARIST&facet=tlevel,include,available_p&facet=location_code,include,4171%E2%80%9313716940004171%E2%80%93graphic%20no&offset=0 c. Proposed solution: Libraries should be able to configure how many facet values display. Maybe 5, 15, 25, 50? 

Locate the Books/eBooks resource type higher in the list of facets (VE/BO)

VE/BO

After a user does a search, and the results page is presented, the "Books & eBooks" resource type consistently appears under the "Show more" button making it take longer for users to apply that filter. A. Negative Impact: Users may not see popular resource types that are father down in the formats list. B. Proposed Solution: Locate the "Books & eBooks" resource type higher in the list of format limiters. 

Prevent search results expansion by use of exact phrase (VE/BO)

VE/BO

No ability to prevent search results expansion term inflection by use of exact phrase, either in Advanced Search by exact phrase or by quotation marks, or with Boolean operators, with associated loss of ability to do targeted specialised searches. Testing and cases have shown that the ‘Verbatim match boost’ and higher ranking for direct term match over variations such as spelling and synonyms are not succeeding in ensuring that all results are meaningful and targeted to match user queries. a. Negative impact: Makes it more challenging to perform specialized searches. b. Proposed solution: Using quotation marks and Boolean operators should generate more precise search results See additional information:  

Include both local and CDI newspaper content in Newspaper Search (VE/BO)

VE/BO

Newspaper Search appears to be a separate CDI search from "regular" catalog search; and it therefore doesn't include items from institutional repositories and the like, that are not represented in CDI in the Newspaper-specific indexing. a. Negative impact: End users cannot search both local and CDI newspapers in the same newspaper search. b. Proposed solution: Include both local and CDI newspaper content in Newspaper Search. 

Add a resource type for transcripts and audio in CDI (VE/BO)

VE/BO

Currently, several items in Primo show labeled as "Text resource." This occurs for things like radio program transcripts, as well as radio program audio files. 

Add ability to choose Collection Alma-C record display and functionality for Collection Discovery (VE)

VE

Primo VE currently enforces a setting equivalent to ‘Use Collection-specific display’ of Yes for Alma generated Collection (Alma-C) type records for Collection Discovery in main Primo search. This has a confusing and disconcerting behaviour of a click anywhere on the Collection record in main Primo immediately sending the patron to Collection Discovery in the same browser tab. The patron cannot open the record in main Primo to see the metadata unless they figure out the workaround that they can open a record before or after the Collection record in the brief results and use the Next Result or Previous Result arrows to see the full Collection record. Also, the patron completely loses their place in their list of results in main Primo, which could be a very negative outcome if they were working their way through pages of results. In contrast, Primo Back Office gives the option to set ‘Use Collection-specific display’ of No, with an outcome of a click on the record opening the full record display, where the patron can see the metadata and More from the same carousel, and choose to click through to Collection Discovery. This click opens a new browser tab, so the patron do not lose their place in main Primo results. As this setting choice does have a more brief display, we have done a simple configuration to add a local field to display the Collection description in the brief results, to further entice the patron to open the record and visit the collection. We would lose all of this with Primo VE where Ex Libris currently hardcodes this area, and thus this is a parity issue as Primo VE should offer the same full configuration and UI functionality options as Primo using Back Office. 

Improve Primo search results from CDI with aligned use of data for display, when it is used for search and facets (VE/BO)

VE/BO

With Primo results from the Central Discovery Index (CDI), patrons can search terms and select facet entries in Primo for data that may not display in the CDI record. This causes confusion and complaints from our patrons as they do not understand why our environment behaves in this way to show results which do not match their actions. In sum, there is no meaningful signpost to explain to a patron why this outcome has occurred. The root cause of this issue is that Ex Libris uses all data from providers in both search and facets, but states that it is not possible per contractual agreements with providers to also display the data in records, unless the site has activated the corresponding collection for full text. It has never been explained why it is acceptable in these agreements to use the data for search and facets, but not acceptable to display the same data in the record. Ex Libris argues that there is value in returning more content for patron searches, and this may be at least partially true, but they also do not receive the complaints directly from our patrons like we do, when they share comments such as that they will not use our core discovery service because they cannot trust the results. The outcome of this submission is either 1. Ex Libris also displays the data which is used for search and facets, or 2. Ex Libris stops using the data for search and facets when it is not also able to be displayed.  

Make the DOI field on the Full Record page a link including EZproxy (VE/BO)

VE/BO

Currently on the Primo Full Record page, the DOI field is not a link to the resource. Please make this a link with the option to prepend your EZproxy URL to the DOI links. (Summon added this feature in 2021.) 

Currently the DOI is plain text. If users want to use it, they have to manually construct an authenticated link by completing the URL and pre-pending the institution's EZproxy URL, which the typical user is not going to know. SUMMON HAS THIS FEATURE.

Brief search results - expose additional access options for items in brief search results (VE/BO)

VE/BO

We have implemented direct linking to our online resources from the brief results screen. This has been very successful, but we are becoming aware that increasingly, users don't know or have forgotten, that other access options exist in the full display screen. It would be useful if the brief results included hyperlinked text (after the Full Text Online hyperlink) to indicate alternative access options are available. Example: "Full Text Online" (hyperlinked) followed by "and others" (hyperlinked to record's full display screen) 

First year students - still learning how to use the discovery service and confident only to use the direct full text online link.
Mature students - still learning how to use the discovery service and confident only to use the direct full text online link.
Returning students who are ready to expand their skills but don't know to look further - this could be a useful pointer.

We are aware from feedback received from desk staff that users remain unaware of the full display screen and additional access options unless this functionality is directly shown to them.

Display on the Location list: textual descriptions of the physical arrangement of a holding unit (VE/BO)

VE/BO

The Primo holdings display shows the summary holdings, such as 852 and 866. However, when we enable this feature, the item range in the form of "from … until …." is no longer displayed in the Location list. We would like the ability to display both the summary holdings AND the auto-calculated item range ("from... until...") in the Location list. Here is a related Idea Exchange. Display on the Location list: textual descriptions of the physical arrangement of a holding unit  

TOU should be hidden when users Not logged in (VE/BO)

VE/BO

In Primo, when a user is logged in, the TOU according to the user's category is displayed. However, when the user is not logged in, the TOU could be displayed as "Loanable" even if the book is loanable only to faculty members. When the user is not logged in, the TOU should be hidden. Here is a related Idea Exchange. TOU should be hidden when users Not logged in.  

Applying Group by Library function to specific resource type (VE/BO)

VE/BO

The April 2022 new function to be able to group locations in Primo VE by library is great, though we would like to apply this only to journals. For example, when three libraries each hold a certain book, turning on this feature will force patrons to extra click to see the items. Also, it is very inconvenient because availability is not displayed on the library (first appearing) list. We would like to apply it only to journals, as this would be effective for journals that have many volumes and separate locations. This functionality should also be fully implemented in Primo BO. Here is a related Idea Exchange. Applying Group by Library function to specific resource type  

Displaying of "Proquest Ebook Central Purchase Model" on Primo (VE/BO)

VE/BO

It would be extremely helpful if the ProQuest Ebook Central Purchase Model was displayed on Primo. This information helps users to understand the availability of the full text or not without some clicks, which will increase convenience.  

Include records from both IZ and NZ in browse search (VE)

VE

In one support case (06423515) we learned that the browse search function in Primo VE will only include records from the IZ and does not return NZ records that are available to the institution. Users simply expect all resources available to be browsable. and they will not care whether a record is from IZ or NZ. Current browse search results are incomplete and misleading. We would like to request an enhancement to the Primo VE browse search function so all available resources from both IZ and NZ will be displayed. 

Using browse search functions for institutions with both IZ and NZ

Current browse search results are incomplete and misleading.

Add a configuration option to disable the expand/collapse function of advanced search panel (VE/BO)

VE/BO

In 2022 a new function was introduced to expand/collapse the Advanced Search panel. It created some confusion as some users did not know how to expand the Advanced Search panel when it is collapsed. We would like to request adding a new configuration option to disable the expand/collapse control of advanced search panel to resume the original UI. 

Using advanced search

The expand/collapse control of advanced search panel is causing confusion to some users.

Enable the Purchase request form link in Primo full record view to be hidden (VE/BO)

VE/BO

Enable the Purchase request form link in Primo full record view to be hidden so that those with permission to access it can but through URL link only. For the 'Purchase Request Form' option we can fill in the form that's available inside Alma, and/or a form in Primo. However if we want to make the form available in Primo then the link to the form appears to all who have access to it in the full view of the record. With this enhancement we will be able to suppress that link from appearing, but still make the form accessible to people in that patron user group with permission to access it using only the URL for the form. 

Currently the link will appear for ALL in that patron user group, however, our patron user group Staff includes not only librarians, but also all university staff, we want to be able to give librarians the option to complete the form in Primo as it's easier for them to quick access/more likely to be using that interface whilst hiding it from all other staff.

Cannot find ability to hide in CSS and would make the process easier for librarian staff than having to access alma to input forms.

Option to include Email in the 'Share' button functions in Primo 'Actions' (VE/BO)

VE/BO

Please add the option to e-mail into the 'Share' button in the full record display so that institutions have the option to minimize the number of action buttons in the Send to section. Currently, in Primo, there is a 'Share' button that gives a selection of sharing options that highlight social media sharing and there is a separate 'Email' option. We would like for email to also be included as an option in ‘Share’ as well as leaving the separate Email button option to provide a choice and flexibility. In many other online instances, share would include an 'email' function as well.  

Better matches functionality found elsewhere online and gives options to reduce number of buttons on full record screen.

Option to add in a relative start date for the Not Needed after option on Patron Physical Item Request form, preventing an earlier date from being selected (VE/BO)

VE/BO

Provide an option in the Patron Physical Item Request Form configuration to select a number of days from today to be the earliest date that a patron can select in the 'Not needed after' option. We would be able to put in the number of days from today where the start of the Not Needed after date (e.g. 3 days after today) could be set to avoid people putting in todays or tomorrows date. 

Currently (despite any wording changes we make on the form to make it clearer) todays date, or tomorrows date is often selected on the 'Not Needed After' field in the Patron Physical Item Request form by our patrons. We believe that confusion comes from assuming that they will receive the item sooner, selecting a 'delivery' date or be prioritised in the holds queue for the title. We feel that if we can control the first date that they see, it may nudge them more effectively into understanding the purpose of this field without the need for a length field explanation.

This has caused much confusion for our staff dealing with the holds shelf and expired holds shelf who are often looking for the item the next day or students who don't understand why their request has been deleted so soon.

Add the ability to customize the RTA display of the call number (VE)

VE

We would like the ability to edit the Primo VE RTA field to add Call Number: in front of the call number in the RTA field. 

See example. https://wisconsin-uwosh.primo.exlibrisgroup.com/permalink/01UWI_OSH/h79h4g/alma99836493502126

We went live in summer of 2021 with Primo VE. Prior to that in old Primo we had prefixed the word Call Number: to the front of the call number in Primo.
When we went live most customizations were not quite available for the holdings fields or the RTA in norm rules, search or display. From what we can see functionality within Alma/Primo doesn't exist to enable us to edit the RTA field.
We ask because it does help bring visual attention to the call number for our new undergrads.

Implement CORE Recommender on the Full Record Services page (VE/BO)

VE/BO

The CORE recommender is a plugin for web interfaces and repositories that provides suggestions on relevant OA articles to the one currently displayed. Its purpose is to support users in discovering articles of interest from across the network of open access repositories. CORE has validated that all recommended articles are free to read and can be accessed without a paywall. Thus, the CORE Recommender increases the visibility of open access content. CORE provides their recommendation service for free.  

Use Cases: At the end of this repository item , you can see a list of similar publications suggested by the CORE Recommender

Also succesfully implemented in a Primo test (!) view:
https://explore.lib.uliege.be/permalink/32ULG_INST/4n43oa/cdi_scopus_primary_633965877
https://explore.lib.uliege.be/permalink/32ULG_INST/ovforp/alma990001883220502321
(although the way we did it may affect the time necessary to display of Get It and View It)

Displaying CORE recommendations on the right instead of at the end of the Full Rercord Services page may be better.

Support "exclude" option for Resource Types when creating Specialized Search Scopes for CDI (VE/BO)

VE/BO

When configuring Specialized Search Scopes for CDI only 5 CDI resource types can be selected in Primo VE, and Primo BO does not include this functionality at all. We want to change the system so that unnecessary resource types can be excluded. Impact of Problem: Regarding "Exclude eBooks from CDI Results - Phase 2 (NERS #6702)" - In Phase 1, all books were excluded from search, but after Phase 2, some books remain in the search results. To exclude books for this reason, we would like to set the "Specialized Search Scopes for CDI" with a limited number of CDI resource types. But the maximum number of resource types that can be selected is too few, so we would like the system to be changed so that unnecessary resource types can be excluded. The ability to make these CDI adjustments should be available in both Primo VE and Primo BO. Expected Outcome: This function allows scopes to be more limited to specific resource types. Idea exchange title: Additional Function:Excludes unnecessary resource types in Specialized Search Scopes for CDI  

Holdings matching behaviour (VE)

VE

There is currently a big difference in how CDI records match against print and electronic holdings. This is a CDI article that we have online access to: https://llr.primo.exlibrisgroup.com/permalink/44NTU_INST/eii82o/cdi_proquest_miscellaneous_58277502. The electronic holdings match well: links that don’t provide coverage to the issue that this article is from are filtered out. The print holdings don’t match at all: holdings for the whole print run are displayed, exactly the same as they do when looking at the title level record for the journal: https://llr.primo.exlibrisgroup.com/permalink/44NTU_INST/1mqln2/alma9917568266607181. I would like to ask for 3 improvements: 1) Publish physical as well as electronic holdings to CDI: this would make CDI aware of a library’s complete stock range, not just what it has online access to; 2) If CDI is made aware of a library’s print holdings, it should mark records as available in filtered search if there is no access online but there is a print version on the shelves. At the moment all such records are hidden in the expanded search; 3) Print availability should be adjusted to suit the context of the record you’re looking at. A simple display would be enough: if a library holds the journal that an article comes from in print, but not that particular volume, don’t display any print holdings. If it does have the volume on the shelf, display information about the full print run. As a bare minimum, we would like to be able to turn off the display of print holdings, as we would rather have no information about print in the full record than information that is misleading and confusing. 

I have attached as a Word document some screenshots to illustrate the problem.

Add 'find an item on the shelves' tool to Primo (VE/BO)

VE/BO

Many libraries have third-party tools integrated with their resource discovery platform that enable library patrons to be directed towards items on the shelves, using floor plans, directions from a given point, or other approaches. This is in response to the common and widely reported difficulty with finding physical items, especially when students are new to a university library or where there are architectural limitations that dictate the layout of shelving in an unhelpful way. However, not all libraries have the skills, staff time or budget to integrate an additional product and it would be extremely helpful if the functionality were built into Primo without the need for any third-party applications. We want to be able to offer in Primo a visual floor plan-type directional function, drawing on the collections data, which will aid our users in tracking down physical items on the shelves. 

For example, a new student cannot find a print book they need for their assignment reading.  They search in Primo and see the shelf mark but still aren't sure where it is, but the item finder points them towards the correct floor and bay of shelving.  They are able to locate the book.

For libraries using a separate item finder tool with Primo already, they might be able to make cost savings and retain the functionality they need.  In institutions where no such tool is being used yet, student experience would be improved significantly by making one available, inbuilt in Primo.  Also, there would likely be a reduction in the number of directional queries from students and potentially from academic staff, enabling library staff time to be utilised for other purposes.

Display 3 items from the three dots menu in the My Favorites (VE/BO)

VE/BO

In the list of saved records in the patron account it is not clear that there are actions that can be applied to multiple selected items in bulk. Considering UI responsiveness, please display all action items at the top of the page instead of hiding them behind three dots, or display them as they are for the Brief Results: 3 items shown and the rest hidden under 3 dots icon.  

Currently, a patron cannot know what actions are available for a selection of their favorites through the hidden menu in the Favorites screen.

Permalink as added Action to My Favourites action menu (VE/BO)

VE/BO

Permalinks are currently only available for individual records. It would be useful to have a similar link option for a bulk selection of Saved Items in the My Favourites action menu. This would allow for users to select multiple items in My Favourites, such as many resources organised by label, and provide the permalink to this targeted set to another user. Clicking on the link would generate a basic search into Primo containing only those specific Saved Items. 

Use authority identifiers for search and display links (VE/BO)

VE/BO

In Primo record details, clicking on the hypertext lateral links generates a new query based on the information in that text string, such as subject term and author name. In many cases, the results are too broad and inaccurate. As authority identifiers are present in Alma records, the identifier(s) for the relevant authority record(s) should also be available to Primo (by indexing and publishing). This would allow a patron to conduct a search query for accurate records linked to that authority, and also to use the hyperlink in the Primo full details by that underlying authority identifier, rather than the text string. We should be able to define which repository we use to correctly match datas. 

One index for browsing call numbers (VE)

VE

Currently in Primo VE, call numbers with different call number types are browse searched separately, using different call number indexes. We have three call number indexes which cause confusion amongst clients and library staff i.e. shelf number – dewey, shelf number – medical, shelf number – other incl. literature. We understand there is a different filing routine for each of these types but our clients and library staff would benefit greatly from Browse Searching one index for call numbers in Primo VE instead being confused by several options, even after renaming them. One Browse Search index would eliminate training on and the explanation of the different call number indexes and where the exceptions e.g. for languages are. They won’t have to think about which index their call number belongs to before Browse Searching their call number. 

Title 'starts with' in Advanced Search delivers no search result for non-latin languages (VE)

VE

In Primo VE an advanced search with the search type title 'starts with' does not deliver search results as long as the search string is placed in MARC21 880. 880 fields are associated fields for e.g. the title statement field MARC21 245. This is a main disadvantage for CJK-languages and also for the languages arabic, hebrew, greek and cyrillic. MARC21 880 contains the Alternate Graphic Representation, so none of these languages is searchable with their original characters. ExLibris rejected a case with the explanation "the current behavior is by design and the fields for "starts with title" will remain as they are now - MARC21 130 for journals and 245 for the rest. In other words, "starts with title" is not planned to include 880." With Primo BO it is possible to add MARC21 880 to the index "starts with" in the advanced search, so for parity issues, it should be possible for Primo VE as well.  

Enhance pickup location lists for libraries in Resource Sharing and Purchase request forms (VE/BO)

VE/BO

Nowadays the lists of libraries which appear in the pickup location option in Resource Sharing request and Purchase request forms for Primo VE can not be customized, which is very disturbing in Institutions or Library Systems, which hold several libraries. We ask that each institution could customize each pickup location list in order to: 1. list the libraries in a more convenient way (e.g. alphabetically or according to subject or according to address, etc.); 2. exclude some libraries from the list. This functionality should also be fully implemented in Primo BO. 

Discovery Import Profile (VE)

VE

Import profile enables to define an external data source, apply normalization rules, configure delivery links, and schedule the execution of the import profile job. The protocols used to retrieve the file containing the records are upload, FTP or OAI. If the protocol is OAI it’s possible set only oai_dc and qdc formats as metadataPrefix. The metadataPrefix arguments are used in ListRecords, ListIdentifiers, and GetRecord requests to retrieve records. So, if a local external source has a different metadataPrefix (for example METS, MAG, DATACITE, RDF ...) can’t retrive via OAI-PMH protocol. In Primo VE this is a great limitation. Currently in Primo Direct it’s possible set any “metadataPrefix”. The request di enhancement is: make it possible set any metadataPrefix in protocol OAI.  

Improve the title display configuration to allow statement of responsibility in display (VE)

VE

We want to include the Statement of Responsibility (245*c field) as part of the title field displayed in Primo VE. This can currently be configured but requires using one of the very limited local fields added separately to the brief results display, or impacts Citation generation if added directly to the title field. This option to display this key title and author information should be available out of the box so that sites do not have to use a local field or impact other Primo functionality. 

Allow the display of the Statement of Responsibility (245*c field) as part of the title field in Primo VE without impacting on the citation title.

Currently not able to display all parts of the title field as the title within Primo VE without impacting on the citation title.

CDI availability calculation (VE/BO)

VE/BO

For Central Index records (managed by CDI), Primo, on the brief results page, indicates whether a record is available online based on the Alma electronic holdings file that is published nightly to the Central Index. For Primo VE it is only on the full record page that full actual availability for the record is calculated by Link Resolver to indicate whether Alma can provide electronic, digital, or physical services and updates the availability statement dynamically accordingly, with the availability statement display static for Primo BO. Current behaviour means available resources are also not visible to patron users as "Show only" and "Available in the libraries" facets are unable to retrieve all resources available in the library. In general, all facets can't filter correctly CDI records if these have an "non-online" availability. Expected outcome: The availability for electronic, digital, or physical services of Central Index record is calculated and showed in the brief results page and included in facet values and counts. 

Available resources are not visible to patron users. "Show only" facet "Available in the libraries" is unable to retrieve all resources available in the library. In general, all facets can't filter correctly CDI records if these have an "non-online" availability.

Include Holdings library, location, and call number for physical items in Excel / CSV Export (VE)

VE

The Export to Excel option is a great enhancement for Primo record actions that is very valuable and much used by researchers. However, one critical area of data is not available for export in Primo VE: physical holdings information, such as Holdings Call Number and Physical Location. This data can be added to the AVA field for Primo BO, but there is no equivalent configuration for Primo VE. Physical Location and Call Number from the Holdings Record should be included in Excel export in Primo VE.  

Researchers often Export lists of records that they then wish to find on library shelves -- but they need the Library Locations and Call Numbers to do so. We have received many complaints from researchers unhappy to find this info missing from their exported Excel files. Adding Physical Location and Call Number to Excel Export fields in Primo VE would more completely meet the research needs that this functionality is designed for. Note that records emailed from Primo VE include an availability statement with location/call number details for physical materials (ex: Available at Lockwood Library General Collection (PA3133 .G68 1983b)), but Excel export is the preferred method for many researchers, and the output is more useable. Separate fields or the single statement would be helpful.

Note: An Idea Exchange proposal to "Include call number for physical items in Excel / CSV Export" was opened in August 2020 and as of January 2023 has 149 votes.  

Combine Two or More Recent or Saved Searches (VE/BO)

VE/BO

Searching is often an iterative process; researchers build upon their search terms based on the results they get, refining and narrowing results. The facets in Primo work very well to help users focus within their results. Often researchers perform several different searches, with several sets of results, and they discover that they are really seeking some combination of these several sets -- they may need a sort of Venn diagram which looks for commonalities between the sets, or they may need to exclude the results of one set from another. Many other tools allow users to combine two or more search results, but Primo does not. In Primo, users have to formulate an entirely new search, puzzling out which exact terms and limiters led to their sets and how they can manually fabricate their desired intersections and combinations -- which is extremely difficult and time-consuming! If only Primo had a Combine Searches functionality, it would make the tool much more helpful for researchers. It would also underscore the appeal of Primo as a sophisticated search tool for all users, including more advanced academic researchers. 

Users should be able to select sets from their Search History or Saved Searches and combine them using standard operators such as AND, OR, and NOT, with the system then processing and presenting a new set of search results based on the interaction between the selected sets. Other Proquest search tools include this functionality, with documentation available at (for example).

Combining searches is a very common, useful function in many library search tools. Not having this ability in Primo makes searching more time-consuming and challenging for researchers.

Enable Public Notes display for content within Database-type collections (VE/BO)

VE/BO

It would be very helpful if Public Notes could be displayed for individual content (articles, etc.) within Database-type collections. Currently, Public Notes for Database-type collections can only be placed on the record for the collection itself, and they are not displayed on individual content. So if a user searches for the name of the database (such as ProQuest Congressional Hearings Digital Collection: Part A (1824-1979)) they can see the Public Note below the View Online link -- but if they search for an article held within that collection (such as Committee Business. Congressional Hearing, 1980-07-31), there is no public note displayed with the View Online link. The info we communicate in Public Notes is most often needed for accessing the individual content. This functionality is in place for Full Text and Selective type electronic collections that include portfolios. Public Notes can be placed at the individual portfolio level or at the collection/service level to display on all portfolios. This functionality would be very helpful for Database-type collections as well. When public notes are added to a database-type collection, these notes should display not only at the database record level in Primo but also at the article-level for content held within these collections. 

It is very helpful for institutions to display public notes about collections within Primo -- these notes can provide important information to the user about special instructions needed for specific collections and other specialized help. These notes need to be displayed at the point that users see and will follow links into the collection -- that is, at the article level. Public notes can be displayed at the article/content level for full text collections, but not for database-type collections. For database-type collections, the notes only appear at the database-level, which is not the level from which users typically link into the collection. Enabling public notes at the article-level for database-type collections would bring the functionality of these collections more in line with the existing functionality of full text collections, which would be a boon for users.

Allow greater flexibility in number and display of Resource Recommender entries in Primo (VE/BO)

VE/BO

We can create multiple types of Resource Recommenders, but if multiple items within a particular type match the tags a user searches for, multiple items are returned from a single Recommender and some Recommenders are hidden. We would like to be able to highlight one result from each matching Recommender. We would also like the option of displaying 4 instead of 3 entries when there are 4 or more suggested resources. For example, display in Primo seems to support highlighting 3 items from Resource Recommenders in brief results, with additional items displayed under a link to "See all [#] suggested resources." We currently have five Recommender types: Library Guides, Databases, Custom recommender for Librarians (enhanced version of Person recommender), Custom recommender for Collection Discovery, and Website. No matter what type we move to the top of the list, if the tags are assigned to multiple items within a recommender, then 2 items may be displayed from the 1st or 2nd Recommender, with no results from the 3rd, effectively hiding the 3rd Recommender within the "see additional" link. We would like to highlight one result from each Recommender type, a Library Guide, a Database, and a Librarian, in brief results. Instead of highlighting two results from one Recommender and one result from a second Recommender with all other Recommender type hidden, the three available Resource Recommender slots in search results should highlight one from each of three Resource Recommenders, if three are used.  

We are pleased to be able to create multiple different types of Resource Recommenders, and we make great use of all of them. All the types are important to support the needs of different researchers, who benefit greatly from these referrals to Databases, Research Guides, and Librarians, while the Collection Discovery and Website recommenders allow us to highlight and market the Libraries collections and services. However, currently only two types can be displayed in initial search results -- even though there are three spots for Resource Recommender entries. The third type is always hidden under the "See all ... suggested resources" menu, so researchers are not even be aware that there is another type of resource to help them. Being able to highlight one result from each of the three top priority Resource Recommenders would make more types immediately accessible to the researchers, better filling the needs of all types of researchers. It would be even better if the default display could be expanded to four, with four different types able to be highlighted.

Display of fees with statuses "transferred" and "Closed" (VE/BO)

VE/BO

The Primo UI is the only access point for Patrons to view their library account; therefore, they must see their fees there transparently. There is a 2023 Roadmap item only for Primo VE to display fees beyond 'active' status, showing 'transferred' and 'closed'. But it is also important to have the possibility to show these across all Primo sites and also to expand this to be able to define additional fee statuses in the configuration menu. This would enable more transparent information to patrons, incorporating additional statuses such as *invoiced*, *unpaid*, *partial payment*, *paid/closed*, *storno*, *write-off* or *transferred to the debt collection*. 

Improvements to Newspapers Search interface and functionality to better match Primo Search (VE/BO)

VE/BO

The Newspapers Search interface is lacking in many features and functions that are present in Primo Search. The system should be improved so that features and functionality are consistent across these interfaces, and it is possible to search in Newspapers with the same granularity and specificity as other Primo Searches. Needed elements include: Advanced Search; ability to save, pin, and act on multiple records; inclusion in Search History; user-friendly record IDs and permalinks; search term passage between Primo Advanced Search and Newspapers Search; troubleshooting tools such as CDI Activation Analysis tool. It should be possible to search in the Newspapers Search interface with the same features and functionality as the Primo Search interface, or at least the community should have a better sense of ongoing development and even incremental improvements. 

Users rely on common search functionality (such as Advanced Search) to accomplish their research needs efficiently and effectively. They learn to use Primo and appreciate its functionality. Newspapers Search currently presents many obstacles to efficient and effective research because it lacks core functionality; users can not search in Newspapers as they can in Primo, and this is confusing, challenging, and disappointing to them. Often they seek other routes for Newspaper content because of the system problems.

Ability to configure whether Links Menu links open in a new browser tab (VE/BO)

VE/BO

Functionality requested: Ability to configure whether customer-defined links in the Links Menu open in the same browser tab or a new browser tab. Business reason: Currently in the Links Menu out-of-the-box links open in the same browser tab and customer-defined links open in a new tab. This results in an inconsistent user experience of the Links Menu, where different links will exhibit different behaviours. We would like the ability to configure customer-defined links to open in the same browser tab. Making all links open in the same browser tab by default, or allowing administrators to configure them all to open in the same tab, would improve the accessibility of Primo. As noted in the WCAG 2.1 guidelines ( ) “it is better not to open new windows and tabs since they can be disorienting for people, especially people who have difficulty perceiving visual content.” Where links do open in a new tab, there must be a warning to advise users that this is going to happen ( ) and this warning is difficult to give for the Links Menu. Including the text ‘opens in a new tab’ in the name of the link button is unwieldy and would make the Links Menu harder to read. Including the warning in the hover text presents additional accessibility issues ( ). All Primo institutions would benefit from the ability to make their Links Menu more accessible to their users. This functionality has been suggested previously in the Idea Exchange:  

As an administrator, I would like to be able to ensure links open in the same tab in order to enhance the accessibility and consistency of Primo for all users. Good accessibility practice requires that links do not open in a new tab unless absolutely necessary, and so this enhancement would allow us to make Primo more accessible.

As a patron, I would like all links within the same menu to behave the same way, because this would make my experience of Primo more consistent. If all links open in the same tab then I can predict how each link will open and I am less likely to be disoriented. If I decide I want a link to open in a new tab, I can actively select this behaviour for myself by using a command on right-click - Open in a new tab or window) or a keyboard shortcut (e.g. Ctrl + click). 

Ability for users to change facet sort on the fly (VE/BO)

VE/BO

Facets in Primo can be set to sort by size or alpha-numeric in the View configuration in Alma. We would like users to be able to change the sort method on the fly in Primo, since the chosen “default” sort isn’t best for all situations. For example, on a Creator facet that is sorted by size, a user may wish to re-sort by alpha in order to see name variations together or to more quickly and easily find the creator they seek. Researchers use the facets to help narrow their search results. Libraries pick a default option that seems most generally useful in a broad number of cases, but for any individual researcher in any individual search, the other sort option may be more helpful. This functionality is very common in other databases and search tools. We find many examples in different ProQuest databases, for example, where expanding a facet list produces a popup window in which the list can be sorted by different fields. For example, in Early English Books Online, users can sort the Author facet list by Author or Count (see screenshot) or other facets alphabetically or by count.  

Note that a related Idea Exchange proposal has 378 votes

Enable greater granularity in display logic for Full Text services within the same interface (VE/BO)

VE/BO

Institutions may have access to the same single title in multiple collections across multiple interfaces, resulting in the display of so many links within the ViewIt area that users become confused and irritated. The current solution to this problem and decrease the display of duplicate links is to use Discovery Interface Display Logic to hide Full Text services within the same interface, resulting in the ability to select and display a single link each from JSTOR, EBSCO, and Gale instead of multiple links from each. An alternative to hiding services by interface is to hide services by collection. There are two problems with the current functionality that should be corrected. 1. It should be possible to hide services with greater granularity and the use of more complex logic; for example, to hide based on Interface but indicate exceptions for collections that should always be displayed. For example, it should be possible to hide service Full Text with Interface value Galegroup if service exists Full Text with Interface with value Galegroup to display only one link for content that is duplicated across active Galegroup collections, but also to indicate collections that should be excluded from this rule. The use case for this is to enable the display of special facsimile collections along with a single aggregator text collection. 2. It should be possible to include coverage consideration within the display logic rules, so that collections with different coverage dates for the same content could be displayed even when the collections are otherwise hidden by an Interface-based display logic rule. These improvements to display logic configuration are needed because applying display logic at the collection level is too complicated when there are many collections within an interface that hold the same content but with differing presentation (i.e. facsimile or text only) and coverage. We have found that attempting to hide Full Text by Collection instead of Interface results in too many links being displayed. The most workable solution is to hide service by Interface but with additional rules. Libraries should be able to add additional rules and exceptions to display logic, especially for hiding Full Text services within an Interface. 

The inability to more granularly apply Discovery Display Logic rules for collection display in Primo results in one of two problems for users: (1) if display logic is not applied to hide Full Text services for collections within the same interface the user encounters too many links and becomes confused and irritated and unsatisfied with the Primo discovery experience; (2) if display logic is applied too broadly at the Interface level, without special exceptions, the user may miss out on collections that have special features or more extensive coverage that would be beneficial to their research. In both cases we run the risk of users having either a bad or an inadequate discovery experience which can push them toward other sources (such as Google) for their research needs.

This request is similar to Idea Exchange proposal "Improve Display Logic in Alma Uresolver to show all variant coverage statements in a collapsed menu" which currently has 145 votes. The use of collapsed display of coverage could be an alternative and acceptable approach to this problem.

Display multiple addresses in Personal Details tab within My Account (VE/BO)

VE/BO

Users may have multiple addresses in Alma. The Personal Details tab within My Account only can display one address, the preferred address. The display of multiple addresses should be configurable. Users often have multiple addresses (home, work etc.). When users are unable to review all of their addresses, one or more addresses may be incorrect, consequently going undetected by the user. When selecting addresses for Personal Delivery, items may be sent to an incorrect address. This results in poor customer service for the user and losses for the library. Primo should allow the display of multiple addresses in the Personal Details tab within my Account to give users greater awareness and ownership of the details on file for them.  

Add ability to filter to current journal subscriptions/holdings (VE/BO)

VE/BO

When searching for journals/serial publications, researchers often need to focus on the most current content only. Primo serves this need well for articles and monograph publications, where the Publication Date is an accurate indication of currency. Publication Dates for journals, however, indicate only the start or end of the publication as a whole and there is no way for a researcher to easily determine an institution's actual coverage/holdings. An additional option for searching or faceting on coverage dates, including "open" for currently received is needed. Users should be able to add "currency" and "coverage dates" to searches in Primo, for both electronic and physical materials. 

A researcher who is searching for current content, including all types of publication, will try to limit searches by Publication Date or by sorting by Date - Newest. These strategies don't work for journals, so the researcher may miss these kind of publications in their quest for currency. When a researcher limits their searching to journals, there is no way to quickly and easily filter to what content is currently published and/or held.

Publication Date is not an adequate indicator for researchers who need to consider currency when searching for journal/serial publications, since the publication date does not take into account the ongoing nature or publication nor local coverage and holdings.

Add the "Library" index in the advanced search (VE/BO)

VE/BO

Library is only available as a facet. It would be useful if "Library" could be also available in the advanced search. This type of research is used more than one would think and our patrons regularly ask why it is not possible to limit the results directly at the library level, using this search mode. In addition, this would limit the side effects of the FRRBisation process (only libraries that have an item of the preferred record appear in the Library facet).  

Show Journal Coverage Dates in Brief Results and Journal Search for Physically Held Materials (VE/BO)

VE/BO

Coverage summary by year can be displayed in Primo results list for electronic journals; this summary is also needed for physical journals. Researchers benefit greatly and save valuable research time by being able to view electronic journal coverage summaries in Primo results, without the need to expand to full record view. Unfortunately, the lack of equivalent coverage summaries for physically held journals makes it more likely that researchers will overlook or misinterpret a library's physical holdings. Some researchers assume that there are no physical holdings; others assume that the physical holdings are complete; all are annoyed and puzzled by the need to expand to full record view to view physical holdings when that is not required for electronic. Summary holdings for physically held journals should display in Primo results lists as they do for electronic journals. The holdings could be taken from the Summary Holdings field of the Holdings record in Alma.  

In 2021 there was introduced the option to display coverage summary by year in its availability statement in the results on the Library Search and Journal Search pages for electronic journals. This functionality should be extended to include physical journals with holdings.

Only show "starts with" for relevant fields in Advanced Search (VE/BO)

VE/BO

Advanced Search "starts with" functionality is only available for title and call number searching, and not all the indexes displayed in the Advanced Search menu. However, the “starts with” option is displayed when a user selects one of these other options, although it isn’t available, and selecting “starts with” will in fact push the user to a Title search. Moreover, the user then only has the option to select Title or Call Number unless they know to de-select the “starts with” option or clear their search. This is extremely confusing and not user-friendly. “Starts with” should only display when it is an available option. When a user selects and index like Author or Subject for which “starts with” is not an option, only “contains” and “is (exact)” (and “equals” when/if available) should be displayed. Selecting an index other than Title or Call Number should suppress the display of “starts with.” A tooltip has been added to the “starts with” search operator to indicate that “This search type is available only for Title and Call Number fields” – but a tooltip is an insufficent remedy for several reasons, as noted in Idea Exchange comments at Among other problems, the tooltip is not visible on mobile and may not display consistently on different browsers, and it does not address nor correct the problem of users being trapped within the Title/Call Number option. We also do not agree that it is a benefit to display the search operator for other fields to inform the user of its availability – users who select fields in which it can be used will see the option, and those who see the option when it can’t be used will assume incorrectly that it simply will not work at all. Only search operators that can be used should be displayed for each search index in Advanced Search. 

The Idea Exchange proposal has strong community support with 146 votes as of 1/25/2023.

Add and configure tooltips in the Get It / View It sections for better accessibility of Primo (VE/BO)

VE/BO

Primo displays tooltips and allows them to be updated using the View Labels Table. Unfortunately, no tooltips can be displayed in the Get It and View It sections. For example, no message is displayed when the mouse is moved over the Request button or the Cancel button of the request form. The display of this tooltip would indicate the action generated by a click on the button. This indication could be read by text reading software for visually impaired people. In conclusion, this would improve the accessibility of Primo for this category of user. 

Add ability to change default sort of results per view (VE/BO)

VE/BO

The default sorting per 'Relevance' often does not meet the patrons' expectations (frequently, the preferred default sorting is 'Date - newest'). We should be able to define for each Primo view a default setting for the search results sorting, and the patrons can pick another setting tied to their account. When a patron logs in, their preference will be activated (like other parameters under their 'Personal details and settings' area). 

If the search results were sorted by the most recent publication date, it would help users realize that we have the most up-to-date editions of works and create greater satisfaction. It will also help stop users from requesting older editions in our Research Reserve as they will realise that newer editions are on the open shelves. This recently was raised as a complaint at the Law staff-student meeting. The default sorting option should be set, like the interface language and the number of hits per page parameters – a default per view and override for each user individually.
Also, there is a very similar IdeaExchange which got 162 votes:

Adding Facets to Database Search page (VE/BO)

VE/BO

By adding a 'Facets' pane to the Database Search results page, consistency between the different search type's results will be improved and users will be able to post-filter Find Databases searches. For example: a user would be able to filter by both subject AND resource type as used to be possible when the Metalib interface was used for the Databases A-Z list 

Ability to filter by both resource subject and resource type. We had this functionality previously.

Consolidate My Library Card display of loans/requests from all institutions in the network (VE)

VE

Improve the Primo VE My Library Card to display a single, multi-institution view of all of a user’s loans, and, a single, multi-institution view of all requests. In a consortial environment, Primo VE's My Library Card currently separates a user’s loans and requests by Fulfillment Network (or AFN) institution on individual vertical tabs with the institution name. It would be much easier and efficient for consortial users to manage their loans and requests if all items were displayed in a single list for all loans and a single list for all requests. Ideally, these consolidated lists would be sortable by title, current due date, loan/request status, and item’s home institution. Loans and requests would each be in their own list in a separate horizontal tab (as they are now). There is an existing Idea Exchange with 723 votes that has been Under Review since April 19, 2022. 

In a consortial environment, users often do not know which institution in the network an item is from.  They place a request from the network and may not care whose copy they receive.  Especially for power users with many items, searching through each institution tab in their Library Card to find a particular item is frustrating to them and may lead to items not being returned/renewed on time because the information is not readily available. The current display of items borrowed also makes it impossible for users to renew items from different institutions at the same time. 

Add Subject Added Entry Uniform Title to the subject browse index (VE)

VE

Currently, subject added entries for uniform titles (MARC tag 630) are not included in Primo VE’s subject browse index. We would like Primo VE to include 630 fields in the subject browse index to restore the same functionality that was present in Primo PBO. The 630 field is defined as “A preferred title used as a subject access point”-- . Two examples are: 630 00 $a Aesop's fables and 630 00 $a Bible. $pActs $vCommentaries.  

Adding 630 fields to the Subject Browse search would be useful for patrons by providing expected options for subject searching. 630 fields are already included in the Advanced Search (subject contains, is exact, starts with). Most patrons won't know that 630 fields are excluded from the Subject Browse search. Including 630 subject fields in both keyword and browse searching would provide a more consistent user experience. Other library catalogs, including the Library of Congress catalog, include 630 fields in subject browse searches.

Additionally, complex subject headings can be challenging to get right in a keyword search. Browse searching can make it easier for patrons to find information on the topics they are researching. Finding books on biblical passages is easier with browse searching.
The format for biblical passage subjects is:
Bible Book--Chapter in Roman numerals--Verse(s) in Arabic numerals.
Example:
Bible.--Luke, XV, 11-32--Relation to Genesis.

One of our research librarians notes that complex subject headings (especially those with LC Free-Floating Subdivisions) are tricky to get right as keyword subject searches no matter which modality (contains, is exact, starts with).  Browse searching can be to be easier to get right, once you know the syntax.

Filter Resource Type by Magazines in Primo (VE/BO)

VE/BO

Give users the ability to distinguish between journal and magazine articles when searching in Primo. 

Adding a magazine limiter would allow users to more easily identify and search directly for magazine articles. Currently, magazines are grouped in "articles" which can be confusing, particularly if journal and peer reviewed articles appear at the top of search results.

This feature would allow students with varied and diverse information needs to better navigate and discover relevant materials in Primo. This inlcudes users completing advanced coursework and basic skills coursework. In some of these cases, journals are not appropriate or relevant for the assignment or the user's need. This feature would serve students in a variety of institutions, including community colleges and 4-year institutions. We've seen this request in Idea Exchange ( ), so it's clear that other libraries would like to see this feature become a possibility.

Search results after_div for customization (VE/BO)

VE/BO

In Primo, facets can appear on the left or right, with the side not chosen appearing as an empty column when the browser window is wide enough. This customization would allow for institutions to use JavaScript to create a Primo directive that would place HTML in that open column. 

knowledge panels, libguides search results, FAQ search results, and/or yewno relate subject tree replacement.

DEI Network Zone Exclude Tool - enhance NZ and IZ management options (VE/BO)

VE/BO

in the NZ, I would like to centrally manage my stop list across all institutions within my network zone. I would also like the institution to have the freedom to make changes/edits/manage the list if they choose or reconnect to the centrally managed list. 

An expansion of the current Exclude List tool ( and ) would allow subject terms to be controlled at the Network Zone instead of the Institutional Zone (IZ). Institutions should be able to inherit a centralized stop-term list or control their own as explained here under "Define Code and Mapping Tables Centrally" ( )

DEI Exclude Tool - allow substrings for text matching, not just exact text matches (VE/BO)

VE/BO

The current tool performs a literal suppression of subject terms through exact text matching. This is problematic for complex subject headings where problematic language is “contained” in the rendered subject heading. To take as an example, if the term “illegal aliens” were listed in the current DEI Exclude tool, the following scenarios would result. While this tool handles the most egregious examples (and does not hide these results from search), it does not suppress or transform a subject heading unless the term is the only string in the PNX:display:subject entry. More importantly, it does not remove problematic language used in facets on the primary search result page. Example Subject heading. Suppression of term in full display illegal aliens. yes illegal aliens - Canada. no Children of illegal aliens - no Education-Law and Legislation While libraries have control over their local metadata, they do not have control over incoming CDI metadata. Many institutions have included language in normalization rules for local data to transform subject strings to more culturally sensitive language. While it is understandable that the tool was meant to handle the most egregious/aggressive of terms, it does not have the level of granularity for institutions to manage. In essence, libraries include incoming occurrences, only to find other substrings that have to be added and redeployed.  

It would be helpful to add the following syntax to handle some measure of stemming at the display level. This is not an ideal solution, since it removes access points from the display, but it may address some of the most egregious language and associated phrases.

Subject term - string literal.       illegal aliens
Subject term - subheadings.     illegal aliens - %
Subject term - bi-directional     % illegal aliens %
wildcard  

Add a DEI Term Substitution Tool (VE/BO)

VE/BO

As an institution, I want to substitute offensive phrases in subject metadata for more culturally appropriate/sensitive terminology within the Primo display. Ideally, these terms and their substitutes could be managed at the network zone level to support centralized management with an institution’s ability to customize/add terms to the inherited code table. Primary metadata generated by the author or specific to the work (such as chapter titles, title, author, etc) would not be eligible for substitution, but third-party assigned terminology (subjects, keywords) would be eligible for term substitution. (similar to the current DEI exclusion tool). The ideal function would examine strings in the <pnx:subject> area and perform a replace() function with the subject terms before rendering the interface. This functionality would act in a similar manner / extension of the term exclusion tool with the additional proposed functionality: Exclusion of specific data source codes or ALL (this would allow the inclusion of CDI metadata, but preserve specific data sources from historical or special collections)  

MVP - Phrases would be literal substitution of incoming to transformed phrases, such as those in the example below.
-----
Subject term - string literal     |.     Illegal aliens.     |.     Undocumented immigrants
Subject term - subheadings.     |.    Illegal aliens - Canada.    |.    Undocumented immigrants - Canada
Embedded subject terms.    |.    Children of illegal aliens - Education-Law and Legislation.    |      Children of undocumented immigrants - Education-Law and Legislation
-----
Transforms would focus around words/phrases that had space characters around them or were literal string transformations.

Add ability to contextualize offensive terms in UI with a Problematic Terms Tool (VE/BO)

VE/BO

As a user in Primo, when I encounter a term that could be potentially offensive, I wish to display further explanation about the context and use of the term. This tool should be managed in either the institution zone or the network zone. This would follow in a similar vein as the table available for the exclude list, but it would include the possibility of the following fields: Value of term Link to explanatory source Short explanation text blob Image URL Date updated Contact link (either mailto: or https:// link)  

The context tool changes the inline text to a button, and would behave as a tooltip above or below the term (based on code-table or css setting). The button would link to the explanatory source link.  In order to address accessibility concerns, the aria-describedby description would include the text blob of the term. Ideally, an image should be able to be inserted in the tooltip as well as text. ( )

Ideally, the patron should be able to disable context notices or not and that setting should be set as a user preference. Please see example in attached graphic.

Sometimes, it is more important to provide context around the use of a particular subject term than to suppress it. This is particularly the case for historical documents in collection discovery.  Librarians and archivists would like to ‘flag' these words so that patrons have a better understanding of the historical context/use of the term.  While we have direct edit access to materials within our own collections, we do not have the ability to edit incoming subject terms for CDI.  Enabling a feature such as this within the discovery layer would allow the library to keep potentially offensive words within the record, and provide context when necessary, particularly for older articles and content.

Add an Offensive Term Reporting Tool to support reporting issues in UI (VE/BO)

VE/BO

Similar to ‘report a problem’, this feature would enable patrons to submit feedback about potentially offensive content within an institution's holdings and/or article data. Ideally, this feature would follow the same architecture of the ‘Email Result’ function. Again, this should be a feature that can be pushed from the network zone to different institutions or the institution should be able to override/customize this function. Fields necessary for tool configurable in code table to support multiple languages. Form fields/values for popup window should include Intro-text as code table value link to offensive content review policy Short text field for offensive term Longtext field for explanation Email address to send feedback Submission/Send button  

Add a DEI icon and information popup (VE/BO)

VE/BO

We would like an icon or a graphic to be displayed that would describe the process of how metadata is created and supplied. this feature has the following functional requirements: 1. An icon would be added to each record (question mark or other symbol) where a user would hover over to learn more about metadata in details pane. Clicking on the icon displays a box with first-level info as well as a link to second-level info / a more description of the library's policy on metadata creation and/or diversity issues in cataloging. We are suggesting multiple “levels/points of interaction” language options. - Respect local control and make sure this PRIMO option is customizable - Make code table queryable for local customizations. Highly encourage ExLibris to consider adding a commenting/form component to PRIMO where both the local institution and ExLibris would receive feedback (see offensive term reporting tool) Example of what it could look like included in attached screenshot  

First Level - Invitation to Learn More About Metadata/Information about the Record/resource
An invitation to learn more/very generic, general, e.g. Learn more about this metadata; BANNER, UNDER THE DETAILS PANE IN THE RECORD or ICON NEXT TO DETAILS HEADER

Examples of short text might include text with links such as:

• Questions about this metadata? etc. If you want to learn more about the metadata here, or if you have concerns, please click here:

• Where description comes from; if you want to learn more about how [institution] provides description [email/feedback form]

-- Where description comes from: controlled vocabularies, authors/creators, library staff, ExLibris

• Accepting ongoing responsibility for remediation of metadata/records.

Second Level Info would include a link to a fuller statement about critical cataloging (editable by institution)-
-- We acknowledge that there are portions of our catalog over which we do not have control (i.e., CDI)
-- We acknowledge that we are often describing communities of which we are not a part.
-- We acknowledge that some of our bibliographic descriptions may contain racist, homophobic, sexist, or otherwise derogatory and offensive language.

Country of Origin Widget (VE/BO)

VE/BO

I would like to be able to filter/focus search results based on geographic region. The data would originate from author institutional affiliation (or publisher location), data which is available within Book Citation index and the various WoS citation index collections. Ideally, there would be an enrichment process for local bibliographic data that would add these values to the Primo/PrimoVE/Summon Search index. When patrons are searching Primo, a control would appear (see below) where patrons could filter their results to a geographic region or a specific country. A cluster map would present where specific scholarship originates (via author affiliation or publisher). This exposes diversity in a visual way, it enables course stakeholders to view the geographic distribution of author or text cohorts. This could support DEI or decolonization initiatives in library and curricula.  

Match CDI keywords against LCSH or widely used thesauri (VE/BO)

VE/BO

The display of subjects include both controlled and uncontrolled vocabularies. CDI should match against a known controlled vocabulary and sort non-matches into a "keywords"area rather than "subjects". institutions should have a control that enables or hide keywords in their subject facet group. 

Support native IIIF viewer in full record display (VE/BO)

VE/BO

Libraries should be able to publish a link to media as part of their publishing process that would consume a JSON manifest and display media from a digital asset management system external to Primo/Alma. See example here: This would allow users to play video and audio from, for example, Academic Video Online (AVON) or other IIIF-compatible services within the Primo full record instead of linking out to these services. When users are not within IP range or signed in, user should be prompted to login and view video. Justification: reduces patron friction of using audiovisual materials and demonstrates proof of concept for other video providers to provide similar publishing solutions to subscription and purchased content.  

reduces patron friction of using audio-visual materials and demonstrates proof of concept for other video providers to provide similar publishing solutions to subscription and purchased content.  

Subject Facet Expansion / Contraction Trail (VE/BO)

VE/BO

Currently, when a user clicks on a subject facet, they are limiting their search result set by the overall subject term. If the subject term has narrower terms, this limiting may be done multiple times. See attached screenshoot with an example of selecting first a subject heading of “Art” and then selecting the narrow term of “Art, American”. It should be more clear in the active filters area that this contraction of the result set is due to travelling down a subject-related path. Ideally, subject terms might show in a tag cloud above the result set, rather than in a facet at the side of the page.