Amount of Time To Determine a User Has Stopped Typing

Question

I have a filter form for a list. One of the fields is a text search field. When a user types in the field, I wait until the user has stopped typing for a half second (500 milliseconds), and then perform the search. I arbitrarily chose this value because it felt natural when I used it. I was watching my boss use the search the other day and noticed that the search was being triggered while he was still typing. A delay of one full second (1000 milliseconds) seems too long to me, but rather than pick an arbitrary value, I was wondering if there was some sort of consensus for the length of the delay.

---

Other Details

• It's a web form/list
• select fields on the form call the search instantly
• I use jQuery in conjuction with the bindWithDelay plugin and listen for the keyup event
• The search is with a jQuery ajax() call, using json

Answer 1

That really depends on the users and on what they are typing. Typing on a physical keyboard is significantly faster than on a touch device.

So the question then is what the average WPM typing speed of the average user on your system is, and then work backwards from there.

Let's say that it is 25 WPM. Typically a word is considered 5 characters long, so their rate is 120 characters per minute, or about 0.5 seconds (60 / 120). If assume that the time between keystrokes isn't even (which it isn't) and account for about a 2x variation in that (which is fairly accurate), you get to a figure of 1.0 second.

For users who type faster, say at 75 WPM, the gap that would indicate the end of typing would be only 0.3 seconds.

Answer 2

I ran into a similar issue with an auto-complete we were working on some time back where I was typing and I never saw the results until I was done typing but another colleague saw it while he was typing because his pauses between typing caused the backend calls to get triggered.

There is really no silver-bullet here but I figure a 1000 milliseconds delay is better than a 500 milliseconds delay for the following reasons.

1. You don't want to assume that your user has stopped so fire the call and for all you know they may start typing again after those 500ms and then your first search may become invalid leading you to fire another search once the 500ms time has lapsed. This might also hold true for a 1000ms call but the gap might afford you more time to wait for user input before firing a call. A second goes by so quickly that the user might not even notice it.
2. Having only a time value without some kind of delimiter on the length of the key entered might raise unnecessary calls and also doesn't help a slow typer when the searches start running in the back-end.

In the end I think that a 1000ms option saves you unnecessary processing time and its not really a lot of time to have to wait for a search to fire provided some feedback is presented that results are being returned. If you type in a single character and wait and it starts searching then its not really useful so having a limit on the number of chars along with a timer would certainly boost you chances of finding common-ground.

I generally like to think that the non-developers on a project or the people we use for testing (even if they type slow) are a better general reflection of how the system is going to be used. I hope that helps.

Answer 3

Rather than a consensus on a static delay, maybe you could look into something a bit more adaptive.

For example, if it is rare that a search will be for anything shorter than a few words or a few characters, try to determine the user's words-per-minute rate, or characters-per-second. Once you have these you can trigger a search when there is a significant drop.

Answer 4

Why do you need the delay? As long as the search text field is constantly available, you could start the search after the first key is pressed, and refine it on each successive keystroke. Take Google search for example: After the first keystroke, the search starts:

No results yet...

...Finally the results appear: