Jesse Kruppa (UCR)
My feedback
24 results found
-
223 votes
An error occurred while saving the comment -
47 votes
-
24 votes
-
5 votes
-
56 votes
-
19 votes
-
17 votes
-
333 votes
Dear all, we are currently working on a design concept for a new form interface option for cataloging, which will make it easier to navigate long fields and subfields - we will take this request into account as part of this design. See our "Form Editing for MARC 21 Bibliographic Records" roadmap plans for more information: https://knowledge.exlibrisgroup.com/Alma/Product_Materials/010Roadmap/Alma_Roadmap_Highlights_(2024-2025)/Metadata_Management#Form_Editing_for_MARC_21_Bibliographic_Records
-
55 votes
An error occurred while saving the comment +1 (million)
As noted in the the page for MARC 21 Format for Holdings Data, 863-865 - Enumeration and Chronology
The following subfields should exist for use:
Enumeration: a-h
Chronology: i-m, v
Descriptors: n-q
Numbers and codes: s-w
Notes: x, z
Control subfields: 6, 8Reference:
https://www.loc.gov/marc/holdings/hd863865.html
https://www.loc.gov/marc/holdings/(Personally, I'd like to be able to make holding/item records in MARC format like in the MDE rather than only in the text form, so I can ensure the metadata is being structured properly)
These are all valid subfields and should be imported as such.
Libraries should not have to put in an "enhancement" request for access to, or proper use and display of, fields and subfields in the metadata standard online library catalogs have used for more than 40 years and that this ILS was built to accommodate.
The standards are the very foundation of the catalog, and their thorough, correct implementation are a core requirement for catalog functionality.
-
19 votes
-
41 votes
-
6 votes
-
260 votes
An error occurred while saving the comment +1 and this does seem like a bug fix.
-
161 votes
Hi all,
This is planned to be handled in the Primo Next Discovery Experience User Interface.
More details on the new interface planning can be found here -
Best regards,
Yael.
An error occurred while saving the comment This is not an enhancement. This is a request for Primo to follow UX design guidelines.
Current implementation suggests to users that they can search "Any field" that "Starts with" their search term.
They cannot. This confuses and frustrates them. To make matters worse, the dropdown behavior is inconsistent (also a cause of complaint):
Selecting "Starts with" in the Search Type disables everything but Title and Holdings Call Number (if configured) in the Field Selector. The Field Selector removes the disabled options from view.
For the sake of consistency, selecting anything other than Title and Holdings Call Number ought to disable "Starts with" and remove it from view.
Behavior should be consistent: Either disabled items are removed from view in both dropdowns, or they are not removed from view in either dropdown.
If the disabled items are not removed from view, then they need to be obviously inactive.
UX design guidelines suggest to gray out any incompatible options and, optionally, ALSO display a tool tip explaining why the option is gray.
https://www.justinmind.com/blog/drop-down-list-design/#:~:text=What%20do%20we,with%20their%20mouse!
https://www.nngroup.com/articles/drop-down-menus/#:~:text=Gray%20out%20any,make%20it%20active.
-
317 votes
An error occurred while saving the comment As library staff and a patron, when I sort volumes I expect volume 9 to sort before volumes 12, 23, 38, 85, and 91.
Primo needs a better volume sort. Alphanumeric sorting does not play nicely with numbers. When numbers are stored and sorted as text, 12 will come before 3 because the sort is looking at the first character, not the whole value.
-
85 votes
An error occurred while saving the comment At my institution, I created a local field with just the 245c, labeled it "Responsibility" and added it to the full display on a new line. (Config > discovery > configure views > full record services > details)
SEE ATTACHMENT: I've attached some small screenshots to show our configuration and the result in Primo, as well as a potential alternate.
Local field: Add Local Field. DO NOT select any MARC21 fields.
Edit the normalization rule to the below:=====================
rule "Primo VE - Lds__"
when
MARC is "245"."c"
then
set TEMP"1" to MARC."245"."c"
create pnx."display"."lds__" with TEMP"1"
end
=====================(the blank varies depending on how many local display fields you have so far)
Save. Apply Rules.
That said: We shouldn't have to do this in the first place. The 245 c should be a default search/display field (All MARC fields and subfields should be able to display out of the box -- respecting indication rules-- without library staff having to specifically add them, frankly.) Institutions should only have to define the actual local fields. 69x, 79x, 9xx, etc.
(I wish the comment box here wasn't so tiny...)
-
145 votes
-
118 votes
-
112 votes
-
435 votes
An error occurred while saving the comment +3, this is an issue at the UC Library system as well.
As a user of the View It interface, I want to see services with current access prioritized at the top of the list, so that I can quickly identify available resources without being overwhelmed by those that only provide archive access.
Acceptance Criteria:
- A configuration option is available to prioritize services with current access (where the Until Year/Until Month/Until Day/Until Issue fields are empty) at the top of the list.
- The list of services is sorted by:
- - Accessible to the user:
- - - Current Access
- - - Archived Access
- - Not Accessible to the user (if applicable)
- The sorting is consistent regardless of interface, electronic collection name, or whether the service is held in IZ or NZ.
- Users can easily distinguish between services with current access and those with only archival access.