Stacey van Groll
My feedback
157 results found
-
59 votes
An error occurred while saving the comment -
312 votes
An error occurred while saving the comment Stacey van Groll
commented
I'm not an expert in authorities nor music works, but I think many of these UI problems are only in Primo VE, and not Primo (managed via Back Office)
* Record counts: Primo VE presents "20+ records", where Primo display the accurate record count eg 560 records (bar minor FRBR/Dedup variations)
* Records returned: Primo VE returns hits outside the author heading such as 600, where Primo presents from the author heading, in an author Browse Search, which I believe covers the left-anchored aspect also
* References: I'm not seeing any sign that Primo VE supports See or See Also references in Browse Search. Primo supports See but not See Also references in Browse Search
* Fields: I won't try to dive into all the subfields mentioned, but Primo sites have the ability to adjust the Browse rules as they see fit, such as if there is a subfield which they'd like to add to Browse Search
Harvard has a lovely Browse Search on Primo via Back Office, labelled in main menu as 'Starts with / Browse': https://hollis.harvard.edu/primo-explore/browse?vid=HVD2&browseQuery=bizet,%20georges&browseScope=author&innerPnxIndex=-1&numOfUsedTerms=-1&fn=BrowseSearch -
64 votes
An error occurred while saving the comment Stacey van Groll
commented
I have just had one of our staff ask after this, as it is very unnecessarily time-consuming to have to click in and out of the email address entries repeatedly just to see the key field of Description.
I completely agree with the submission in not wanting to create user accounts for this to try to solve what seems to be a very simple fix to add the option to the cog icon display to allow users to display the Description if they want to. -
174 votes
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
This feature is even more important with CDI.
I have complaints because users are getting results returned on the basis of one of their terms being only in the reference list in a URL of a citation.
In sum, completely irrelevant to their query, as nowhere else in the record metadata or the true full text of the work.
If you could force Primo (actually CDI) to only return results for your search terms when in close proximity, this would drastically improve this currently very poor situation.An error occurred while saving the comment Stacey van Groll
commented
I've submitted this for Primo NERS 2020.
Title: Add a proximity search operator
Request ID: 6682
Description: A proximity operator allows a researcher to specify that their search terms are present in records within a specified number of words from each other.
Summon already incorporates this feature, performed by enclosing search terms in quotation marks and using tilde and the number distance, for example "yeast bread"~10 finds material where "yeast" and "bread" appear within 10 words of each other.
See https://knowledge.exlibrisgroup.com/Summon/Product_Documentation/Searching_in_The_Summon_Service/Search_Features/Summon%3A_Boolean%2C_Phrase%2C_Wildcard_and_Proximity_Searching#proximity
Primo’s search algorithm incorporates an out-of-the-box assignment of higher ranking to records where search terms are closer together, but a proximity search operator gives a researcher explicitly more control over precise targeting of their search, which would also help to build greater understanding and confidence that the results will meet their needs and aren’t just from a mysterious “black box”.
With CDI coming soon to Primo, along with the massive increase in records, this trust building will be even more important to support researchers with tools to help sift through billions of results.
This tool should primarily support PNX and equivalent record metadata (both Primo via Back Office and Primo VE deployment models), but ideally would also incorporate standard existing extensions to remote data where available, including table of contents, abstracts, and full text.
See Idea Exchange submission: https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/19308214-proximity-search-operator-for-fulltext-search-in-pStacey van Groll
supported this idea
·
An error occurred while saving the comment Stacey van Groll
commented
I would love to see this in Primo, for full text and for record metadata, which are both available in Summon.
Our site was on Summon when I was studying myself and I constantly used this functionality for my research and assignments, as a key strategy to improve ranking of results for several keywords.
It is a vital tool for topic searches for beginner and more advanced researchers alike, to help sift through the hundreds of millions of results, by improved targeting of results and moving them into prominent position. -
315 votes
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
Some user-focused reasons to vote:
* Do you get queries from confused users who have searched in specific fields like Subject, Title, and Author, and then get results that have no sign of their search terms in those fields?
* Do your users wonder why they don’t see features like lateral links to find more records in these results, and don’t get the expected data they searched also exported to EndNote?Stacey van Groll
shared this idea
·
-
21 votesStacey van Groll
shared this idea
·
-
18 votes
An error occurred while saving the comment Stacey van Groll
commented
Hi Moshe,
I don't think such workflows for rejected requests are unknown to Ex Libris. It's necessary for monitoring, tracking, and resolving requests in a variety of scenarios, such as those which were cancelled while In Transit. This then hinders other workflows such as deleting a Library. Alma should not just 'disappear' a request as if it never existed, and we need visibility of all requests in Alma. This should already be the case under the 'All' filter selection, which is a defect. But it would also be helpful as this submission suggests to specifically add also a 'Rejected' filter. I am well aware from a case open for years that this filter was about to be released, and was even in Release Notes for May 2021, and then was pulled last minute.Stacey van Groll
supported this idea
·
-
103 votes
An error occurred while saving the comment Stacey van Groll
commented
I suggest to merge and rename to CDI this submission: https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/43803426-customize-cdi-activations-by-resource-types
-
135 votes
An error occurred while saving the comment Stacey van Groll
commented
It is really unfortunate that the new pagination option to display up to 50 results by user selection in May 2021 was not included in Collection Discovery, which keeps the same Load More Results.
This also adds a design inconsistency across Primo interfaces.
The design is that it will only apply to Collection Discovery if a user sets this already for the session in main Primo and then happens to navigate into Collection Discovery.
As it is a very common user pathway to provide direct links to specific collections, such as promoting content in a web page by direct link to a collection, this means that a user is guaranteed to bypass main Primo and then miss out on the opportunity to set an increase in page numbers. -
53 votes
An error occurred while saving the comment Stacey van Groll
commented
Doesn't that CSS code just hide the suggestion, Manuela? The DYM index is taking effect on the results in Primo VE, right? So the results would still be highlighted as 'light', using the original example.
I often think that the downfall of this feature is what seems to be the unnecessary complexity, so it is almost impossible to explain.
For example, if I test this on one of my local data sources with Hmong consumers, I get two results with among and consumers highlighted. If I choose the suggestion for 'among consumers', then I get 19 results, some of which have among and consumers also clearly in the data, including the title. But the key is that the two which showed up originally have apparently been triggered by the Levenshtein distance aspect of the distance between the two words (it's not documented what that is specifically that I can find), whereas in the other records the words among and consumer are further apart.
Try explaining that to a user!
And there's also the issue that only the local index is used to build the index from title and authors, which drastically reduces the value because it's missing out on more unique and newer terms that might only be in emerging research topics which only have articles thus far in CDI, which are actually more likely for users to misspell and need help with. -
70 votesStacey van Groll
supported this idea
·
-
9 votesStacey van Groll
supported this idea
·
-
94 votes
An error occurred while saving the comment Stacey van Groll
commented
I believe this was added on Primo via Back Office with the New UI in 2016/2017, by adding request.date to mapping configuration.
-
44 votes
An error occurred while saving the comment Stacey van Groll
commented
I believe this is technically possible by a different manner of running a Delete and Reload pipe. This can now be scheduled with NERS delivery of '6184: Make it possible to override Start Harvest date for Delete and ReLoad pipes' in May 2020. I run this process monthly, which seems sufficient for our 3 OAI data sources.
-
193 votes
An error occurred while saving the comment Stacey van Groll
commented
Users often like to see the options arrayed visually, rather than starting to type and only maybe being offered the autosuggest they'd like.
An autosuggest also constrains a user into typing, rather than clicking or tapping quickly.
We don't use Journal Search in Primo on Back Office, but we have Database Search active which has an A-Z. The use of this is high by the amount that it shows up on our Popular Searches results.
For example, in 2019 there were 3,857 clicks on "P", which is highly likely users quickly targeting to PubMed, as that is also our consistently most popular search. And "W" was 2,749 clicks, likely for Web of Science, and "S" was 2,331 likely for Scopus.
Perhaps we should consider, instead of deciding that we know better and telling users that the manner in which they want to search is old-fashioned, we should instead listen to the action of users and instead support them by offering both options? -
69 votes
An error occurred while saving the comment Stacey van Groll
commented
It's disappointing that this idea has so few votes when Evidence-Based Practice is such a focus, and this is vital data on user engagement with different types of formats ie electronic vs physical.
I have long contemplated putting in a submission for yet another gap of no actions recorded in Primo Analytics for View It services clicks.
These are partially recorded in Alma Analytics for Link Resolver, but completely missing for any Link in Record links for either remote PCI/CDI or external local sources. So few votes here makes me think I shouldn't bother,but at the same time it amazes me that this gap hasn't been filled already as standard.Edit: I'll take the plunge, here's an idea for the View It clicks
Primo Analytics - Add Actions for clicks on View It links, for both Link in Record and Link Resolver
https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/41480614-primo-analytics-add-actions-to-be-recorded-for-cStacey van Groll
supported this idea
·
-
135 votes
An error occurred while saving the comment Stacey van Groll
commented
There's no label just for 'Primo', Lisbeth, as this enhancement channel was designed before Primo VE existed. It applies to all flavours of Primo regardless of deployment model. My impression is that it only needs a Primo VE tag if Primo on Back Office already has the functionality, but Primo VE does not. I have seen incorrect entries for this though, as someone on a Primo VE site might not know that a idea isn't possible in Back Office either.
-
42 votes
An error occurred while saving the comment Stacey van Groll
commented
Have you considered use of the category tree? I understand completely if the submission is only for Subject headings, as would be found in the Subject facet in main Primo, but perhaps you might not be aware of the option to add a category tree. We use this for a curated list of subject categories and then have a second tier for 'Key Resources', as many other commenters have described as being desirable. This makes for a different search experience to main Primo, as offering our users a list designed just for a focus area for our university with databases chosen by the expert liaison librarian supporting that areas, which helps also to not just replicate the Primo search in two different places, as each offers a distinct feature.
-
45 votes
An error occurred while saving the comment Stacey van Groll
commented
Agreed - there should be holistic design as standard.
-
40 votes
An error occurred while saving the comment Stacey van Groll
commented
We'd want the option to do this by Fulfillment Unit though, rather than only an off or on setting at the institution level, as things like loans for 2 hours that circulate quickly and that users actively wait for need a time stamp.
I agree with Manu that this is a defect if Primo is not making the data meaningful for UI.
The normalisation rules should adjust for this, in adjusting the date to cover the range.
For example, if you check the PNX of a record with 199-, it can be seen to be adjusted to 1990 for sort and search, while it will display as 199- per the source record permitted cataloguing.
As another example with 260 ##$a[Vancouver :$bDuthie Books,$c199-?-1994], the range will be <startdate>19900101</startdate> <enddate>19941231</enddate>