Display results from multiple sources

Question

I'm working on a search which aggregates videos from multiple sources. Imagine that my search is searching through Metacoffe and Youtube. In my case Youtube have more relevant results but they need longer to arrive from search.

Currently my search shows loading bar until it gets results from both YT and MC. This may take up to 10 seconds (very bad from UX perspective), because of YT slow loading (MC is returning results near-instant). When results arrive they get mixed (with more YT results on top)

I want to display MC results as they arrive and later when YT results are ready they should be added into list - not to the bottom - but in correct place.

What is the proper way to handle this and what would be the best from UX perspective? Isn't a bit weird if list is modified once its filled? What if user wants to click and youtube results arrived?

Answer 1

As stated in Seow's book on time engineering, working on time-consuming tasks there are some issues:

1. How to make the system work faster (technology task).
2. How to make the system be perceived by users as faster one (psychological task).
3. How to make users become more tolerant to the systems delay (psychological task).

On tech side you can use caching tools, create own database for search and so on.

On psychological side you have some tricks. For example, you can do 10 sec of searching useful for user, look at my sketch. The idea is to display immediately some results from fast search. The more relevant search is continued while user learns fast results. So the 10 secs are virtually divided and the user engaged from first seconds (perception way).

The next trick is fun. You can make waiting for results more fun for users by displaying some nice animation (toleration way).

Answer 2

Show what results you have initially, but indicate that there are more results coming.

When you have more results, use some mechanism to indicate 'Adding more results in 3...2...1'.

You could also indicate what results are already fetched and which are coming so that the user knows what source of information is still being waited upon.

So for example, the following sequence:

Before any search results are found you show a list of sources.

If one source appears almost instantly then you show the results asap and dim the source in the waiting list. You don't want to delay showing the first results.

Now the user has something to do - ie look at the initial results.

Then when you have results ready or are preparing results in such a way that you know how long it will take then you start indicating via a progress meter that the results are being processed and about to be added.

This will allow the user to see that an update to the results is about to happen. They will learn after only one or two goes that the results will be updated when the progress meter reaches full circle...

Ideally it shouldn't take more than a couple of seconds otherwise user will get fed up with waiting. But also, it should take a minimum amount of time such that the user can see the results are about to be updated and for the last second they will not click/tap on an existing result, while they wait for the results to be updated.

Then the results will actually get updated, and although the results are sorted in order of relevance (?) the user can see which of the results are from the new source.

Finally, when all results have been fetched, the header changes to show more relevant information like number of results or whatever the user may be interested in.

Answer 3

I bet these results will be clickable, so as more results are added, some of the formerly displayed results will go lower. I hate it when e.g. I want to click a link/button on a site and then an ad loads at the top of the page and everything goes down, so - as a result - I click something completely different than intended, something that has just "slid under" mu cursor. In your case it is going to be similar, so, unfortunately, something that is good as an idea in this case will crush on the rocks of implementation limitations.

What is left, is either preventing users from clicking (by delaying the click ability of the results until the last result arrives) or splitting the results into two lists, e.g. displayed side by side. None of these is 100% good, but I think that these are better than your solution (or, to be precise: less bad). But as I said, this is only due to API returning results delay, the idea is, of course good.