Stacey van Groll
My feedback
178 results found
-
74 votes
An error occurred while saving the comment -
3 votes
An error occurred while saving the comment Stacey van Groll
commented
I suggest to move this submission to the Primo Idea Exchange, as submitted to Alma Idea Exchange but solely for Primo functionality.
-
57 votes
An error occurred while saving the comment Stacey van Groll
commented
It would be very welcome for this Rialto version Purchase Request form to have a configuration option to require authentication and allow to show only to specific user groups.
Optional configuration would support those sites who currently use this feature without authentication, while also expanding potential use to sites who do need it to be authenticated.
The flow-on benefits for authentication would be to associate the requests to the Alma user account, just as is done for the Primo Purchase Request form.
We currently use the Primo version Purchase Request form, but it's notably less unattractive than the Rialto form, and a bit of a clunky workflow via Citation Linker.
But it allows for us to show it only to specific authenticated staff and student user groups by Display Logic Rules, as embedded within the GetIt, and is a nicely streamlined workflow overall for staff processing.
We can't use the Main Menu direct link option as our institution requires a standard header, and even if we could it does not allow to show only to specific user groups accounts.Stacey van Groll
supported this idea
·
-
88 votes
An error occurred while saving the comment Stacey van Groll
commented
I agree this is very clunky for VE.
In Primo with BO, you can see all the information easily by frame source and adding &displayCTO=true, which I added as a bookmarklet to be triggered in one click.
In Primo VE, first you have to trigger Display CTO, which very annoyingly refreshes the display from the full record overlay to a full page, losing your place in the search results. Then the CTO display is still missing the Target URL. So then you have to find the Incoming URL, copy this, paste it into a doc, add &debug=true&svc_dat=CTO to the URL, copy the URL, paste it back into the browser. -
3 votesStacey van Groll
supported this idea
·
-
7 votes
An error occurred while saving the comment Stacey van Groll
commented
I agree that the current development is misleading and unclear. It is completely obvious that there is a user expectation immediately established that the presence of such a visual element indicates a user-generated change, regardless of by form, text, whatever.
And that this visual element being not present indicates no such change.
It feels like lazy development that this feature was not made complete to match this user expectation and the desirable outcome to have Alma clearly indicate all user-generated changes without having to constantly click to see this instead.Stacey van Groll
supported this idea
·
-
3 votes
An error occurred while saving the comment Stacey van Groll
commented
I know it doesn't match exactly your idea as a premise, but perhaps just disable the field if it is causing so many problems for you?
If it adds no value, there is no point having it, so that is a factor you'd have to consider if it's useful to you at all for some use case.
We decided several years ago to remove it when it was a display field only which was meaningless and only caused staff confusion as to what they should do if it had passed.
We haven't regretted it for a moment. -
4 votes
An error occurred while saving the comment Stacey van Groll
commented
The 'Search inside' functionality should perform an advanced search by keyword + the ISSN of the record.
This should therefore not show articles from completely different titles, in not matching to ISSN.
I checked one at a VE site by "Search inside" keyword of teaching, and the outcome Advanced search was: Any field contains teaching AND ISSN contains 0022331XCould you perhaps provide an example where you have articles returned which are for other titles?
-
1 vote
An error occurred while saving the comment Stacey van Groll
commented
I agree that there should be personalisation options in this area to allow patrons to set their own defaults, and for consistency this should be in the Personal Details and Settings area.
This should be for all Primo customers, not just those using Primo VE.I also wanted to note that there are technically 'locks' available but they are not clear to a patron as only shown by the URL and not as a UI feature.
These URL based locks ensure that features such as Saved Searches correctly record the search state saved by the patron to their Favourites and for any records sent by weekly email for Saved Search Alerts.Expand toggle
• Initial search – no indication in the URL
• Once expand toggle is enabled, the following is added to the URL: &pcAvailability=true
• If the expand toggle is then disabled, the following is change in the URL: &pcAvailability=falseFulltext toggle
• Initial search – no indication in the URL
• Once fulltext toggle is enabled, the following is added to the URL: &searchInFulltext=true
• If the fulltext toggle is then disabled, the following is change in the URL: &searchInFulltext=falseIt is definitely clunkier than simply allowing users to set defaults, but technically you could suggest that a patron bookmark a URL directly into Primo after using the toggles as above to set the URL element, or to use their Saved Searches for this to navigate from there, and you can provide saved URLs also with this.
Not ideal, but at least it is some answer to give to upset patrons to workaround this UI issue. -
189 votes
An error occurred while saving the comment Stacey van Groll
commented
Is there any progress on this? The last update was now 7 months ago that this was being reviewed (Feb > Sept 2023).
Stacey van Groll
supported this idea
·
-
16 votes
An error occurred while saving the comment Stacey van Groll
commented
I would like to add an important use case for Journal Title.
Our Business students are expected to use articles in their assignments from the ABDC List, the ‘Australian Business Deans Council Journal List’ (see https://abdc.edu.au/abdc-journal-quality-list/). This list ranks thousands of journals into four categories of quality: A*, A, B, C.
A common assignment may state: “Your reference list MUST include a minimum of ten articles published in peer-reviewed journals included in the ABDC Journal List”.
Primo offers no way to do this effectively other than by students doing a keyword search for their topic, limiting to Articles and Peer-reviewed, and then cross-checking against the ABDC list to manually select to include each Journal Title facet value available in their Primo results.
Therein lies the problem when now Primo only shows 10 values.
In sum, this flow is no longer possible and we receive patron complaints on this when they either incorrectly assume that these journal titles are the only entries in their results set and miss out on good relevant results for their keywords, or they realise a problem and query with us why the facet options do not make sense in comparison to their results and the articles they are seeing in the first page of results published in journals which do not appear in the facet list.An error occurred while saving the comment Stacey van Groll
commented
To continue the discussion of facet values for local records, this is yet another parity issue between Primo using Back Office and Primo VE managed via Alma, and I did not realise until recently just how limited VE was.
Our Back Office is currently set to 500 Maximum Number of Displayed Facets. We have never had a complaint on either this limit, or desire wanting even more from users, and I have never felt hindered by this high level of data as a systems librarian. I have also never noticed any performance delay with loading these values, and they appear pleasingly immediately at the time of results returned or by selection of 'More'.
Without being allowed to see more facets in UI, there are issues such as when there are few resource types in the set. For example, if we have a facet for Library Guides this is likely to only be one records in millions. In BO, we can easily expand the facet list for the Resource Type set to size, and find the Library Guide (1). And expanding the Subject Term or Author or Language facet etc, there are the expected 500 entries shown.
The ability to see this level of data as a feature of UI flows beyond just selecting to include or exclude a single facet in a one-time search. Users can use the facet selection to tag resources easily in bulk into My Favourites, can use the locked facet feature to do subsequent more limited searches on the set without having to perform another Advanced Search with complex search lines on specific fields to attempt to target the data (and this expects that they know what to search and are not helped by easily viewing the entries in the facet), and they can set up a Saved Search and Alert specifically by this facet to quickly re-run the query including or excluding facets, and get regularly email updates with these facet value selections.
Why is there this limitation in VE? Is there some fundamental design flaw causing such performance issues that Ex Libris decides that this part of Primo UI must be is drastically and artificially limited to overcome it? If the argument that this is acceptable is the common one of relevance ranking, I would say that not all problems are solved by relevance ranking, such as the issue of long tail results from CDI meaning that Sorting results is not possible, and it does not remove the value of other features such as facets to help with this.BO:
"Number of Top Hits for Facet Creation – This field specifies the number of top-ranked records the system will use to create the list of facet values that are displayed in the Refine My Results section of the Front End. Currently, this field is no longer configurable and is set to 2000 internally. For CDI, all records in the results set participate in facet count calculation for the top 20 values displayed for CDI.
Maximum Number of Displayed Facets – This field specifies the maximum number of facets that can be displayed in the FE (for example, when More is invoked).
Full Facets Cache – This field indicates whether cache is used to increase the maximum value of the Number of Top Hits for Facet Creation field to 5000. For more information on adding additional memory, see Full Facets Cache (on-premises installations only). For multi-tenant customers, this value may be set as high as 10,000."
https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/Primo/Back_Office_Guide/100Facets/020Configuring_FacetsVE:
"By default, facets in Primo VE return up to 20 facet values for local searches and up to 20 more facet values for CDI in blended searches. This parameter allows you to increase the maximum number of facet values to 50 for local searches only. The valid values are 20–50. CDI will continue to display a maximum of 20 values in blended searches." by discovery_facet_limit
https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/020Primo_VE/Primo_VE_(English)/120Other_Configurations/Discovery_Customer_Settings#Discovery_Facet_LimitAn error occurred while saving the comment Stacey van Groll
commented
That is a fair point, Manu, I was attempting here to scope a hopefully reasonable request to restore what we once enjoyed in PCI, working on the information provided by Ex Libris in my case stating that this will be an enhancement request for specifically a change in CDI behaviour due to the newly imposed limits.
I did not have many scenarios in a PCI blended where the number of returned facet values for dynamic facets seemed lacking, which is very much not the case on CDI with the much lower limit. I recognise in this as well that there are real system-based limits, but I would expect for a new mandatory system that all factors should be an improvement rather than a downgrade.Stacey van Groll
shared this idea
·
-
794 votes
Thanks for the examples - we will review them and discuss our options.
Best,
Tamar
An error occurred while saving the comment Stacey van Groll
commented
In February 2023 Ex Libris advised more sources of Peer-Reviewed information:
"In CDI, records are marked as Peer Reviewed if they are published in a journal that is marked as Refereed/Peer-Reviewed in Ulrich's Periodicals Directory (Ulrichsweb).
In addition to the journal-level indication from Ulrich's, CDI also provides a Peer Reviewed indication from few other providers’ source records: ERIC, Onepetro, Erau digitalcommons and Almandumah."Stacey van Groll
supported this idea
·
-
68 votes
An error occurred while saving the comment Stacey van Groll
commented
Hi - Best to submit ideas to the forum where the issue is expressed ie a suggestion for Primo functionality to the Primo Idea Exchange.
Note: Ex Libris moved the submission from Alma to Primo after I added this comment.But regardless I don't hold much hope as Ex Libris has consistently denied indexing for item level information due to impact on performance and the high load of indexing it would require for constant changes.
Even for barcode which was delivered this year, it could only be fulfilled by API call, not indexing: https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/38113540-barcode-search-in-primo -
1 vote
An error occurred while saving the comment Stacey van Groll
commented
If implemented, please fulfill as an addition, not a change.
We find creation date valuable, but would appreciate also to have updated date.
There should be no need to sacrifice one for another. -
3 votes
An error occurred while saving the comment Stacey van Groll
commented
I've tested this and they all work to change to display the service or not depending on the setting and resource.
Who told you they don't work and that it would be an enhancement to correct an in-system non-functioning feature? -
48 votes
An error occurred while saving the comment Stacey van Groll
commented
An excellent idea. This is one of the reasons we don't use this feature. It is needed not just for VE though, but for all Primo customers.
-
20 votes
An error occurred while saving the comment Stacey van Groll
commented
I live in fear of accidentally clicking a default radio button for this reason! Or for one of my fellow admins at our site to do this.
I've never gotten around to doing a case myself, but I wonder if anyone has and been advised by Ex Libris that this is actually an enhancement request as opposed to a defect?
It certainly seems to me to be a defect that you cannot unselect a default, and wonder what justification there would be for deliberately designing this into a product. -
11 votes
An error occurred while saving the comment Stacey van Groll
commented
I wish I had more votes spare for this. I support it both for giving Admins autonomy to manage this area, including by cutting down on time wasted with Salesforce cases, plus also it is ridiculous that the admin customer sees only the view full of codes that often do not match the actual outcome of change, and the vendor gets the lovely clearly well-designed UI. This is completely opposite to what it should be, though ideally both admin and vendor gets both.
-
1 vote
An error occurred while saving the comment Stacey van Groll
commented
I reported this factor for Contextual Relationships in June 2019.
It was advised: "the book chapters are not displayed in a specific order, because we don't have the necessary data for that, when the chapters are found in the related item call." -
1 voteStacey van Groll
shared this idea
·
Please be aware that hiding GES or service by Display Logic Rules still shows the details in the OpenURL Context Object, and only hides the details from UI.