When searching for items in the OPAC, the results page (opac-search.pl)will show number of holds placed on that record, but the number is incorrect. It does not show the same number as on the record itself (opac-detail.pl). Christopher
Could the difference be that the result list show the number of items 'waiting' - while the opac detail shows the number of holds?
(In reply to Katrin Fischer from comment #1) > Could the difference be that the result list show the number of items > 'waiting' - while the opac detail shows the number of holds? It does, indeed, appear to be the case. :/ This is extremely confusing. If I am getting confused, I can't imagine patrons are doing any better with this. I'm not sure how much of the information on that line in the results is helpful to patrons. At least for US public library patrons, patrons would want to know how many copies there are, how many are available (and MAYBE where), and how many holds are on the item. I doubt they care about how many items are in transit, or how many are waiting for people. Frankly, I would ditch the transit info and change the holds to total holds. Christopher
The result list groups the items by their status, so the number should add up to the total number of items on th record. I think if we added the 'holds' there, it might result in people thinking there are more items than there really are. Maybe the trick would be to use a better term for the result list? Perhaps using "Waiting on hold shelf"?
(In reply to Katrin Fischer from comment #3) > The result list groups the items by their status, so the number should add > up to the total number of items on th record. > I think if we added the 'holds' there, it might result in people thinking > there are more items than there really are. > Maybe the trick would be to use a better term for the result list? Perhaps > using "Waiting on hold shelf"? Respectfully, I get that. The number of holds waiting and in transit are just part of the stats. However, I don't think they are stats that most patrons would care about in general. I think we're providing the patrons with a lot of information they don't necessarily need. Personally I would prefer a total count, number of holds, and MAYBE the location of available items. Everything else is meaningless to me as a patron. I know we all look at this from different perspectives, so I get that what I think isn't necessarily the norm or the majority. But on behalf of all the patrons that have to wade through a sea of information to find what they are looking for, I think we are handing out some bits of information that we could do without, and I think we could be a little more on point. Perhaps we could have Total Copies, Total Copies Available, and Total Holds? Maybe a sub category showing Copies Available at: and then a list of libraries with an option to have call numbers showing or not? I'm not sure that call numbers are absolutely necessary on the discovery layer, although I guess it might help in determining type of material and target audience.
(In reply to Katrin Fischer from comment #3) > Maybe the trick would be to use a better term for the result list? Perhaps > using "Waiting on hold shelf"? I do agree that we should change the phrase. Something shorter like "Waiting holds"?
FYI, I did use jQuery to change the phrase to "Holds waiting" rather than "On hold", and I've changed the phrase "Total holds" to "Hold requests" on the record itself. I think this makes it more clear. I think this communicates the difference better. However, I still think the availability info on the opac-search.pl page is a little overkill and confusing for Koha patrons in general. Let's keep talking about this.
Hi Christopher, I think my argueing was just about this being a bug or not :) I am sure there is room for improvement and probably a need for flexiblility. We also got a few prefs already in that area, to influence how the information is shown. Maybe we could move comment 4 to a enh request and discuss if we want to change the terms in general?
(In reply to Katrin Fischer from comment #7) > Hi Christopher, > > I think my argueing was just about this being a bug or not :) I don't think you are arguing. I think we are having a healthy discussion. :) > I am sure > there is room for improvement and probably a need for flexiblility. We also > got a few prefs already in that area, to influence how the information is > shown. What prefs? Would you mind pointing me to them? > Maybe we could move comment 4 to a enh request and discuss if we want > to change the terms in general? Done: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13337 :) Christopher
> > I am sure > > there is room for improvement and probably a need for flexiblility. We also > > got a few prefs already in that area, to influence how the information is > > shown. > > What prefs? Would you mind pointing me to them? > I haven't played much with them so far, but those are the ones I found: OPACItemsResultsDisplay HighlightOwnItemsOnOPAC HighlightOwnItemsOnOPACWhich OpacItemLocation
For my part, I am with Christopher here. I'd like to see a simplified approach to the results page. Patrons don't need all that information. They need to know if the book is available now, how many there are, and an idea about how long it could take to get it. Something like 10 items, 8 unavailable. and a preference whether to show the number of holds outstanding on an item, because patrons don't need to know how many they can't have because they are sitting on the hold shelf
(In reply to Liz Rea from comment #10) > For my part, I am with Christopher here. I'd like to see a simplified > approach to the results page. Patrons don't need all that information. They > need to know if the book is available now, how many there are, and an idea > about how long it could take to get it. > > Something like > > 10 items, 8 unavailable. > > and a preference whether to show the number of holds outstanding on an item, > because patrons don't need to know how many they can't have because they are > sitting on the hold shelf Let's generate an 'items' index in ES and make use of JOIN operations :-D