Page MenuHomePhabricator

Decrease search complexity on Places
Closed, ResolvedPublic

Description

Finding

Users often submit a search using the keyboard before suggested search results load, this works well for broad geographic locations, but can cause problems when users are searching for specific articles

Video: http://www.usertesting.com/videos/ERMWSd4Sxe4uGaIMmsI3SA/clips/3?note_id=clip-1236274&shared=iqy_M6m0

Updated interactions

  • Disable search button on keyboard while results are loading
  • Disable search button on keyboard when there are no suggested results (eg. searching for 'asdfkla;' or 'Nwe Yrk')
  • Load top result (if available) when users taps on keyboard search button
  • If there are no results for a 'Top read matching "user's search string"' result, load empty map with the message 'No results found. Did you mean closest matching result?' This interaction is covered by T165097.
  • When user taps on the 'x' in the search field to clear their search and then closes the search overlay their search should be cleared (their previous search should NOT persist) and the default search should be re-enabled (eg. 'Top read' with no search string)
  • Add a progress bar below the search field and above the search results to show users that a search is in progress.
User flows tap to view larger
Places search user story.png (1×2 px, 219 KB)

Message designs

No results map.png (1×750 px, 799 KB)

Zeplin: https://zpl.io/Z21OVbb

Test Cases

  • Don't allow empty searches
  • Disable keyboard searches while suggestions are being loaded
  • User types "Pa", results are loaded
    • taps keyboard Search button, top result "Pakistan" is loaded
      • This was existing behavior, no changes necessary
    • taps "Top read matching 'Pa'", top read articles in current area are loaded
      • This was existing behavior, no changes necessary
  • User types "Paris", taps "Top read matching 'Paris'", no articles in current area, button appears with "Did you mean *_Paris_*"
  • When user taps on the 'x' in the search field to clear their search and then closes the search overlay their search should be cleared (their previous search should NOT persist) and the default search should be re-enabled (eg. 'Top read' with no search string)
    • This was existing behavior, no changes necessary
  • Add a progress bar below the search field and above the search results to show users that a search is in progress.
  • Move the top suggestion to the top of the search list once the search finishes

Event Timeline

cmadeo updated the task description. (Show Details)

I added some new interactions and a user flow diagram to illustrate these new interactions.

@cmadeo I did a little research, it doesn't seem like the Search button on the keyboard can be actually *disabled* but we can ignore it until suggestions have loaded

http://stackoverflow.com/questions/9721668/how-can-i-disable-enable-uisearchbar-keyboards-search-button

@AMroczkowski Ah! Okay, so will this be similar to how the search button acts on Search in the app (non-Places search).

On a different note, it would be great to discuss the keyboard search button on non-Places search in the app at some point in the future as it doesn't actually enter a search currently!

cmadeo removed cmadeo as the assignee of this task.May 3 2017, 2:25 PM
JMinor lowered the priority of this task from High to Medium.May 16 2017, 6:52 PM

@AMroczkowski Visually this is looking good! Before I move this over to needs QA I'd like to discuss 'did you mean' and other search suggestions as well as the keyboard search button behavior. I might have lost track of what falls under this ticket and child tickets, so let's just check-base on Tuesday before moving this ticket forward.

@cmadeo I double checked and it is definitely ignoring Search button clicks while results are still loading. I think often it just happens very quickly

@AMroczkowski thanks for checking! Should I move this over to needs QA then? Or would you like the description to be updated first? Thanks!

@AMroczkowski and I had a conversation on Tuesday where we discussed how the current functionality of the API would affect Places search. We decided that including a 'Did you mean' in the search results would not provide a satisfactory experience for users as the 'did you mean' results would not necessarily be a better match than the suggested search results. In the future if we can have a better idea of popular places and apply that weighting to the 'did you mean' results, we might want to consider building this feature.

ABorbaWMF subscribed.

Considering this fixed for now. It sounds like more improvements are coming.