Round Two Primo Enhancements

Authority record enrichment for Established Headings (VE/BO)

20

We understand that the request is to index 7XX fields from authority records, in addition to 1XX and 4XX fields that we are currently indexing.
We'd like to suggest the following option as we understand this request: Indexing 7XX fields from Authority records the same way fields 1XX and 4XX of authority records enrich bibliographic records in Primo
We understand that the indexing of field 7xx will be subject to the following settings:

• a flag if to index 7XX

• close list of vocabularies to index

for this the evaluation is 20 points

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)

15

In this enhancement we will allow users to view their requests history very similar to the way users are viewing their "Previous and historic loans" in Primo.
This option will be available under configuration (same as done for loans history and also as we know that some customers are using anonymization process in Alma in order to disconnect historic requests from their users as part of their privacy policy)
The evaluation for adding "loans history" (very similar to the existing "Requests history") is : 15 points

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):
https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/36194536-view-user-request-history ; ; ;

Add facets to Collection Discovery (VE/BO)

65

We'd suggest the following option for adding facets in the Collection Discovery:

• adding facets using existing facet component similar to the way it shows in the main search plus option to configure specific facets per each collection

This estimated as 65 points

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)

60

A similar enhancement was already evaluated last year in NERS 7820 Add A-Z to Database Search , in 2023 we also see the request is to add it to the Journal Search as well.
So the evaluation for this enhancement:

• Support A-Z in English 1-9 , others is 30 points

• Supporting also Hebrew, Stroke count / Pinyin and English and Norwegian as exists in Primo is additional 15 points

• Request includes also Journal Search - Additional of 15 points

So in total this is evaluated as 60 points

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(!!):

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

120

We'd like to summarize the suggested solution for this request in high-level and provide estimation for it:

• New option will be available in the User Interface to support the bulk export of search results : we may offer the users to export : current selection, current page or entire results - limited to X results ( X will be determine in implementation phase)

• Users can select to export search results in the following formats: CSV/ Excel , RIS or BIBTEX

• The new export option will be available only for signed-in users ( we can add notification for guests users to sign-in to use this option)

• Users will be requested to fill in the target email to send the exported file to (we may also add the from address using the signed-in main address)

• File will be sent by email as attachment once the bulk export process will be completed, as mentioned this action will be invoked in the background and allow the users to continue to work in Primo while export process is running. As for the time to expect the exported search results - this will be determined in implementation phase.

• The exported file will not display the search results in the same order as displayed in the User interface . Justification for that: users will this exported file to import the search results in citation managers. We plan to invoke light-weight search APIs in both CDI and Local to support the mass export. ( in blended search we may show results sorted by date - all of this will be determined in implementation phase).

Note: there is also performance impact of which fields will be exported in the bulk upload and we will also take this in consideration while implementing ( for example exporting abstracts from CDI) , we will also not include fields that required to invoke delivery call ( for example library location ... )
The estimation for this suggested solution supporting the bulk export: 120 points as this enhancement is highly costs and involve many aspects of system performance and others.

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.

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

20

We would like to emphasize that allowing adding HTML tags to all labels can be a bit problematic as it requires an addition for each and every label in the system, due to the different types of labels that currently exist. Also, a generic solution for all labels may also have a potential of security issues.
In the past we have opened specific labels per request and again the reason not to support this for all is due to the complexity: some labels are dynamic with place holders, some are concatenated , and also as we mentioned we do note security concerns while allowing all labels to inject HTML tags.
Therefore we suggest to have a focused list of labels or specific areas in the system.
In parallel we are also examining the option to support HTML tags in collections' descriptions (this was requested specifically in an idea related to this request -
As agreed we will include :

• Collection description

• Public notes

• Citations disclaimer

• list of additional labels - up to 30

@community - to provide the list
Estimate as 20 points

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

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

10

As we understand, the request here is to add a configuration for setting the way the getit section will be displayed in case of a single location.
Today when there is only one location, we automatically display the items level under getIt.
The new configuration will allow to choose whether to display the getIt at location level or items level, when there is only one location available.
The evaluation for adding configuration to support two options of display in the Get It in case of one location is : 10 points
Note: this estimation is for Primo VE only - this enhancement is planned only for Primo VE. For the Primo BO this request requires changing the Mashup section and Ex Libris are not going to invest development in the mashup

VE

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.

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

40

The examples we found in our analysis were from Ebsco , but we will develop this to support more cases once found and reported.
We would like to estimate this enhancement with the direction we have provided, I believe once we will be in implementation phase we can further analyze and check also your comment with regarding record metadata.
So this is the evaluation of Suppressing availability for Ebsco (or other provider) when the following conditions are met :

• Record type is journal article

• Record metadata does not include volume or issue information

• Access rights are from Ebsco (or other specified provider)

--> 40 complexity points

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)

15

As the existing solution we have today for the copy to clipboard doesn't support well the rich text format, this enhancement request is to replace the existing solution with a solution that will keep the rich text format - same as displayed in the UI.
The estimation for replacing this tool is : 15 points

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)

25

Today we display the related records sorted by alphabetical order based on their titles as given to us from relation table that build in Alma.
To extend the sort and support this request, we are going to utilize the functionality as exists in Alma - sort by series Asc/Desc.
This means that this request will be evaluated only for Primo VE - as request comes after specific VE release.
Note: We will provide a configuration to trigger this sort ,as the new sort by series may be more slower then the existing alphabetical sort that is being done today in the client side.
The evaluation for supporting the sort by series for related titles (same as provided by Alma ) is : 25 points

VE

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)

60

This enhancement is about creating a separation and logic to display related titles that are based on 773 vs related titles that are based on 8XX .
Related titles are mainly based on a relation table created and managed by Alma , in order to create this separation between relation based on 773 and 830 , it is required to define a new relation type for related titles based on 8XX. The impact of a new relation type definition is on many areas in both Primo VE and Alma : Get It - related titles , requests , Availability statement , Facet locations and Alma related titles workflows.
The estimation of this enhancement will be done together with the Alma and will take into consideration the impact on all related components.
This enhancement includes:

• Defining new relation type to reflect relations based on 8XX

• Impact of new relation type within Alma workflow

• Impact of new relation type in Primo VE : Get It - related titles, requests, locations facets , availability statement .

The evaluation of this request is : 60 points

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.

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

55

The request is to use verbatim search when quotation marks are used, today in CDI we are using a payload mechanism where we index one variation of a word and using the original variations for ranking - for example we can index only student even if the title includes students in plural or composing vs composition ...
this mechanism was identified as the main cause to the variations of search results that appear even when using "".
Today in CDI, we apply language-specific text analyzers to both indexed terms and search terms. For example, the term “students” appearing a record will be indexed as “student”. The current payload mechanism as discussed is used to support the current verbatim match boosting feature meaning boosts the relevance scores of verbatim matches between search terms and indexed terms, without excluding non-verbatim matches.
The proposed enhancement is to modify CDI’s search algorithm to use the same payload mechanism to limit the matches to verbatim matches only when double quotes are used. meaning in this cases we will ignore other variations.

Solution will be focused in improving CDI searches in the following use cases:
using quotation mark ""

• using "is (exact) in the Advanced Search

• In these cases CDI will do matching based on the original terms and will minimize cases caused by the payload mechanism.

The estimation for this solution is :

• Covering 90% of cases by improving matching using "" - 35 points

Additional information:

• As mentioned this solution will be limited to searches on metadata fields -> it will not include full text searches ( as we don't save the original terms to exclude in case of "" )

• Also to set expectations : differences in diacritics and other character variations will be considered to be non-verbatim matches. They will not be cross-searchable with double quotes. Examples:

** fiancé vs. fiance
** 大學 vs. 大学
Note: casing differences will not be considered to be non-verbatim matches. They will remain cross-searchable with double quotes. For example: University vs. university or AIDS vs aids
This is so far the solution we intend to implement and estimated as 35 points

• Handling additional edge cases like using hyphen and more... - Additional of 20 points

Additional information:
During the analysis phase we also identify special cases that require additional effort estimated as additional 20 points for example:

• Compound words (e.g., workplace)

• Hyphen, and other punctuation marks.

• Handling languages with special functionality like Chinese, Japanese, Hebrew, and German

• Special cases of CJK text included in non-CJK records

In any case we would like to mention the limitation of full text searches - if using the include full text searches option- users may still get results with the variations coming from full text. changing this also to support full text matching will be highly cost and may impact indexing size in CDI.

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:

CDI availability calculation (VE)

120

We'd like to share our evaluation to this enhancement request and note the following:

• This solution is limited to improve the display of the availability statement in the brief results.

• As we are limited to the performance of Alma Link Resolver performance, we can't commit at this stage to the performance of showing the full availability statement.

• Solution doesn't include the availability facets - we wont trigger this full calculation of availability during indexing time.

• This request will be done only on Primo VE as the full record optimization is already available there and we intend to use it also in the brief.

The evaluation of this request is 120 points

VE

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)

15

This enhancement is to include Holdings Call Number and Physical Location details while exporting to Excel. This addition will be available only when exporting current selected records or current page (10 - 50 records that the data already calculate those fields)
Note that it will not be part of NERS 8126 - bulk export - since this can make performance impact on the system.
We'd like to summarize the suggested solution and to provide estimation.
The export to excel with be enhanced to include :

• Holding library location and call number - we will add this to a new column and concatenate the information to include all various cases of multiple locations

• Information will be added if it is available

• This will be added only to the existing export to excel mechanism that export information that is already available on the page.

• We can also support the export to excel with the additional information from the My Favorites page, the delivery information is already available there, therefore can be used also in the export to Excel.

The estimation for this request is : 15 points

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)

120

We'd like to summarize and share the evaluation of this request.
The suggested solution for this request is to :

• Support the selection of searches saved in the Search History and Saved Searches and allow to combine them into unified query that includes filters and terms from all selected searches

• Selection of searches will be limited to same search scope

• Unified query will be limited to system query length

Note: we can better define unified query specification closer to the implementation phase.
The evaluation for this request is: 120 points

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.

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

30

A similar NERS currently exists in Alma in NERS #8371. After discussing this with the Alma Product, we understand that the suggested direction is to add comments to the existing fees statuses instead of creating new statuses. This means that Primo will display the additional comments rather than new statuses.
Based on that, our estimation for this will be for adding additional comments and display them in Primo.
The evaluation of this request using the direction of adding comments is 30 points
This is synced with the Alma evaluation as well.

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*.

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

50

This enhancement was also evaluated last year as part of NERS 7896.
The evaluation for it was and still is :

• Displaying users all of their loans / requests in one page. First show their home institution's loans \ requests and after loading is completed show loans/ requests from other institutions

This is estimated as 25 points

• Support bulk of actions: sorting, renew. exporting.. on the unified list is estimated as additional 25 points

Total points: 50

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.