Search results should appear in a sensible order
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• Mholloway
	Jul 4 2015, 12:15 AM

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":

Screenshot_2015-07-03-17-08-43.png (1×720 px, 193 KB)

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.

Details

Related Changes in Gerrit:

	Subject	Repo	Branch	Lines +/-
	Fix search result ordering based on latest API.	apps/android/wikipedia	master	+13 -37
	Revise search result ordering logic	apps/android/wikipedia	master	+7 -19

Customize query in gerrit

Related Objects
Search...

Status	Assigned	Task
Resolved	Dbrant	T104746 Search results should appear in a sensible order
Duplicate	dcausse	T108554 index appears to be missing from search API responses if the page is a resolved redirect
Resolved	EBernhardson	T92796 Prefix search API doesn't return "index" field when "redirects" is enabled.

Event Timeline

• Mholloway created this task.Jul 4 2015, 12:15 AM

• Mholloway raised the priority of this task from to Needs Triage.

• Mholloway updated the task description. (Show Details)

• Mholloway added a project: Wikipedia-Android-App-Backlog.

• Mholloway moved this task to Needs Triage on the Wikipedia-Android-App-Backlog board.

• Mholloway subscribed.

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 subscribed.

Dbrant moved this task from Next Sprint to Current Sprint on the Wikipedia-Android-App-Backlog board.Jul 21 2015, 12:10 PM

Dbrant added a project: Mobile-App-Sprint-62-Android-Summer-Breeze.Jul 22 2015, 2:42 AM

• Mholloway claimed this task.Jul 24 2015, 8:32 PM

• 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

gerritbot added a project: Patch-For-Review.Jul 24 2015, 9:28 PM

• Mholloway moved this task from Doing to Code Review on the Mobile-App-Sprint-62-Android-Summer-Breeze board.Jul 24 2015, 9:33 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.

• Mholloway moved this task from Code Review to Doing on the Mobile-App-Sprint-62-Android-Summer-Breeze board.Jul 27 2015, 1:38 PM

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.

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.

Dbrant removed a project: Mobile-App-Sprint-62-Android-Summer-Breeze.Jul 29 2015, 4:56 PM

Dbrant moved this task from Current Sprint to Tracking on the Wikipedia-Android-App-Backlog board.

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

Dbrant mentioned this in T108554: index appears to be missing from search API responses if the page is a resolved redirect.Aug 10 2015, 12:03 PM

Dbrant added subtasks: T108554: index appears to be missing from search API responses if the page is a resolved redirect, T92796: Prefix search API doesn't return "index" field when "redirects" is enabled..Aug 10 2015, 12:13 PM

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

• Deskana closed subtask T92796: Prefix search API doesn't return "index" field when "redirects" is enabled. as Resolved.Aug 25 2015, 7:02 PM

• Deskana reopened subtask T92796: Prefix search API doesn't return "index" field when "redirects" is enabled. as Open.Aug 27 2015, 4:37 PM

Dbrant moved this task from Tracking to Next Sprint on the Wikipedia-Android-App-Backlog board.Aug 27 2015, 8:08 PM

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

Dbrant mentioned this in rAPAW03dfeecd2834: Fix search result ordering based on latest API..Aug 31 2015, 9:01 PM

Dbrant moved this task from Next Sprint to Current Sprint on the Wikipedia-Android-App-Backlog board.Sep 2 2015, 4:58 PM

Dbrant added a project: Mobile-App-Sprint-65-Android-Terbium.Sep 2 2015, 5:06 PM

Dbrant moved this task from To Do to QA Signoff on the Mobile-App-Sprint-65-Android-Terbium board.

• 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