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

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

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.

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.

In T42855#2069181, @Majr wrote:

In T42855#2066470, @Krinkle wrote:

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.

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?

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

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

After much time has passed i think this feature sounds risky. While we can render the containing link, it will jump down as soon as results pour in and having it at the top is terrible UI.

To me the real problem here is the performance. If search is really taking that long to show results, that's the problem that should be focused on here, not a ui workaround.