Bug 4148 - Sorting by author is confusing to users
Summary: Sorting by author is confusing to users
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Galen Charlton
QA Contact: Bugs List
URL: cgi-bin/koha/opac-search.pl?idx=kw&q=...
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-10 01:04 UTC by Nicole C. Engard
Modified: 2023-01-07 21:08 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
search results with authors not in alpha order (50.87 KB, image/png)
2010-02-10 13:04 UTC, Chris Cormack
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:23:42 UTC


---- Reported by nengard@gmail.com 2010-02-10 13:04:54 ----

Created an attachment
search results with authors not in alpha order

See the attached image.  I ran an advanced search and chose to sort by Author A-Z and my results were not sorted.  The other sorts seem to work A-OK - it's just this one that's not doing anything - or not doing what I'd expect.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:23 UTC  ---

This bug was previously known as _bug_ 4148 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4148
Imported an attachment (id=1873)

Actual time not defined. Setting to 0.0
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
The original submitter of attachment 1873 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Owen Leonard 2010-08-19 16:23:17 UTC
I think the problem may be that the sort is done on 100a, but the XSLT displays author information from other fields too. That means that if a record has, for instance, multiple authors under 700 but no 100, it will be sorted at the top because of "nothing comes before something."

It's clearer if you have XSLT turned off because you can see the authors as "[empty] [empty] [empty] Akpan Alexie Anderson."

Could that be it?
Comment 2 Owen Leonard 2014-07-11 16:05:30 UTC
I still think the above explanation is correct. Does that make this bug invalid (since the search *is* sorting by author) or does that redefine the scope of the bug as "advanced search should include more than just 100a when sorting by author?"
Comment 3 Danielle Elder 2014-12-18 00:05:03 UTC
I think the sort should look at other than 100a field for a sort on author.
Comment 4 Katrin Fischer 2016-04-29 08:11:10 UTC
If we include more than 100$a - how should we deal with multiple fields? 100$a and several 700...? Always use the first?
Comment 5 Fiona Borthwick 2017-06-26 11:37:52 UTC
One of our new customers has reported this also. It is not just the case for the Advanced Search - quick search is the same.  Both OPAC and staff.
Comment 6 Owen Leonard 2017-06-26 13:09:18 UTC
(In reply to Fiona Borthwick from comment #5)
> One of our new customers has reported this also. It is not just the case for
> the Advanced Search - quick search is the same.  Both OPAC and staff.

It's certainly confusing for the patrons that an author A-Z search returns seemingly nonsensically sorted results first, but this bug isn't as simple as "fix sorting." Koha is sorting correctly, because "nothing comes before something." When sorting on 100a, results which have no 100a will be sorted first.

Is it even possible for Zebra to create an index on "100a if present, 700a if not, but use the first 700a as sorted by first and second indicators?"
Comment 7 Katrin Fischer 2019-05-04 13:48:35 UTC
 
> Is it even possible for Zebra to create an index on "100a if present, 700a
> if not, but use the first 700a as sorted by first and second indicators?"

This seems awfully complicated. I wonder how other systems realize author sorting and if it is even offered?
Comment 8 Katrin Fischer 2023-01-07 21:08:43 UTC
Changed the bug description a little since we have concluded that it works ok. Thinking about it, maybe it should use 100, 110, 111, but I am not sure if using the 700 will not give even more confusing results unless we can limit to certain relator terms... and then it would require them to be catalogued correctly too. Maybe the safest bet would be to handle the 'no 1xx to sort' by sorting them to the end if possible?