Search results should clearly identify unavailable books

[mekarpeles]

Description

What problem are we solving?

Users are confused when they search for a book and the search result items don't explicitly / clearly state when the book is not readable (users assume it is).

Evidence

What does the experience look like today? What are the symptoms?

Relevant url:

https://openlibrary.org/search?q=potter&mode=everything

Screenshot (if possible):

Expectation

What should by happening? What will it look like / how will it behave?

Book search results which are not borrowable should explicitly have a "no ebook available" button, a la

#1712

Details

What page(s) are impacted?
https://openlibrary.org/search

Proposal

What is the proposed solution / implementation? Is there a precedent of this approach succeeding elsewhere?

Constraints

Which suggestions or requirements should be considered for how feature needs to appear or be implemented?

Priority

What evidence do you have this feature or bug is important to this audience? What can't we do because this bug exists or this feature doesn't exist? How many users will be (or are) impacted? What is the value to us and/or to each user impacted? How much time/money can be earned/saved?

Stakeholders

@ tag stakeholders of this bug / feature
@jdlrobson, @hornc, @cdrini, @seabelis

[mekarpeles]

<form>
  <input type="submit" class="unwait-btn" disabled="" value="No ebook available">
</form>

[tfmorris]

This behavior has apparently changed and I greatly prefer the previous behavior. The new layout clutters the display with information-free labels.

[mekarpeles]

@tfmorris acknowledged. I think we may be changing this to an actionable "sponsor" button in the near future. In the meantime, for better or worse, closing this issue as having been implemented

[tfmorris]

Presumably there should be a PR or commit linked here so that we know the offending commit to revert.

On a more meta level, how did we get from a cosmetic bug report being filed to a significant behavior change being implemented in under two weeks with zero discussion when we have so many other things which have been universally acknowledged as problems for many years?

Did the "stakeholders" who were tagged earlier (@jdlrobson, @hornc, @cdrini, @seabelis) agree that this was a beneficial change for the OL user community?

[seabelis]

I agree with @tfmorris that it does look more cluttered. I'm not sure I have the big picture, however. If there was some indication that users were confused and this has improved the situation, than perhaps the change was beneficial overall.

[mekarpeles]

This features was driven by an internal request from @JeffKaplan who was frequently responding to emails about patrons who were confused about the difference between readable and non-readable catalog efforts and was discussed w/ @bfalling, Alexis Rossi, and on at least one of our community calls. Broadly related to our prep work for #684 which attempts to address confusion between our works and editions page (topic of several community calls). The change was made in #1712.

when we have so many other things which have been universally acknowledged as problems for many years

This is a fair question. We did raise this as a topic during a past community call but there are a handful of meetings for which we don't have notes (we've since improved our processes to prioritize note-taking for our community calls, especially of decisions and supporting discussion). Some efforts are easier than others to fix and (while there are many important problems within our list of 400+ issues) I don't think we should discourage opportunities which could be quick wins. In this case, I hear that you do not agree with the decision and it's also abundantly clear the decision making process could have been documented better, but there was discussion and I decided @JeffKaplan's request was compelling enough that it was worth the prescribed fix. Open Library is not a static beast, happy for this to be discussed (not only the decision, but process changes you recommend) at our next community call -- I've added it to our agenda.

[waldenn]

Can someone comment on why the Search API returns books with "has_fulltext: true" but which are not readable online? The "ebook_count_i" value also does not indicate read access.

How can the user of the search API make sure a book is directly readable? Thanks!

[mekarpeles]

@waldenn I'm forking your comment to a new issue which reflects your question (so we can address it)

[tfmorris]

@waldenn Probably implied, but to make it explicit, don't co-opt unrelated issues, particularly ones which are closed, if you want a meaningful response.

[mekarpeles]

@tfmorris I think I can appreciate the misunderstanding in this case -- especially for someone new to the code base, this issue title seems to address the question (it isn't super unclear that this issue isn't about the search API and availability). Thanks for keeping our issues focused! Glad we were able to resolve the issue on #2065 :)