Often a search filter is not hitting a simple local database, but rather a remote server thousands of kilometres away. In addition, if the dataset is of a non-trivial size, then processing the query and returning the results to the client also has a delay. Maybe a search component may also have a small forced delay to increase perceived value or complexity in producing the results. There may also be a debounce in there so we're not hammering the backend with every key stroke.
Let's say I'm looking for Foo Bar Car Rental. I type in the query:
Search: foo Searching...
A spinner or some kind of activity UX is a great way of indicating the initial round-trip, so the client can signal the user that results are on their way. The results come back:
Search: foo
Results (5):
- Football results
- Foo alpha ipsum
- Foo bad
- Foo Bar Car Rental
- Foo Bar Star
A glance of the first and second results in the list shows that I'm not quite there, so type in in 'bar' to my search query to narrow it down a bit. But hang on! The fourth result is what I'm looking for! I start pressing the down arrow, and have pressed it twice already, and will press it twice more to hit my desired result:
Search: foo bar Searching...
Results (5):
- Football results
- Foo alpha ipsum
- Foo bad
- Foo Bar Car Rental
- Foo Bar Star
I need to press the down arrow twice more, and then press return, but suddenly all of the delays of the debounce, server filtering, and server response have finally occurred. In my experience, I will be quickly pressing those buttons before I realise the change in search results.
Here's what usually happens in this situation. The user selection completely resets with the new results. This means that no item is highlighted. I may be pressing the keys faster than I realise the change in search results, and I will wind up being shuttled off to the wrong place (from before, Down x2, Return x1):
Search: foo bar
Results (2):
- Foo Bar Car Rental
- Foo Bar Star
If I have begun pressing the down arrow or moved the mouse of a particular result, then surely this should be a signal to the search component that I have found or am finding the desired. If the search results list is particularly long (the amazon.com search return is currently 10 results, for example), then I may be in the process of arrowing down to my intended result when the search component resets my progress with a fresh list.
This is a particular problem when bandwidth is constrained and latency is increased, as the round-trip between client and server is prolonged and the user has more time to realise and signal that a desired result has been found. You can simulate the impact of this using browser dev tools, such as the GPRS setting in Chrome, for example.
I have seen this issue so many times in search filtering, but perhaps it means I should just be a little more patient? For me, if the user has signalled that they have found something relevant by pressing an arrow or moving their mouse through search terms, the user is provided with a short debounce before moving on to the new list.
Basically, the old results should remain in place until the user has shown a disinterest in the old results.
The bit what I am not sure about is the experience of signalling new results are available... perhaps by a notification in the search bar like below? There could be some kind of progress bar indication that resets each time the user presses the down button, for example.
What do you think?
Search: foo bar New Results!
Results (5):
- Football results
- Foo alpha ipsum
- Foo bad
- Foo Bar Car Rental
- Foo Bar Star
Interestingly, when using the stackoverflow tag searching when going to post this question, it has a variation of the proposed UX which is partially welcomed but also partially annoying. If I find a search result while the round-trip is occurring, the updated search results are completely voided. If I determine the result is not what I was looking for, I need to arrow up to the search input, press backspace, and then type the character I removed to continue with my search.