I would like to suggest that Primo's facets should be sticky by default (or at least that this should be a configuration option). The "Reset filters" link right below the selected filters implies that filters will stick unless reset; users find this confusing. I agree with other posters' points about the lock icon being visible at all times, and that a selection of New Search should automatically clear sticky facets, but otherwise, I would like to propose that facets should stick unless the user either selects New Search, or clicks "Reset filters" (perhaps this could be renamed "Clear filters"). This is how PubMed functions, with an additional notification at the top of results that selected filters will remain in place until the user clears them.

If a user is not logged in they get the Login message on the ViewIt and GetIt tab, whether they need to login to access that resource or not.

For example, Open Access material.

We have had many instances of users complaining that they have to login to access OA material. In fact they do not need to login to access this material. The Primo login message is confusing and misleading the user to think that they do need to login.
See for example the following Open Access material in our Primo instance.
https://primo-direct-apac.hosted.exlibrisgroup.com/primo-explore/fulldisplay?docid=RMIT_ALMA_DC11160517080001341&context=L&vid=RMITU&lang=en_US

In this example the resource is available Open Access and anyone can access it without logging in.
But Primo continues to display the Login message in the View Online section of the full record.

To resolve this confusion can the login messages be made situation sensitive?
If a record has an Open Access indicator can the Login message on the ViewIt section of the full record be hidden.

Currently patrons can access the area

My Library Card/Personal Details

Where there is an option to edit their details (address, phone number etc).

As our borrower details all come from corporate systems we would like to disable the edit function as, for example, students changing/updating any details such as their address should occur via the student record system not in Primo as a standalone action which will lead to confusion.
In the old UI there was at least a tip on the edit page:
"Changes to e-mail address and text message number will be reflected in Primo only."

It would make more sense to be able to disable the edit function completely, ideally with the option to add a user message or tip of the correct procedure/channels to update their details.

The sticky facets are an excellent addition to the functionality of the new UI, but the probability of users discovering them is quite low.

In usability testing students will alter their search terms without ever hovering their mouse over the filters they have applied to their previous search, and then have to reapply the filters.

While the padlock is hidden behind a mouseover interaction this very desirable functionality is undiscoverable.

Also in its current configuration the tooltips for the selected filter and the padlock clash.

The padlock for making your selected filter 'sticky' should be visible by default, and probably to the right of the filter beside the 'x' used to remove the filter.

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):
- TN_proquest195858157 and TN_faoagrisUS201300875183
- TN_crossref10.3168/jds.2007-0231, TN_scopus2-s2.0-42449094585, TN_sciversesciencedirect_elsevierS0022-0302(08)71293-1, TN_medline18349258
- TN_orbi2268/23076

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

Efficient control of transient wave forms to prevent spreading depolarizations
2 results (1 FRBR group):
- TN_arxiv0705.3398
- TN_scopus2-s2.0-39649117125, TN_sciversesciencedirect_elsevierS0022-5193(07)00579-6, TN_crossref10.1016/j.jtbi.2007.11.019, TN_medline18177900

Le traitement de la modalité épistémique dans les traductions françaises de On the Origin of Species de Charles Darwin
3 results:
- TN_erudit1038687ar
- TN_scopus2-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.

While the new Primo interface gave us more power to extend functionality via JavaScript it does not do the same for modifications via CSS due to the lack of properly marked up content.

In some parts of the New UI the content is well described, often with custom HTML elements, but there are also many places, often in the higher levels in the DOM tree, where better described selectors (preferably through classes) are needed.

For example, there is currently no selector that show the current system that is being displayed. The <prm-explore>-element could have the current system being shown as a class (search, fulldisplay, openurl, jsearch, account, login etc).

In the search results the <div.list-item-wrapper> element is used on the parent level. Here the markup would be greatly improved by adding the media-type such as article, book, text_resource etc. Allowing us to style based on media-type.

It's the same with facets. There's currently no way to target a specific Facet Group with CSS. The first real identifying selector is on the span[translate="facets.facet.facet_XXX"] that is several children down. Having this as a class or other attribute on either the repeating parent <div> or the <prm-facet-group> would help.

In My Account the <md-tab-content> could use the same treatment. Here the section could be added as an attribute, e.g. overview, fines, blocks_messages etc.

These are just a few examples where better selectors would be helpful. The best would be if the entire UI got the treatment with better selectors and modifications via CSS in mind. While JavaScript is powerful it is not the correct tool for everything.