Page MenuHomePhabricator

Search results should appear in a sensible order
Closed, ResolvedPublic

Description

We currently integrate redirect targets of our prefix search results into our search results list in order to display more useful results to the user. Redirect targets are inserted into "holes" in the results list in the order they appear in the "redirects" array in the query results. See https://gerrit.wikimedia.org/r/#/c/199285/ for details.

As currently implemented, this can result in odd search result ordering. See, for instance, the results of a search for "obama":

Here's the API result this is based on: http://pastebin.com/ENZf10fx

"I Got a Crush... on Obama" shouldn't be the first result displayed to the user for this query. We should find a better method of ordering our results -- it isn't the case that they're in a sensible order in the "redirect" array in the API results.

Event Timeline

Mholloway raised the priority of this task from to Needs Triage.
Mholloway updated the task description. (Show Details)
Mholloway moved this task to Needs Triage on the Wikipedia-Android-App-Backlog board.
Mholloway added a subscriber: Mholloway.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 4 2015, 12:15 AM
Mholloway updated the task description. (Show Details)Jul 6 2015, 5:26 PM
Mholloway set Security to None.
Dbrant triaged this task as Medium priority.Jul 17 2015, 3:41 PM
Dbrant moved this task from Needs Triage to Next Sprint on the Wikipedia-Android-App-Backlog board.
Dbrant added a subscriber: Dbrant.
Mholloway moved this task from To Do to Doing on the Mobile-App-Sprint-62-Android-Summer-Breeze board.

Change 226922 had a related patch set uploaded (by Mholloway):
Revise search result ordering logic

https://gerrit.wikimedia.org/r/226922

bearND added a subscriber: bearND.Jul 24 2015, 10:49 PM

Hmm, the results still don't seem right. For the example search term I get much better results if we restrict the prefix results to 15 or 16 (and the code on master). This weeds out some of the lower quality prefixresults.

We should really push for a resolution of T92796.

Yeah, we should probably decide on some acceptance criteria for this one.

In light of Brad's explanation on T92796, I'm wondering if just taking the limit down to 15 as you suggested is a good fix for our purposes now. (Anecdotally, I rarely look beyond the first handful of results when searching in the app before selecting a result or refining my search term.)

It's also worth noting that this seems like a pretty anomalous case -- I don't recall having any other searches return an oddball first result.

I would guess that taking the limit down to 15 would expose this issue for a different search case. The real solution is for all search results given by the API to contain an index, as requested in the aforementioned task.

Dbrant changed the task status from Open to Stalled.Jul 29 2015, 4:52 PM

This turns out to be wholly dependent on the search API returning results in the correct order (or supplying the correct index property with each result).
Let's not make this a blocker for production (esp. since this is the current behavior in production), and we'll keep a close eye on the bug filed against Search.

I don't think that this would expose this issue for different search terms if we lowered the limit. I think 15 or 16 would be fine with me. 13 would be the lowest I would go since that's how many search results can barely fit on my 9" tablet, and we wanted to avoid needing a full text search result in addition to the initial prefix search result without the user scrolling.

Having said that, I consider this more like a band-aid. A real fix would be to get the index set, as mentioned before.

Change 226922 abandoned by Mholloway:
Revise search result ordering logic

Reason:
Task is stalled; the real fix should happen on the API end.

https://gerrit.wikimedia.org/r/226922

A Play Store reviewer points out another interesting example of this undesired behavior: try searching for "tickle"!

Change 234925 had a related patch set uploaded (by Dbrant):
Fix search result ordering based on latest API.

https://gerrit.wikimedia.org/r/234925

Change 234925 merged by jenkins-bot:
Fix search result ordering based on latest API.

https://gerrit.wikimedia.org/r/234925

Mholloway removed Mholloway as the assignee of this task.Sep 2 2015, 5:08 PM

Checked with 2.0.110-alpha-2015-09-02 on Nexus 5(Android 5.1.1)

Note: The issue is still present in 2.0.108-r-2015-08-04 ( search criteria: 'obama', 'tickle' ).

Also, search more relevant results are returned for cases

  • when search criteria includes multiple words
  • for misspelled search criteria
  • for multi-word search criteria typed slowly - before it looked that the search results were stuck despite typing more words to search


Dbrant closed this task as Resolved.Sep 14 2015, 12:13 PM
Dbrant claimed this task.