Page MenuHomePhabricator

Improve user experience in search
Closed, ResolvedPublic3 Story Points

Description

The problem
Mobile web search results flicker while updating and typing in the entire query.

Proposed Interaction
Assumption - User has typed some query and some results are showing below the searchbar
Next steps- User types in more characters > we request for results > we don't hide the current results > If new results take more than 2s on client side we show the spinner as in the mocks > ELSE we update the results without any spinner

the results can be tapped on in the 2s gap.

This is a minor change to current behavior and we would like to see how it improves the experience. if we see value in it we can invest more time.

Mock

Acceptance criteria

  • MFBeta-only
  • When a search request is sent:
    • The results are not removed
    • The results are tappable
    • If the request takes more than 2s to resolve:
      • A spinner is shown
      • Spinner background has opacity
    • When the search request resolves:
      • The results are replaced
      • If a spinner was shown, it is hidden

Suggested testing, RTL+LTR, portrait+landscape:

  • Android 2.3 Browser phone form factor
  • Android 4.x or higher Chrome phone form factor
  • Android 4.x or higher Chrome tablet form factor
  • iOS 9.3 iPhone Safari
  • iOS 9.3 iPad Safari
  • Opera Mini non-compressed (not extreme mode) Android 4.x or higher phone form factor
  • Opera Mini compressed ("Opera Mini" mode on iOS, "Extreme" mode on Android, inbuilt functionality on older devices like J2ME Opera Mini)
  • UC browser (not mini with compression) Android 4.x or higher phone form factor
  • UC Mini (with compression) Android 4.x or higher phone form factor
  • Windows 7.5+ Phone IE
  • Desktop Firefox
  • Desktop Chrome
  • Desktop Safari
  • Internet Explorer 11
  • Edge

From old description

We show the spinner all the time and update the full result for every change (it goes white and then paint the result). It makes the experience bumpy. Compare what the search looks like on the iOS app, where we update the rows that change (and no spinner):

We should for having the same experience on mobile web as on the iOS app.
we can't have the same experience because ios app assumes good internet connection. we can't assume that on web.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
dr0ptp4kt updated the task description. (Show Details)Aug 10 2016, 2:11 PM

@Nirzar would it be better to do Option A, but put the spinner directly over the results over a translucent modal? That way visually all of the images and text aren't disappearing, just hiding behind an opacity layer.

MBinder_WMF set the point value for this task to 2.Aug 10 2016, 4:55 PM
MBinder_WMF moved this task from Needs Analysis to To Do on the Reading-Web-Sprint-79-Uh-oh board.

^ The estimation is for the option A.

Here's what @jhobs is saying

will be less intrusive

and here's one more option

and here's one more option

I think you missed a screenshot, unless you were referring to my suggestion as the "one more option."

haha yes.

this was another option

I'd vote against T137068#2540526 (@jhobs suggestion) or Option D as we're also aiming to make the search results usable, i.e. interactive, while a search API request is ongoing.

we're also aiming to make the search results usable, i.e. interactive, while a search API request is ongoing.

though I agree with it, but it also changes the scope from only removing flicker.
as the task says improve user experience i think we can add more than one thing to do that. and if we consider this then the option A and D are out of the window.

now the question is where to put the loading indicator.

does everyone agree that the search results should be usable? if so, i will post options on where to put the indicator.

does everyone agree that the search results should be usable? if so, i will post options on where to put the indicator.

I really can't decide on this one since I can see arguments for both sides. In the interest of varying voices, I'll play devil's advocate here.

Allowing search results to be interactive during an API request means that the content under your thumb could change between the time you see it (and decide to press it) and your tap is registered. I could especially see this happening when on the move. Maybe another solution (assuming, for a moment, we use the variation on Option A that I suggested) could be to make the loading modal disappear upon tapping, cancelling the API request?

Jdlrobson assigned this task to Nirzar.Aug 11 2016, 8:39 PM
Jdlrobson added a subscriber: Jdlrobson.

Can you please update the description based on the discussion so this is ready to go for sprint kick off meeting.

@Nirzar, another suggestion is to use the toast to show the spinner.

Nirzar updated the task description. (Show Details)Aug 15 2016, 4:09 PM
Nirzar updated the task description. (Show Details)Aug 15 2016, 4:37 PM
Nirzar updated the task description. (Show Details)
Nirzar updated the task description. (Show Details)Aug 15 2016, 4:41 PM
Nirzar updated the task description. (Show Details)Aug 15 2016, 4:45 PM
Nirzar updated the task description. (Show Details)
MBinder_WMF changed the point value for this task from 2 to 3.Aug 15 2016, 4:47 PM
bmansurov moved this task from To Do to Doing on the Reading-Web-Sprint-79-Uh-oh board.
bmansurov updated the task description. (Show Details)Aug 16 2016, 11:18 PM

Change 305156 had a related patch set uploaded (by Bmansurov):
Beta: Improve search experience

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

jhobs updated the task description. (Show Details)Aug 18 2016, 5:01 PM

@Jdlrobson I've replied to your questions/comments. Can you take a look and let me know what you think before I upload a new patchset?

I've merged this but I'm seeing some edge cases where the search gets locked:

Case:

  1. Type S character
  2. Throttle to offline
  3. Type A character
  4. Throttle to WiFi

Expected: Search for A should retry or an error should show or nothing should happen
Actual: Spinner shows after several seconds and never clears

Case 2:
If I continuously mash keys and backspace it is possible to get the search results locked into spinner mode.

Change 305156 merged by jenkins-bot:
Beta: Improve search experience

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

I've merged this but I'm seeing some edge cases where the search gets locked:
Case:

  1. Type S character
  2. Throttle to offline
  3. Type A character
  4. Throttle to WiFi

Expected: Search for A should retry or an error should show or nothing should happen
Actual: Spinner shows after several seconds and never clears

Can you file a separate bug for this? This happens in stable too.

Case 2:
If I continuously mash keys and backspace it is possible to get the search results locked into spinner mode.

Can you record a screencast and upload it? Thanks.

@bmansurov i think we are going to need a better environment to test this one where results are often updated with every character you type like wikipedia. basically more varied articles on a wiki better it is to test this ticket.

I concur with Baha on his comments in T137068#2576785. I think it's fine to file a separate task for the issue that affects both versions of the search interaction. That being said, one simple solution may be to make the modal tappable, upon which it would be dismissed. I think this is a fairly common interaction that most users would be used to, although @Nirzar would probably be able to better answer that.

With that being said, I'm not sure this task should remain in -1, although I'm not sure it should quite move to Signoff yet either given Nirzar's comment above.

That being said, one simple solution may be to make the modal tappable, upon which it would be dismissed.

The ideal solution would be the loader not getting stuck. just like in the production. if there is a technical constrain we can think about the fallback like you mentioned here.

That being said, one simple solution may be to make the modal tappable, upon which it would be dismissed.

The ideal solution would be the loader not getting stuck. just like in the production. if there is a technical constrain we can think about the fallback like you mentioned here.

The problem is that the spinner gets stuck in production too. Since the problem is outside the scope of this task, I suggested not changing the scope of the task.

Since the problem is outside the scope of this task, I suggested not changing the scope of the task.

+1 I agree.

i didn't know it gets stuck in production too.

Case 1: Filed as T143741.
Case 2:

- this should be fixed as part of this task.

Thanks for the screencast.

Peter added a comment.Aug 24 2016, 8:58 AM

Think this will be cool, really exciting!

@Nirzar I'm not sure about getting suggestions after one/two characters do we actually get a good results? Thinking getting suggestions after maybe third character makes more sense since we then are in better shape to deliver something closer to what the user want. Or whatever now the magic number of characters can be that helps the user :)

@Nirzar I'm not sure about getting suggestions after one/two characters do we actually get a good results? Thinking getting suggestions after maybe third character makes more sense since we then are in better shape to deliver something closer to what the user want. Or whatever now the magic number of characters can be that helps the user :)

yeah we can play around it. might be different for different languages though. but we can tweak it as a follow up.

Change 306446 had a related patch set uploaded (by Bmansurov):
Beta: clear the loading icon when a new search is started

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

Change 306446 merged by jenkins-bot:
Beta: clear the loading icon when a new search is started

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

To test please visit https://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page?mobileaction=beta and click on the search bar and type something.

Nirzar added a comment.EditedAug 24 2016, 8:45 PM

RIP flicker :)

The spinner has an issue in the implementation. partially because i didn't cover this in my mocks.

The spinner should be vertically center of the viewport, and if that is not possible then should be 10% from top.

right now spinner is vertically center to the device screen where it's hiding behind the keyboard.

putting it back in to do. drag it back to doing as needed.

let's not make this another task. i think it is part of this task.

Change 306561 had a related patch set uploaded (by Bmansurov):
Beta: vertically center-align the spinner of the search results

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

Change 306561 merged by jenkins-bot:
Beta: vertically center-align the spinner of the search results

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

bmansurov removed bmansurov as the assignee of this task.Aug 25 2016, 7:47 PM
phuedx assigned this task to Nirzar.Aug 25 2016, 8:31 PM

Over to you @Nirzar. Are you happy? Are you capable of being happy? What is happiness?

LOL yes. i'm happy!

From Urban dictionary:

Happiness: A small metal hinged box with pointy edges, rapped with barbed-wire and hidden in a dark room full of electric eels, razorblades, piles of salt crystals with fans behind them and random pools of lemon juice.

phuedx removed Nirzar as the assignee of this task.Aug 26 2016, 6:03 AM

Per the above.

phuedx added a comment.EditedAug 26 2016, 10:29 AM

For all of the following tests I introduced a five second delay to all API responses by adding the following to api.php:

sleep(5);

Passes:

  • Chrome (52.0.2743.116) on OS X El Capitan (10.11.6)
  • Firefox (47.0.1) on OS X El Capitan (10.11.6)
  • Safari (9.1.2) on OS X El Capitan (10.11.6)
  • Edge 14 on Windows 10
  • Opera 39 on Windows
  • Safari 9.3 on an emulated iPad Pro
  • Chrome (49.0.2623.91) on Android 6 running on a Galaxy S7
  • Chrome (49.0.2623.91) on Android 4.4 running on a Galaxy Tab 4 10.1
  • Opera Mini non-compressed (not extreme mode) Android 4.x or higher phone form factor N/A
  • Opera Mini compressed ("Opera Mini" mode on iOS, "Extreme" mode on Android, inbuilt functionality on older devices like J2ME Opera Mini) N/A

Failures:

  • Windows Phone 8.1 on an emulated Nokia Lumia 930
  • Safari 9 on an iPhone 6 Plus

Both browsers suffer the same problem: the viewport isn't resized when the virtual keyboard is open and so the spinner appears close the the top of the virtual keyboard. N.B. that Safari 9.3 on an emulated iPad Pro exhibits this problem but it's not noticeable in either orientation as the screen is so large.

bmansurov moved this task from -1 (Needs More Work) to Doing on the Reading-Web-Sprint-79-Uh-oh board.

Thanks, @phuedx for testing thoroughly.

Change 306957 had a related patch set uploaded (by Bmansurov):
Beta: show the search overlay spinner at 10% from top

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

Change 306957 merged by jenkins-bot:
Beta: show the search overlay spinner at 10% from top

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

bmansurov removed bmansurov as the assignee of this task.Aug 26 2016, 6:59 PM
  • UC browser (not mini with compression) Android 4.x or higher phone form factor

This also worked on a Samsung Wave II.

dr0ptp4kt closed this task as Resolved.Aug 26 2016, 9:04 PM
dr0ptp4kt claimed this task.
  • iOS 9.3 iPhone Safari - iPhone 5c
  • Windows 7.5+ Phone IE - HTC Trophy 7

Signing off.