PCI results respect that a user knows what they want, but help with expansion when necessary, such as by stemming when there are very few results returned by the exact query. A user has autonomy also to target their results with techniques such as quotation marks, Boolean operators, and Advanced Search.

In CDI, expansion is constant, by term inflection applied to all searches, as well as higher recall in general by design. This cannot be prevented by features such as Boolean operators, quotation marks or Advanced Search, and is illogical in conjunction with other features like 'Did you mean'.
Note: It is recognized that these may represent different underlying mechanisms, but it is the user outcome which is key.

Ex Libris states that CDI behaviour "does not affect precision" because of Verbatim Match Boost, which will rank more highly the exact search query, but they have designed this as also meaning "near verbatim", completely undermining this concept.

Use case: If a user searches for ATLA, then they expect only results for ATLA and not atlas. CDI returns 7 of 10 first page results which are clearly returned on the basis of atlas by term highlighting, even at No.1, and yet also offers a "Did you mean: atlas", which barely changes the results when clicked.

Use case: If a user searches for a DOI, then they expect only that specific resource. CDI returns dozens of results with often no indication by term highlighting or snippets to explain why. This is discovered only after a timeconsuming check on the full text to be because the DOI is in the Reference List. There is no clear pathway to the actually correct known item, and this is not consistently fixed just by ranking changes. For example, if we do not hold that article in full text, the user sees dozens of results, none of which are correct, instead of the expected pathway of the Zero results message, using the expansion checkbox, and then leveraging the metadata in the 'No full-text' citation to prefill an ILL form.

This is the opposite of precision.

The design should centre the user and the needs they directly express when entering their search query, allowing the choice to both target their search by the techniques above, as well as giving the option of expanding their search, which is even more important given the larger CDI index.
One option could be returning the expected targeted results matching the user query, and then offering a suggestion similar to a clickable Did you mean or Controlled Vocabulary features, such as: "Results also referencing [query]"

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.

Primo's browse search "By Library of Congress Call Numbers" includes the call number prefix (holdings record field 852 $k) when generating the browse list. At UGA, we use that prefix for oversize volumes (Folio, Ff), and for a variety of branch locations, special statuses and shelving areas (Juv, Ref, Vet Med, etc.).

As a result, any holdings with a prefix do not show up alongside holdings in the same call number range, essentially hiding many titles from patrons interested in browsing the shelf list. (This would be an issue for staff as well, but shelf list browsing works correctly in Alma.)

Please reconfigure Primo's browse search to ignore (but, ideally, still display) the call number prefix when generating this index.

Currently, the "starts with" functionality is only available for title searching. There are already some posts here about adding it for other fields, like call number and subject, which I support. This post is about the current behavior though. If I choose to search by another field, such as author/creator or subject, then the next dropdown allows me to choose "starts with" even though it's not available, and it immediately switches to a title search. I'd prefer that, if a user has selected a field other than Title, that "starts with" just wouldn't show up at all. If the task at hand is finding something by author, it doesn't make sense to switch the user to a title search. So if I've selected an author search, then I'd only have contains or is (exact) available in the next dropdown.

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.

The alert functionality is not really functional in a library network with a Network Zone. Users get an alert when a new bibliographic record is created in the Network Zone, but most users don't care about new acquisitions in other institutions. What they want is to be alerted on new acquisitions in their own institution. This means: to get an alert when a new bibrecord is added to the inventory of of their IZ (not only by creating a new record but also by adding a holding or portfolio to an existing record in the NZ).
Our request is to allow for alerts at the institution level in a consortium with NZ.

The facet "language" in Primo is not working correctly. When I choose another language than german or english, e.g. italian, I got german or english titles whose authors have an italian background. This is not making any sense. Especially our chinese students expect titles in chinese when they use this facet. And as it is a global problem I think ExLibris has to find a solution. I checked with several Primo catalogues from other libraries:

e.g.
http://www.getty.edu/research/library/
https://fu-berlin.hosted.exlibrisgroup.com/primo_library/libweb/action/search.do?vid=FUB
https://library.wlu.ca/
http://primo.abdn.ac.uk:1701/primo_library/libweb/action/search.do (they obviously deactivated the language facet already while it is not working)
http://primo.tug-libraries.on.ca/primo_library/libweb/action/search.do?vid=WATERLOO&reset_config=true
http://primo.bib.uni-mannheim.de/primo_library/libweb/action/search.do?vid=MAN_UB
http://onesearch.slq.qld.gov.au/primo_library/libweb/action/search.do?vid=SLQ&fromLogin=true
http://primo.ub.uni-due.de/primo_library/libweb/action/search.do
http://catalogue.solent.ac.uk/primo_library/libweb/action/search.do?vid=SSUVU01
http://whel-primo.hosted.exlibrisgroup.com/primo_library/libweb/action/search.do?vid=44WHELF_ABW_VU1&reset_config=true
http://bvb-new-primo.hosted.exlibrisgroup.com/primo_library/libweb/action/search.do?vid=49BVB_UBG01_VU1
https://hollis.harvard.edu/primo_library/libweb/action/search.do?vid=HVD
a.s.o.

In all libraries I checked there is the same problem that the language facet is not working correctly. So I hope that other libraries will vote for this enhancement request as it is a fatal error in the facets functionality. And I think we should not accept this failure.