Comment 10 for bug 1238979

I’ve tested silo 20 and I have to say that these changes -mainly no clearing results when updating the model but rather as the results arrive- have a great positive impact on the overall experience when using scopes, so great work¡ : )

Also, the flickering/jumping of results has been palliated, or at least, with a good network connection, it *feels* faster.

We definitely want to avoid accidental activation by tapping results while these are updating, however, if there’s no way of “enforcing physical location when a new item arrives”, I would NOT recommend to make results “inactive”, even for a small amount of time. I don’t know what the most appropriated solution could be with the challenges of the current architecture, but I will think of/design some alternatives for this issue.

Some other things to consider:

- Missing icons problem (see screenshot attached) - Pawel pointed that this is not scope’s fault but rather the shell requesting icons via thumbnailer. I’ve experienced this in several occasions, is there any technical limitation that prevent us from solving this issue and optimising the experience?

- We also need to account for the empty dash use cases, where some queries provide no results at all (i.e.: try searching for ‘coffee’ in the News aggregator = 0 results and no feedback to the user). In order to design for this screen, I need to understand what’s happening behind the scenes. Isn’t there a single result for this query, really?

- Also, for accessibility reasons, instead of delivering results for a partial string we should wait for a natural pause when user is typing to trigger the query - currently the timer is set to 300ms. My recommendation would be to wait (at least) 700ms for user input before firing the query, provided some feedback is presented that results are being returned.