When there are records in CDI that have link in record, but also would return links from the link resolver both types of links should be displayed to the end user.

The challenges with the link in record are discussed in this idea: https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/40487230-preference-cdi-link-resolver-records-over-link-in

They have a tendency to break and if the link for some reason do not lead to the full text the end user does not get any other way to the full text (as they do with the multiple links fromt he link resolver).

We hope that Ex Libris enables the system to display both link in record links and link resolver links for the same item.

This should be done for both Primo and Primo VE. If this should be configurable can be discussed with the Primo Working group.

A user viewing a view that is associated with a particular library or campus should be able to view availability of physical items at that library or campus libraries in the brief results layout. This idea is primarily for institutions with multiple libraries and, especially, multiple campuses. Campuses are associated with libraries, and typically a Primo view will be associated with a campus.

Currently "best location" can only be set via the user's IP address. This approach works when users are at the location, but when a user is off-campus, the first location to show on brief results and full display is alphabetical. Providing control over which library is preferred at the view level would give that view's users a better understanding of their quick access to materials. We have done usability testing that showed users who did not see their library listed on a results page assumed that the material was not available at their library.

Note this request was made in a previous idea, https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/32961133-ability-to-select-which-location-appears-first, but Ex Libris considered it to be completed with the addition of IP-based Best Location.

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

Our users make heavy use of the generate citation button, but they currently have to do this one record at a time. It would make things easier for them if they could pin all the relevant items, and then go into My Account, select all their pinned items, and generate a citation for all of them.

They can currently perform several actions by batch on all pinned items - email results, export to Refworks and so on - but the generate citation action is not yet available to them.

The citation that appears could be simply plaint text, with the citations separated by line breaks.

Hi there,

According to SF case 422111 it's currently not possible to provide detailed statistics about advanced search field through OBI.

As for the facets, we would like to know the number of using field by field.

For example :
- We would like to know how many clicks were done on search field "Topic"
- We would like to know how many clicks were done on search field "Author"
- We would like to know in how many session the search field document type / books was used
- Which are the fields the most used in the advanced search, which are the less used ?

Those statistics would help us to improve our configuration according to patrons' needs.

Thanks for support !

Ariane

Infinite scrolling (with or without load more) is not a good solution from a stricter accessibility perspective and certainly not in combination with the scroll button. Primo has both infinite scrolling from the bottom search result list with the button "Load more results" and a scroll button in left bottom. That scroll button doesn't work in Safari with newer MacOS and it's registered as a bug.

1. Make it optional to the library administrator to choose between: infinite scrolling or scrolling by pagination (with option of number of hits per page) and with or without scrolling button to the left.




2. Make it optional to the user in the account settings to choose between: infinite scrolling or scrolling by pagination (with option of number of hits per page) and with or without scrolling button to the left.

Some make a difference between infinite scrolling and a load more button. Here, wether you agree or not, I treat Load more button as a type of infinite scrolling.

We would like to allow the user to use the Collection Discovery interface also for discovery. Currently, it is only possible to search at the collection level. It is important to enabling a search across all levels of all collections as the user cannot know in which collection/sub-collections to search for needed items.
Following are a couple of user stories:
* We have various collections of photos. We would like to allow the user to search across the various collections and sub-collections for the pictures of the Knossos temple. We have relevant photos in two different sub-collections.
* We would like to allow the user to search across the various collections and sub-collections for the pictures of the Kabara Swamps. We have photos in various sub-collections that are 3 folder levels down from the Collection Discovery Home Page.

In Primo, customers could customize the RIS export table, to determine what PNX fields should be used for RIS fields. In Primo VE this is not possible:

The mapping of the RIS fields to PNX fields is as follows:
IS addata/issue
TY addata/ristype
N2 addata/abstract
N1 addata/notes
PB addata/publisher
A2 display/contributor
ET addata/edition
KW display/subject
EP addata/epage
DO addata/doi
PY addata/date ; display/creationdate
JA addata/stitle
VL addata/volume
CY addata/cop
AU display/creator
T3 addata/seriestitle
T2 addata/addtitle
T1 display/title
SP Addata/spage
JF Addata/jtitle
ID Alma MMS ID
SN Addata/issn; addata/isbn; addata/eissn; addata/eisbn

As most reference managers will read A2 as Series Editor, it would be helpful if the display/contributor could be conditioned to map to AU instead. This is just one example - and why the mapping should be customizable.

Paraphrased omment from one of our patrons:
- When I tag something I have pinned, the entire page has to refresh- which means it jumps all over as images come in etc and can take up to 5 seconds to fully load. Not all browsers act the same. Chrome gets me close to where I was while FireFox is a Magic 8 ball. One time I land back at the record I just tagged, the next, I am 6 records up the list. I'm working my way through my list trying to organize my articles for a lit review - having to wait as the whole page reloads every time I want to add a label and not knowing where I'll be when the page does load is frustrating. There are better ways to do this that wouldn't force the entire page to reload each and every time. This is just painful.

Currently if display of 541 and/or 561 fields in holdings records is enabled in "Holdings Display Customization", 541 and/or 561 fields display in the GetIt section in Primo regardless of the value in the first indicator. If the value in the first indicator is zero then the 541/561 field should not be displayed - this is standard MARC coding (see https://www.loc.gov/marc/holdings/hd541.html and https://www.loc.gov/marc/holdings/hd561.html ).

Ex Libris proposed a solution to us where when the holdings record is saved the a 541 and/or 561 field with first indicator empty or 1 is copied to a 999 field, and in the Holdings Display Customization table display of the 999 is enabled. We don't feel this is acceptable as it is changing/perverting the source data to accommodate a failing of the Primo software, when Primo should be able to use established MARC coding to display or not display the 541/561 fields in holdings records.