2

We're developing a search functionality for our product (web). We are having some controversies how to handle search requests that can take up to one minute.

Current version: After clicking enter or after hitting the search button, a loading animation starts and the whole screen gets blocked. You're not able to click back again in the input field or anywhere else on the application except the user settings and the logout button until the request is handled.

That's how we used to do it with all filter/search functions, but they weren't as time consuming, so it never really bothered us.

I really don't like the blocking mechanism and that you can't send another search request in case you want to correct a typo or such.

What can we do to avoid making the user wait until the request is finished in case the search entry was wrong and needs to be changed?

Thanks for your help.

For visualization: Image of the website

  • Cancel search button? – Yates May 31 '18 at 9:36
  • I think that would not help much since, since the database is still busy with the request. The database select is the time consuming part. – samalisam May 31 '18 at 9:39
  • Well your question states your issue is the blocking mechanism because you might want to fix a typo or do a completely different request. Cancelling (or removing the block) would be your only solution. Otherwise you're looking at a completely new system. – Yates May 31 '18 at 9:53
  • The request is already wasted and useless when a user makes a typo or wants to do a different request entirely. Why make the user wait? – Yates May 31 '18 at 9:55
4

I really don't like the blocking mechanism and that you can't send another search request in case you want to correct a typo or such.

What can we do to avoid making the user wait until the request is finished in case the search entry was wrong and needs to be changed?

Let the user cancel the search. The request is wasted anyway, don't force the user to wait for something they don't need.

  • That's probably the only way we can take, yeah... thanks. – samalisam May 31 '18 at 10:12
  • @samalisam Even if you can't actually cancel the DB-lookup behind the original search, you should be able to ignore the results and let the user get on with a new (corrected) search. If "pending DB-searches" is likely to impact overall performance, you may want/have to limit the number of "abandoned" searches somehow. – TripeHound Jun 4 '18 at 14:23
0

There are a couple ways to solve this.

One way, as in another proposed answer, is to offer the user the option to cancel the query in progress.

But this is quite simplistic as there are multiple kinds of cases to consider, which might cause the user to be annoyed with a blocking UI, for example:

  • The user has made a mistake in their first query and needs to correct it (this is what you're concerned with initially)

  • The user realizes that the first query, while correct, may not return all the information that they'd like. They'd like to explore other query options. They don't know yet if they'll be able to issue a better query so they want the ability to draft a new query without cancelling the first or waiting for the first to finish

  • The user realizes that the first query, while correct, can be enhanced. They write a second query which tries to enhance it but unfortunately turns out to have a bad mistake in it, and they only realize it when the results of the second query come in. It would have been better if the user has had the option not to cancel the first query which might have produced useful results.

  • The user wants to issue multiple queries because a single query won't answer all their questions. They want to queue them up rather than have to wait for each one to finish before executing the next one.

A way to solve all these issues is to represent, instead of the results of a single query below your search form, results for a list of multiple queries.

Then, when a new query is executed, you add the new query in progress to the list at the bottom, with a progress indicator and a cancel button. The query form is not disabled, but if you start a second query, it adds the query to the list, above the first one that is still ongoing as well. The results area for your queries essentially becomes a master/detail view where you're able to see the list of previously executed and still ongoing queries, to inspect their results.

Finally a third alternative is to present a form of tabbed UI, where each tab is a different query form. Then within each tab there's a blocking modal indicating that the query is in progress, and a cancel button, but without preventing the user from opening a new tab to create a new request. Unfortunately this approach doesn't support very well the use case of applying a simple tweak to a complex query, since typically you'd want to start each new tab with a blank search form.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.