1

We have an app that autosuggests various possible options based on a database query. For example if a user types 'Steve', it will find all Steves and allow them to choose the correct one. It looks somewhat similar to this: https://jqueryui.com/resources/demos/autocomplete/combobox.html

How long after the user releases the last key should we wait before the autosuggest appears?

We want to take the following things into account:

  • The cost of a database query
  • The speed of fast typer - we don't want them to have to wait a long time.
  • The speed of slow typer - we don't want to fire a query off for every letter if the user is still typing.
Improve this question

2 Answers 2

Reset to default
1

It's quite common to wait for the second or third keystroke, then add a pause based on the Keystroke Level Model - http://en.wikipedia.org/wiki/Keystroke-level_model

Although if you have a very robust backend and matching system, you could just set your delay to 0 as Google does on some of its auto suggest processes.

You might also be able to do some javascript to measure the keystroke speed of the first 3 characters, then determine the delay based on that.

EDIT - If your matching is based around a "starts with" type query rather than a full "contains" query, you could set to zero and refine the results in browser based on the initial query as @Blam mentions below.

Improve this answer
0
0

As pure UX answer the cost of autocomplete should not be a factor but understand the reality of need to deliver the UX.

As a user I would want zero delay. As I key in fast or slow the possibilities get refined instantly.

This is a UX site but as a developer I would say don't make every key stroke a database query. Once you retrieve everything name that starts with s then you also have every name that starts with st. As a web site it would mean hold that information in a session or a shared cache. Or even hold that information in the client but that get a bit harder with a web client.

Improve this answer
5
  • Down vote care to comment?
    – paparazzo
    Commented Dec 3, 2014 at 19:35
  • 1
    Not sure about the downvote, but I appreciate you answer. Is an immediate response really best though? I feel a rapidly changing autosuggest would take away from my experience as it might be a bit confusing at first.
    – Prinsig
    Commented Dec 3, 2014 at 19:55
  • Why would a delay be better? Either way the auto suggest needs to be clearly distinguishable. The common presentation is gray. If I am typing in ste and stop to see the suggestions I don't want to wait. And suggestions in no way encumbers me from typing in steve.
    – paparazzo
    Commented Dec 3, 2014 at 20:02
  • I do this but in WPF where I can download to a smart client and the users love it. As a collection in memory can really provide immediate response. In my case a tab key does select so they can type ste tab and be done. If they tab again it goes to the next e.g. steve thomas to steve thompson. I use enter for commit.
    – paparazzo
    Commented Dec 3, 2014 at 20:07
  • I believe that the only reason to introduce any sort of latency in autocompletes is to avoid hammering your database to death. If that's not a concern (caching, fast db, local data, etc) then I think Blam's suggestion makes the most sense. The whole point of an autocomplete is to make it faster for a user to enter something. If they're waiting 250ms for the list to update after every keystroke you're artificially slowing them down.
    – John S
    Commented Dec 3, 2014 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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