The current behaviour to move from search results to exploring a record is to open a pop up to view the full record.
This takes the user away from the results set they are working with.
There is feedback that some users dislike pop ups.
We have also observed that many users open full records in a new tab in order to have records of interest open in tabs to go explore in detail later whilst continuing to work with the search results.
To match user behaviour in exploring search results I'd like to suggest an option to open the full record within the search results page. Or the option to expand to view more about the record whilst remaining on the search results page.
The aim being to allow the user to work with record whilst remaining on the same search results page. Reducing the need for users to open records in new tabs, or being navigated away from search results to a pop up.

A growing number of Central Discovery Index (CDI) sources contain the original non-english characters for specific languages, e.g. Scandinavian (Danish, Norwegian, Swedish) letters such as æ,ä, ø, ö and å. Searching the original Scandinavian letters works for both local and CDI data. However, searching non-English letters are cumbersome for foreign users. There are different ways to anglicize these characters. The traditional Scandinavian way is to use a "folded variant": "ä" -> "ae", "ö" -> "oe", etc. However, this only works for local data (institution zone). CDI use the method of simply removing the dots: "ä" -> "a", "ö" -> "o", etc. These two different ways of indexing Scandinavian letters leads to inconsistent searching.

We would like to be able to search for Scandinavian characters in a consistent way for local data as well as CDI data.

As a cataloger, I would like to propose a new option to filter search results for items with accessibility features (captions, audio descriptions, large print, etc). We are in the process of adding 041 subfields (mostly p and q), and 341 and 532 fields to our records in order to help users more easily identify items intended for those with hearing or visual disabilities. Ideally, this feature would utilize that input based on the presence of indicators in the 341 or 532 fields (i.e., 0 and 1) or controlled vocabulary terms to create search facets or indications (similar to the use of the 506 to indicate Open Access). Ultimately, our aim is to make access to our collection more inclusive, and this feature would go a long way towards achieving that goal.

Primo no permite configurar la ordenación de los holdings o de los items asociados a un holding en la Vista completa del registro (sección Get It).
En nuestro caso, tenemos holdings diferentes asociados a una misma ubicación y biblioteca. Primo VE no permite ordenar estos holdings por signatura (ver en la imagen adjunta el ejemplo número 1).
Por otra parte, hay casos en los que muchos items dependen de un mismo holding. En este caso nos gustaría que se pudieran ordenar por disponibilidad, es decir, que se mostraran en primer lugar los items disponibles. En el ejemplo 2 del documento adjunto se puede ver que el orden de los items no sigue ningún criterio.
Gracias!

Currently any unkown View Code in the URL (e.G: vid=PRIMA) leads to empty page and rotating diamonds.

In the background Angular is unable to fetch the configuration URL /primo_library/libweb/webservices/rest/v1/configuration/PRIMA which is answered by an HTTP 406 error from the server.

To the enduser its completely unclear where the problem is located, did she/he make a mistake or is there a problem on the server.

I would suggest to provide at least generic error page (View Code not found) and respond by HTTP 404 or 406 to the client. This is also important for search engine crawlers if there are any outdated permalinks on websites.

For mulittenant and local installations it would be great if this can be customized at installation level.

Thanks
Ulrich

Some of our patrons like to use Primo with many open tabs, each tab can contain one item they are interested in and want to read/check out. The problem is that if they spend longer time than the timeout limit (one hour for our instance), Primo will automatically log out and close all the tabs. And the patron cannot re-claim/re-open closed tabs after sign in again. It has been a recurring complaint and we think extending the timeout limit is not a good solution. Our expectation for Primo is that when patrons sign in again, the lost/closed tabs from the last session will automatically re-open.

Current CDI design in Primo UI is to expose metadata from all participant records for both returning results from a search query, and in the values presented for selection in facet for filtering results, but the display of metadata within records is only by site-specific activations.
This means that a user can search for a term in Primo, have results returned on the basis of that term, select the value for the term in a facet, but then not see the term in the record display.

The negative impact of this design decision includes:
* a user is confused by the Primo results list, as there is no indication as to why results were returned, even when the user has specifically targeted data such as an Advanced Search by a specific subject that is then nowhere to be found in the records displayed
* a user can't effectively filter results by facets, because when they do so and look at the records, they can see no relationship between their actions and the resulting records
* a user can't take advantage of lateral links, to generate an Advanced Search query of all the entries for the search term to expand their initial results set, such as all records in a specific subject, because there is no lateral link displayed in the record
* a user is missing key data when exporting by RIS to EndNote, RefWorks, BibTex etc, such as keywords not included, as well as this information not being included in other Send to options of Export to Excel, Print, and Email

Ex Libris design should be reviewed and made holistic and meaningful, to either:
1. Hide all the data ie if data is hidden from display, it should also be hidden from search and facets (and any other elements)
2. Show all the data ie if data is used in search and facets, then it should also be shown in display

Since the updates in January 2021, the Location list has become capable of displaying the Field 866, 852, etc.
There are cases in which the issues of a single journal title are located separately according to publication years. Here we present a case example to explain the situation:
Group 1: The issues published in the last several years; they are shelved in the “New Arrival.”
Group 2: The issues published several years before the Group 1; they are shelved in the “Back Numbers.”
Group 3: The issues published more than 20 years ago; they are shelved in the “Remote Storage.”

Although the groups are virtually separate, they are actually a collective single unit in means of holdings. The Field 866 given to the journal holding is a single character string, and is shared among the above three, resulting in displaying the identical holding range, regardless of the actual location of each group. It looks as if each group includes identical set of issues, and it is impossible to locate a particular issue just by looking at the character string.

However, when each Location is opened, we can see each item’s holding range in the form of ‘from … until ….” We request holding range to be displayed on the Location list as well.

[Case Example]
https://sokei-keio-psb.primo.exlibrisgroup.com/permalink/81SOKEI_KEIO/188bto4/alma990017347710204034

In the case of the journal above, 2 identical holdings of Hiyoshi Media Center are shown. The library patrons may assume there are 2 sets of 1<1927>-90<2003> in this library. In fact, the library holds only one set; Vol.75 and after are placed in the Psychology Lab, and the rest are in the repository.