Improve Search Results Experience when 0 results

[mekarpeles]

If the user is in mode=ebooks mode for search, but there are no results, we should fall back to search mode=everything and/or at least show the user some other options + a useful message which doesn't feel like a dead-end

[mekarpeles]

We're going to fall back to the next /search/inside full-text search! cc: @brewsterkahle

[mekarpeles]

History

1. Some searches return non results -- this is not a great experience
2. We had implemented a fallback to full text search in 1001/feature/fts fallback when 0 search results #1025
   this was expensive and could be confusing so we rolled back the change in Disable auto full text search fallback #3288

We still don't want dead ends. The revised proposal is to:

• show no results w/ warning message
• Instead of showing the text, "Search for books containing the phrase [...]" as a link, change it to the text, "Showing books containing the phrase [...]" and asynchronously load up to 5 fulltext search results w/ a link to switch to "see more" which goes to the /search/inside tab

[tfmorris]

I recommend looking at this through a different lens. Dead ends are unsatisfying, but the best solution is to avoid them in the first place, not to send the user on a detour down a different dead end.

I recently copied the book title, "Cornell ’77: The Music, the Myth and the Magnificence of the Grateful Dead Show at Barton Hall," from an article and pasted it into the OpenLibrary search box resulting in exactly zero matches. Searching "All" instead of "Title" also returned zero matches. Switching to full-text search resulted in ... zero matches. Can you spot the one word (out of sixteen) that the article author transcribe wrong for Cornell '77: the music, the myth, and the magnificence of the Grateful Dead's concert at Barton Hall?

If search returned results which were close (I consider 15 of 16 words close), there would be many fewer dead ends to worry about. This applies to single letter transpositions, small typos, and all the other things the Google & Duck Duck Go handle effortlessly, but completely stump OL Search.

[Ashisaphnx]

Would it be possible for the search function to look for each word, and display the results in order of most similar words?

[Ultare1717]

Hello, I am a student from the University Of Toronto. Would it be possible for me and my group to work on this in case this issue is still open?

[mekarpeles]

Related to #8740

[merwhite11]

@mekarpeles Hello Mek, I'd love to take this issue on.

[merwhite11]

@mekarpeles
Reading through these comments again and actually not sure what the issue is. Is the goal to implement @tfmorris 's suggestion : ?

I see noted that the issue was fixed by #1025 ..but when I search for a result with a typo, it's still turning up 0 results:

Please clarify the reqs for this and happy to get to work on it.

[mekarpeles]

@tfmorris, @benbdeitch has been working on an fuzzy search effort #8873 to address #6923. An issue exists for this, a PR-in progress exists for this.

@merwhite11 This issue is calling for something different, which is --

If you are on the All or Books tab and you perform a search and there are 0 results found through regular search, before showing "No results found" use javascript to perform a Full Text Search using the https://openlibrary.org/search/inside.json API and, if there are any results, show a card with up to the first e.g. 3 matches as described in #8884

See the design here for inspiration: #8884 (comment)

We also want to do this in a way where (when possible) we're keeping the design of the different search pages consistent, see: #8891

[merwhite11]

@mekarpeles @jimchamp
Reiterating what we went over in today's meeting. Thank you for all the guidance :) --

Context:
When search returns 0 results, current UI displays a No Results widget and a link to Search for books containing the phrase..

Goal:
On browsers that support JS, the link needs to be replaced by a suggestions card aka Full Text Search Results Preview Box outlined here: #8884 (comment)

Process:

1. User enters search → search controller renders template displaying results
2. Add a check in template that checks if there are 0 results (aka SOLR_EDITIONS?)
3. If there are 0 results, make a call from template to a JS function that calls a Partial
4. Partial will return Full Text Search Results Preview Box HTML
5. The preview box will be a template or a macro that will be inserted into the original work_search template.

Questions:

1. Is JS function going to be written in a separate file (eg. plugins/openlibrary/js/preview-box) and called from work_search.html template? Please clarify step 3 of process.

Future Issues / Out of scope:

1. Apply preview box to Search Inside search results: Search Page: Add "Search Inside" async preview card #8884
2. Apply preview box feature to Authors, Subjects, Lists and Advanced Search when 0 results
3. Include preview box feature to all search results (regardless of how many results returned)

References:

Similar Partials use-case: https://github.com/internetarchive/openlibrary/blob/37db01e97fafaeec1f36951050b06f836442ca71/openlibrary/plugins/openlibrary/js/affiliate-links.js

Partials docs (to be added to!):
https://github.com/internetarchive/openlibrary/wiki/Frontend-Guide#partials

Separate but possibly overlapping issue of unifying UI for widget being worked on here: #8891

[jimchamp]

Thanks @merwhite11!

Is JS function going to be written in a separate file (eg. plugins/openlibrary/js/preview-box) and called from work_search.html template? Please clarify step 3 of process.

This section of our Frontend Guide may help.

For this issue, you'll probably want to make a new .js file for your code. We avoid inline JS, so you won't be calling any functions in the template. Instead, we add functionality to elements having specific ids or class names in our main index.js file.

For example, you could replace the existing markup in the work_search.html template with an empty div having id="live-fulltext-search-container" (or any other unique identifier). In the main index.js, you would search for the element with the unique id, and, if one exists, your function would be imported and executed. In this example, your function would probably send the search query to the backend, which would respond with an HTML string that you can render in the empty #live-fulltext-search-container div.

That's the gist of it. I've glossed over a lot of things, so feel free to reach out over Slack if you have questions and would like a quicker response.

[merwhite11]

Progress report --

• All data coming in and linking to correct pages on clicks
• First draft of formatting for md & lg screens complete

Still to do --

• Format card for small screens / responsive
• Add browse icon in header
• Add page number (before quote or below)
• Add loading indicator
• Update Partials info in docs

[merwhite11]

Another progress report 6/7/24:

Completed:

• Responsive styling
• Title and author truncated for mobile
• Quotes around text
• Error message display before

Still to do:

• Blue link default for title and author in mobile
• Try different fonts for quotes to make it stand out more obviously as a quote
• Determine how many book results should be displayed for mobile and desktop
• Determine if header should go on bottom of card
• Add loading indicator
• Update Partials info in docs

[jimchamp]

Thanks @merwhite11! Just in case you didn't know, we have a loading indicator macro that can probably be used as a placeholder here.

[merwhite11]

@mekarpeles @jimchamp

Opened the pull request and completed a draft of Partials docs revision:
https://docs.google.com/document/d/1Ays0kw1tcYSj4IuMIthSS_jw0TbrxHmDuqCoVyoqet0/edit