New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sorting a collection by relevance doesn't make much sense #4308
Comments
thanks for this! some notes for whoever picks this up: it looks like these views just use the default blacklight config for as a first step, the implementation of that helper could be cc: @samvera/hyrax-repo-managers @samvera/hyrax-ui-ux-advisors is it a good idea to remove "relevance" from this drop down? is "Title [A-Z]" a good default? are the other drop down fields for sort good? |
collection show views were using the default blacklight config for `active_sort_fields`. there's not much point in sorting by relevance, and other changes to how these sort options present may be desirable on a per-application basis. to make it easy to make this kind of change, add a `collection_member_sort_fields` helper. for now, its implementation is just a call to the existing helper, so actual behavior is fixed for this commit. connected to #4308.
collection show views were using the default blacklight config for `active_sort_fields`. there's not much point in sorting by relevance, and other changes to how these sort options present may be desirable on a per-application basis. to make it easy to make this kind of change, add a `collection_member_sort_fields` helper. for now, its implementation is just a call to the existing helper, so actual behavior is fixed for this commit. connected to #4308.
collection show views were using the default blacklight config for `active_sort_fields`. there's not much point in sorting by relevance, and other changes to how these sort options present may be desirable on a per-application basis. to make it easy to make this kind of change, add a `collection_member_sort_fields` helper. for now, its implementation is just a call to the existing helper, so actual behavior is fixed for this commit. connected to #4308.
custom sort configuration for these pages made it into some discussion in Slack questions whether we should treat this as an issue with collections page at all, or whether it's better considered as an issue with with blacklight's approach to "fallback" sorting. BL implicitly falls back on 'updated' when no search term is present, and we'd like this behavior to be explicitly visible to users via the drop down. |
Descriptive summary
On 2.6.0 (confirmed on nurax running today's master), collection pages allow you to sort the works in them. These sorts are the same sorts defined in the catalog controller and displayed on the search results page.
However, the default sort -- relevance -- doesn't make any sense here. The user hasn't entered any search terms, so there's nothing for the Works to be relevant to.
Rationale
The default behavior is not useful for end users.
Expected behavior
As an end user, I go to a collection page (like https://libarchive.linnbenton.edu/collections/gm80hv33v?locale=en). The default sort is something meaningful, like date uploaded descending.
Actual behavior
As an end user, I go to a collection page (like https://libarchive.linnbenton.edu/collections/gm80hv33v?locale=en). The default sort is not meaningful (although it might happen to be date uploaded descending, just due to internal workings of the system).
The text was updated successfully, but these errors were encountered: