In Primo you can activate autocomplete to get suggestions for search-queries based on what the end-user begins to type in the search-box.

We have tested the functionality and see that it could be useful for the end user to get these suggestions. However we see that the suggestions from the central index in some cases are a little strange and that you get suggestions from the entire index and not only the sources the institution has activated. This means that the end-user could get suggestions that gives 0 results.

If you get a suggestion that leads to nothing you will think that it was a bad suggestions and maybe not use the feature again. That reflects badly on the reputation of the system and institution.

We would like that this functionality is changed so that the users only gets suggestions from sources that are activated for search.

This to prevent that the get suggestions that leads to 0 results.

The open discovery of the new UI allows customers to customize the new UI, extend its functionalities, and connect Primo with external services.
This framework can offer an important added value to institutions; it can enable them to respond to specific needs of their user community.
We want to implement extensions for functionalities like:
• Offer a button “report a problem” that allows a user to report a broken link or another problem with a specific source he found. The form sends this message to our helpdesk, together with useful debug info like : is the user on or off campus, browser version used, search query, pnx-id,.. and his e-mail address when he is signed in. Our e-resources staff finds this functionality extremely useful: more linking issues are reported now and they can be handled in a more efficient way.
• Offer a button “Pay fines” that allows a user to pay fines online. The button is only displayed when the user has fines.

These are extensions that we currently implemented in our old UI.
But creating extensions that make use of session data (like user email, vid, …) are time consuming and risk full:
• Time consuming because documentation is limited not to say non-existing, this requires reading the code. It has a high maintenance cost since after every release, extensions can break and it is difficult to find out why because of the lack of clear release notes.
• It is risk full because we don’t know whether we will be able to fix the functionality in the two weeks between release on staging and production. It is also risk full because we don’t know if the extensions will still work after the transition to Angular 2.

Our request is :
Please provide us with session data in every component so we can quickly create components.
One way to make the extensions manageable and future proof, is to use a data model (see primo-explore-dom). If the data is framework agnostic it will become more portable and working with data is easier and almost timeless.
This way everybody can develop within the reach of their skillset and more institutions would be able to take profit of the open discovery framework.
But we are open to any solution to overcome the issues mentioned.

Primo Central grouping is based on the existing FRBR workflow, including the grouping process at the database level (the way the Search engine handles grouping) and the Front End functionality. It is used to prevent duplicate records in the results list.

Unfortunately, many records are not added to FRBR groups because the system considers the metadata are not rich enough. With the increase of records provided by (Open Access) aggregators and repositories, the number of duplicate records will certainly not decrease.

Could Ex Libris improve the FRBR workflow for Primo Central records in order to reduce the number of duplicate results and consolidate the FRBR groups?

Examples of duplicate records:
Accuracy of prediction of gene content in large animal populations and its use for candidate gene detection and genetic evaluation
3 results (2 FRBR groups):
- TNproquest195858157 and TNfaoagrisUS201300875183
- TNcrossref10.3168/jds.2007-0231, TNscopus2-s2.0-42449094585, TNsciversesciencedirectelsevierS0022-0302(08)71293-1, TNmedline18349258
- TNorbi2268/23076

Linguistic symbiosis between event loop actors and threads
2 results (1 FRBR group):
- TNsciversesciencedirectelsevierS1477-8424(08)00024-9
- TNscopus2-s2.0-51649125887 and TNcrossref10.1016/j.cl.2008.06.005

Efficient control of transient wave forms to prevent spreading depolarizations
2 results (1 FRBR group):
- TNarxiv0705.3398
- TNscopus2-s2.0-39649117125, TNsciversesciencedirectelsevierS0022-5193(07)00579-6, TNcrossref10.1016/j.jtbi.2007.11.019, TNmedline18177900

Le traitement de la modalité épistémique dans les traductions françaises de On the Origin of Species de Charles Darwin
3 results:
- TNerudit1038687ar
- TNscopus2-s2.0-85017546223
- TN_proquest1870219718

Primo supports display of See references (not same as See Also) in browse headings, if those cross-references are in the bibliographic data ingested by Primo. There is no capacity to display See Also and Usage info from authority records, which are important so that users understand how and why certain terms, especially subjects, may be used.

We propose that See Also and Usage info display in the Browse headings.

Example headings and See Also and Usage info that does NOT currently display in Primo:

Blacks:

Search also under: subdivision Blacks under individual wars, e.g. World War, 1939-1945--Blacks; and headings beginning with the word Black

Here are entered works on blacks as an element in the population. Theoretical works discussing the black race from an anthropological point of view are entered under Black race.

It's possible this enhancement could be achieved through application of an API that interacts with Library of Congress systems. Display of narrow/broader terms would also be highly valuable.

Primo VE is configured to map 6XX $v form subdivisions to a separate display field, breaking the subject string. In some cases, the form subdivision is plucked out of the 6XX, leaving the surrounding string incomplete. For example:

600 10 $aO'Keeffe, Georgia, $d1887-1986 $vExhibitions
displays in Primo VE as:

Subject O'Keeffe, Georgia, 1887-1986

Genre Exhibitions

651 #0 $aRome (Italy) $vMaps $vEarly works to 1800
displays in Primo VE as:

Subject Rome (Italy)

Genre Maps

                   Early works to 1800

And so on, for all 6XX $v form subdivisions. This cannot be reconfigured. Additionally, each occurrence of the form subdivision is displayed as a separate genre. An exhibition catalog with three artists appearing in 6XX fields would result in three genre term displays, all saying "Exhibitions".

To preserve our subject string with form subdivisions intact, we were advised to consider adding a 9XX with the field as we want it to display and labeling that as Subject in Primo VE.This adds steps to cataloger workflow and generates unnecessary data in the records.

This display feature should be reconsidered. Whether or not to split $v form subdivisions should at least be configurable by libraries.

Primo Central Index contains many records for abstracts of conference papers that have been published in journal issues/supplements.

These records are given the Article resource type in Primo. This confuses users, who when they find these items expect a full-length article instead of a short abstract.

It also creates problems with link resolvers, which attempt to generate article-level links and fail (publishers usually do not provide these abstracts as individual articles).

To fix this, Primo Central should be given a new resource type for abstracts.

The sources for these records are usually large indexes such as Scopus or Web of Science, which already mark these items as abstracts. This would make it easy to reclassify items as the Abstract resource type.

Create Discovery Manager roles and give customers the possibility to assign Discovery roles to colleagues who are in charge of specific content updates in the front end (notably Tag management, Resource Recommender management, Primo Central Index activations/deactivations) and who are not necessarily Primo administrators. For more flexibility and granularity, different roles (or parameters to add?) should be created. For example, a staff user in charge of Resource Recommender management should not necessarily have access to PCI activations.

Subject and reference librarians could directly work in Alma in order to keep recommended resources, tags and PCI collections updated; tasks where traditional Primo administrator skills are not required. Currently, a single 'Discovery – Admin’ role concentrates too many responsibilities and functionalities.

In the brief and full display pages, libraries can display information contained in data fields (such as the title, author, and creation date) from the source record. This information helps users to differentiate records quickly. In some cases, there can be a lot of information that is displayed. This is particularly the case when Contributor is added: all 7XX fields are added, and in their entirety (see for example in the attached screenshot).

We would like an option that would allow the library to either limit the number of fields to display (for example max 3 7XX fields) or to only display fields based on the content of some subfields (for example: only display 7XX where $$e equals 'editor', 'publishing director ', 'translator', 'Director', 'film director'...).