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.

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.

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.

A strong argument for a discovery index compared to a bibliographic database is the incorporation of full text in the index. I have not found an actual number or a percentage how many Primo Central collections are full text searchable. But we all know: it is significant. Since this year all Primo Central searches will always expand to full text.
https://knowledge.exlibrisgroup.com/Primo/KnowledgeArticles/PrimoCentralFull-TextSearching

The most powerful feature for full text search is proximity.
https://en.wikipedia.org/wiki/Proximitysearch(text)

Aleph was able to support proximity for small hitsets
https://knowledge.exlibrisgroup.com/Aleph/KnowledgeArticles/Proximitydoesn'tworkforlargerresults.

... and Summon has a proximity feature
https://knowledge.exlibrisgroup.com/Summon/ProductDocumentation/SearchinginTheSummonService/SearchFeatures/Summon%3ABoolean%2CPhrase%2CWildcardandProximitySearching#proximity

Proximity search is currently not supported nor planned in the Primo/Primo Central roadmap. Although as part of the search engine algorithm the proximity is being calculated and records in which the query words are closer (we call the distance slop) will be rank higher.

It would be great to add proximity operator to the Primo search syntax and to support proximity search in Primo Central.