Stacey van Groll
My feedback
198 results found
-
54 votes
An error occurred while saving the comment -
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
·
-
764 votes
This improvement is planned for the 2024 Roadmap.
An error occurred while saving the comment Stacey van Groll
commented
This is the scoping statement by Primo Product Management for the 2023 enhancements round, which is important to consider. It is different in some ways to my submission here, but I am likely to consider it fulfilled with the delivery of #8210 (as generated by my #7683 submission which was No.1 but rejected for scoping in 2022). This is pending practical experience of testing once it's available.
"The request is to use verbatim search when quotation marks are used, today in CDI we are using a payload mechanism where we index one variation of a word and using the original variations for ranking - for example we can index only student even if the title includes students in plural or composing vs composition ...
this mechanism was identified as the main cause to the variations of search results that appear even when using """".
Today in CDI, we apply language-specific text analyzers to both indexed terms and search terms. For example, the term “students” appearing a record will be indexed as “student”. The current payload mechanism as discussed is used to support the current verbatim match boosting feature meaning boosts the relevance scores of verbatim matches between search terms and indexed terms, without excluding non-verbatim matches.
The proposed enhancement is to modify CDI’s search algorithm to use the same payload mechanism to limit the matches to verbatim matches only when double quotes are used. meaning in this cases we will ignore other variations.Solution will be focused in improving CDI searches in the following use cases:
using quotation mark """"
* using ""is (exact) in the Advanced Search
* In these cases CDI will do matching based on the original terms and will minimize cases caused by the payload mechanism.The estimation for this solution is :
* Covering 90% of cases by improving matching using """" - 35 points
Additional information:
* As mentioned this solution will be limited to searches on metadata fields -> it will not include full text searches ( as we don't save the original terms to exclude in case of """" )
* Also to set expectations : differences in diacritics and other character variations will be considered to be non-verbatim matches. They will not be cross-searchable with double quotes. Examples:
** fiancé vs. fiance
** 大學 vs. 大学
Note: casing differences will not be considered to be non-verbatim matches. They will remain cross-searchable with double quotes. For example: University vs. university or AIDS vs aids
This is so far the solution we intend to implement and estimated as 35 points* Handling additional edge cases like using hyphen and more... - Additional of 20 points
Additional information:
During the analysis phase we also identify special cases that require additional effort estimated as additional 20 points for example:
* Compound words (e.g., workplace)
* Hyphen, and other punctuation marks.
* Handling languages with special functionality like Chinese, Japanese, Hebrew, and German
* Special cases of CJK text included in non-CJK records
In any case we would like to mention the limitation of full text searches - if using the include full text searches option- users may still get results with the variations coming from full text. changing this also to support full text matching will be highly cost and may impact indexing size in CDI."An error occurred while saving the comment Stacey van Groll
commented
The set of 3 ideas which would drastically improve irrelevant and meaningless CDI results, by restoring and adding search tools which empower our users to target their search and their results, and and fixing the design decisions which make these tools very necessary:
An error occurred while saving the comment Stacey van Groll
commented
A user story showing one of the issues with this design:
I am a user interested in new resources the exact terms “student consult”, and I’m pleased to find that my Library offers a feature of a weekly Saved Search Alert email, as I’m time poor.
The next week, I get a saved search alert email for a single new item returned by my query, and I’m excited to explore this resource that my Library has sent to me.
I click on the link to navigate to the record, but I’m surprised to see that the record doesn’t appear to have my exact terms, with nothing in the record matching this.
I’m confused, and so I navigate to the full text, and Ctrl-F to search for my terms, but I don’t get any hits on “student consult”.
I change my search to just “student”, and then I finally see that the full text includes text of: "Ask students to consult the literature…"
I am extremely annoyed, because I explicitly set up a search query exactly for “student consult” as I know this is what quotation marks should do to target queries, and I feel like my institution’s library has wasted my time.Per Ex Libris documentation, this outcome is expected, because stop words are not indexed in the full text and quotation marks do not present expansion.
So, “student” is expanded to “students” and the presence of “to” in the full text is ignored, meaning that “student consult” matches to “students to consult”.
Ex Libris recognises this is a problem in the OLH ie “On the downside, they contribute to a longer tail of results that may be less or not relevant to the users’ intentions.”
But they also think that this is acceptable: “As full text matches are ranked far lower than metadata matches, material with the exact phrase in the metadata will almost always outrank them in the result list. However, full text matches can become important if there are no or very few results with the exact phrase in the metadata, and it can lead to other relevant findings.”
The assumptions that Ex Libris is making here, all of which are false:
• getting no results or few results is always a bad thing, which must be avoided at all costs
• users will not want to sort their results
• users will not want to use any facets
• users are only searching in UI manually every time, and not setting up saved search alerts
In sum, it is assumed that the only way Primo is being used is by a search, with relevance ranking, and that users only care about the top results in Primo, and therefore CDI design is 'working as expected'.
“Some” users are served by this, and perhaps you could argue even the majority, but the needs of experienced researchers are ignored and apparently considered unimportant.
Primo should be sophisticated enough to support the needs of all users.
It is a regression and downgrade in the service offered by our Library.An error occurred while saving the comment Stacey van Groll
commented
Some user-focused reasons to vote:
* Do you get complaints about the deluge of irrelevant results?
* Would you like your experienced researchers to be able to find exactly what they need by their targeted query, with the use of Boolean operators, quotation marks, and Advanced Search?
* Would you like these users to be able to sort their results for review other than by relevance (not possible with the long tail), and take full advantage of features like Saved Search Alerts?Stacey van Groll
shared this idea
·
-
10 votes
An error occurred while saving the comment Stacey van Groll
commented
I concur with Andy's comments that the existing feature to hide terms applies to both local and CDI records, which I confirmed in my Sandbox testing.
We do not use this in Production partly per Andy's comment also that the feature is only for display. -
2 votesStacey van Groll
shared this idea
·
-
225 votes
An error occurred while saving the comment Stacey van Groll
commented
This is an alignment issue, as possible in Primo Back Office with Alma, but not Primo VE.
An error occurred while saving the comment Stacey van Groll
commented
Hi Natasja, you should be able to do this by adding the AVA field for display. We have a local practice of using LC in the bib record and then adding a Local running call number at the holdings level when we shift items to our off-site Warehouse. So, a little different use than yours in open stacks. I've already had a Local Call Number field for display, but just from the 090 in the bib for resources without LC. To date I've only grabbed both the AVA and the 090 for search data, just in case it's the only information a user wrote down from a record, but am now adding the AVA also for display as well, so that it is included in the Excel Export.
-
345 votes
Hi all,
This is to update that we plan to develop this option in the future. It is not in the current roadmap for this year, and we will update as soon as we have more details about the development planning.
Best regards,
Yael.
An error occurred while saving the comment Stacey van Groll
commented
This is on my list of dealbreakers for not moving from BO to VE. We should not have to give up functionality and autonomy to move to the latest-but-often-not-better system of VE. Why should we have to state to our patrons that we moved to a system where we have no ability to do something so basic as remove links from our own environment for our own records?
There is no benefit of the sales pitch of simplicity for VE if all it means is that you can't configure your environment any more. It's ridiculous that for a core access service such as Primo, VE does not give the ability for library staff to curate the links which their users see.
This includes both 856 for View It and also the Links section.
This is another case where Ex Libris thinks they know better and that more is better than less, but they don't have to deal with the patron complaints. -
3 votes
An error occurred while saving the comment Stacey van Groll
commented
We don't use this feature but the documentation has entries added for this and I observed them added to our OAS (just with no data).
Are you advising that they are being used but you're not seeing any data recorded?
The action is: Clicking on a resource type filter bar - <1-11>
The user selected All (position 1) or a resource type (position 2-11) in the Resource Type Filter Bar.
Data for this action is available starting with the May 2023 release.
https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/Primo/Analytics/040Primo_Analytics_Subject_Areas/Primo_Action_Usage -
85 votes
An error occurred while saving the comment Stacey van Groll
commented
We cannot use Rapido, as Ex Libris has excluded Primo sites managed by Back Office sites from using it.
But I have this on my dealbreaker list anyway for Rapido if Ex Libris ever changed that decision, because of this hardcoded results issue. -
15 votes
An error occurred while saving the comment Stacey van Groll
commented
I reported this as a defect for Primo managed by Back Office more than a year ago in March 2022, and the case is in Development since then.
This is because the quicklinks also display in the Links section despite the configuration not including them.The data is <linktopdf> and <linktohtml>
Production configuration under Views > 61UQ > Tile List > Full Display > Full Results > Links to display in full results
Back Link
Link to TOC
Link to Abstract
Link to Review
Link to Price
Link to Finding Aid
Additional Link
Link to Union Catalog
lln02 -
4 votes
An error occurred while saving the comment Stacey van Groll
commented
We’ve used ‘Search collections’ as the consistent labelling because all of the options either have this initially, or have the option to expand to it with one click, per the November 2021 Release
* The lobby search box is for everything --- yes, agreed.
* The top-level collection search box is for the title of sub-collections in that area only --- this searches titles of child collections and items within the top-level collection in the initial query. I believe it’s quite common for sites to not have items directly within the top-level collection level when they also have child collections, but it can be seen as being done in the results split into section of Collections (x) and Items in the collection (y). Then there is the option to expand the search into all collections in Collection Discovery by the hyperlink option for ‘Try searching in all collections’
* The sub-collection search box is for items in that sub-collection only --- yes, with the same optional workflow to expand by ‘Try searching in all collections’Ex Libris advised this the possible options given the search scoping infrastructure.
I agree that the need for the extra click by initial scoping is a little less than ideal, but we haven't had any comments on this with our 'Search collections' labelling.
-
1 vote
An error occurred while saving the comment Stacey van Groll
commented
Could this be managed by making renewable false in the TOU but using the Block Preferences by override setting by role?
-
2 votes
An error occurred while saving the comment Stacey van Groll
commented
It this idea was approved, I would like to advocate that it should be opt-in, or the name data should be an addition, rather than a replacement for the IDs.
I'm aware that some sites may use data such as strings of numbers for IDs. At our site we have Primary IDs which are staff usernames and they are able to be identified without manual crosschecks, so this is not a factor.
A greater concern though is that names are changeable whereas Primary IDs are not. For example, we may have staff who have changed their names, for reasons such as personal relationships, by personal choice, or to reflect identity.
This becomes an issue when data displayed is the prior name which may cause distress to individuals as well as confusion for other staff.
It could be that Ex Libris would update this data retrospectively for name changes, but this would presumably add considerable complexity to the development, such as if the account had been deleted from Alma.
As such, we would choose not to enable this feature, if indeed it was added as opt-in and would support Ex Libris using Primary ID consistently for the above reasons. -
1 voteStacey van Groll
shared this idea
·
-
55 votes
An error occurred while saving the comment Stacey van Groll
commented
100% support for this submission. As a site using Primo Back Office, I have no idea how I'm meant to transfer all our 7 years of good work in this area to Primo VE when there are such massive limitations.
And also some frustration that there appears to be an expectation that we should just give up and sacrifice this, and move regardless. Especially when some of this work includes also areas of the record which we cannot touch at all in VE, including normalisation of availability statements and links and facets.
It simply is not possible with VE development currently, and Ex Libris needs to address this so that we can properly present all our collections.Stacey van Groll
supported this idea
·
-
119 votesStacey van Groll
supported this idea
·
An error occurred while saving the comment Stacey van Groll
commented
I’ve been directed here by Ex Libris after putting in documentation feedback that I couldn’t see any information on expectation of a default for ‘Export to Libraries Australia’, which appears to be ‘Don’t Publish’. We want autonomy to be able to decide for ourselves what records are marked automatically to be externally published, and not be forced to have our records marked to publish to OCLC and not to Libraries Australia. MD Editor Templates are hardcoded to this as well. Also, the MARC21 Bibliographic Normalize on Save task options for both OCLC and Libraries Australia do not work (closed Pending Work Plan case from 2018). The only options are trying to catch as many records as you can by import profile management tag settings and endlessly creating sets and running manual jobs. This seems ridiculous for a LMS which purports to support us with the ability to streamline by automating our work. It seems like that’s only true when what we want happens to match what Ex Libris wants.
-
0 votes
An error occurred while saving the comment Stacey van Groll
commented
This request might be better to submit for the Alma Idea Exchange, rather than Primo?
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.