Page MenuHomePhabricator

Provide the "containing... <search term>" right away instead of waiting for an API request
Open, LowPublic

Description

When I'm using a computer with slow internet conection, it is really inconvinient having to wait the API request
https://en.wikipedia.org/w/api.php?format=json&action=opensearch&search=EXAMPLE&namespace=0&suggest=
to complete before I get the option to search pages containing the EXAMPLE.

There is no reason to wait for that since it will always point to
https://en.wikipedia.org/w/index.php?search=EXAMPLE&title=Special%3ASearch&fulltext=1
independently of the API response.


Version: unspecified
Severity: enhancement

Details

Reference
bz40855
Related Gerrit Patches:

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:06 AM
bzimport added projects: Vector, JavaScript.
bzimport set Reference to bz40855.
bzimport added a subscriber: Unknown Object (MLST).
He7d3r created this task.Oct 8 2012, 12:40 PM
Majr added a subscriber: Majr.Feb 12 2015, 11:38 AM

Change 273436 had a related patch set uploaded (by Majr):
searchSuggest: Show "containing..." option immediately

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

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 26 2016, 11:29 AM
Majr claimed this task.Feb 26 2016, 11:39 AM

I've submitted a patch which does this, though we might want to discuss if showing it immediately is actually desired (technically, there is still a 120 ms delay; although this could be removed if desired).

The main issue I see is the suggestions popping up just as you go to click it, and you accidentally click on one of the suggestions instead (although I guess most people would press the down arrow and enter, and fortunately the focus stays in place when the suggestions pop in, so that will still work properly).
This situation could be reduced by adding a set delay. It would act like a timeout, where the containing option will display if the suggestions are taking too long.

We can also change the design slightly to have the "View search results..." link be a small hint at the top of the list below the input field (as opposed to at the bottom).

I've noticed the same irritation when typing something with lots of search results and changing the query to something that yields only a few and times when it hangs one can also mis-click the bottom that has then moved up a bit as the list shrunk.

Majr added a comment.Feb 27 2016, 1:42 PM

I can foresee a lot of complaints about having to press an extra button to get to the suggestions with that approach.

It seems crazy, but what if we put it above the search box? It would always be in the same spot and be a single button press away, while not requiring an extra button press to get to the suggestions. It would probably look weird though. :/

@Majr I made a few comments on your patch. I would appreciate your reply. I'm not too familiar with this codebase, so it would help to do any cleanup separately so I can review it more promptly for you.

We can also change the design slightly to have the "View search results..." link be a small hint at the top of the list below the input field (as opposed to at the bottom).

I can foresee a lot of complaints about having to press an extra button to get to the suggestions

To clarify, you're referring to when a user types a search phrase and uses the arrow keys on the keyboard to navigate from the input field down to the first suggestion. I'd estimate that it is far more likely for a user to click on the result with their mouse.

As for keyboard navigation, it's a trade-off either way. Either it's one more press to skip over the "View results" entry. Or you could argue it saves 10 key presses when trying to get to the "View results" entry. I realise there is also the ability to use the up arrow from the starting point to go "-1" to the bottom. That's a bit of an advanced use case though.

In the end, I think design and UX wise it makes sense to keep the design unchanged and leave "View results" at the bottom of the list of suggestions.

Trying to render it early only irritates users and also has the potential of making the perceived performance worse by introducing an extra rendering step. All results + viewmore in less than a second is a lot better than seeing viewmore in 0.1 second and the rest at 1.5 seconds.

So perhaps we can compromise by only rendering 'view more' early if it loses a race against the clock? This would match RAIL expectations and improve the user experience for both scenarios.

Majr added a comment.Mar 4 2016, 1:35 AM

As far as complaints go, I'm talking about power users. They're the sort of people that will use arrow keys for navigating suggestions, so they don't have to move their hand to the mouse, and will already use the up arrow to loop back around to the bottom of the list.

I agree (and suggested) that having the "view more" work on a timeout instead of instantly reduces (but doesn't eliminate) the issues with it moving as someone goes to click on it, while still avoiding waiting too long, however I don't see how showing the "view more" almost instantly while you're typing causes the suggestions to seem like they're taking longer to load.

Even without the supposed perceived performance issues, the timeout idea still seems like the best choice for solving this task (and ideas for moving the "view more" box somewhere else can be a separate task), while reducing clicking on the wrong thing, the question of course is how long the timeout should be? I suppose it should be slightly longer than the average response time for search results, 1 second maybe?

Majr added a comment.Mar 4 2016, 5:14 AM

Gerritbot on holiday? https://gerrit.wikimedia.org/r/#/c/273436/

I've changed it to use a timeout, set to 1 second.

Isarra edited projects, added MediaWiki-Interface; removed Vector.Apr 7 2016, 1:45 AM