up vote 22 down vote favorite
4

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
share|improve this question
  • You could start the search as soon as a key is pressed. Then you cancel it if another key has been pressed but the response was not returned yet, and you start a new search and on and on... – Toni Toni Chopper Apr 23 '13 at 15:48
  • 1
    Why do you need wo wait before the search is started? Due to lack of resources of a web server or similar? If you, for example, perform an inline search on a modern web browser (ctrl/command + f) the results are shown instantly. – Henrik Ekblom Apr 23 '13 at 15:54
  • 1
    Possible duplicate: Delay on keystroke when search as you type – Graham Herrli Apr 23 '13 at 17:08
  • @3nafish - Definitely a great related resource, but it doesn't directly answer my question. – Sonny Apr 23 '13 at 20:31
up vote 15 down vote accepted

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.

share|improve this answer
  • Math! I like it. Are there any stats on typing rate on a mobile device? Is there a keyup event? – Sonny Apr 23 '13 at 20:33
  • Just for testing purposes, I upped the delay to 1s, and I didn't find the delay annoying. – Sonny Apr 23 '13 at 20:36
up vote 5 down vote

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.

share|improve this answer
  • 2
    Wasting 1s before starting the search seems a bit exaggerated to me. The reason is that recommended response times for web applications are between 0.1s and 1s (for simple functions like an auto-complete, obviously a complex business function can take more). Less than 0.1s and the user wonders if anything happened at all, more than 1s and the flow of thought is disrupted. References here and here – Toni Toni Chopper Apr 23 '13 at 16:11
  • 1
    I suppose that also depends on the kind of feedback the system provides for when the actual list gets populated. But I do agree that sometimes we want instantaneous responses and that can cause a bit of confusion to the user typing as well. As long as their workflow isn't being interrupted then it should work. I think a second is acceptable waiting time but then again I know some people who type then think and that thinking can go from 0 - Infinity so providing a box and saying building... / searching ... just helps them know something is going on but not disturb their process too – Melroy Coelho Apr 24 '13 at 8:36
  • 1
    It is possible to allow the user to short circuit the wait by pressing a key, such as enter which would force the search operation. – jelaplan Apr 27 '16 at 20:06
up vote 3 down vote

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.

share|improve this answer
  • I would love to cater to the end-user's typing abilities, but that's a bit beyond the scope of my project at the moment. – Sonny Apr 23 '13 at 20:37
  • This is because if you search for every keystroke, you may have lots of network activity and some servers may throttle you. So better wait until user finished typing to avoid too much query and throttling. For for Google's case, it's obvious that they won't throttle their own activity. – litaoshen Jun 6 at 16:54
up vote 3 down vote

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 first keystroke, the search starts: After the first keystroke, the search starts: No results yet...

No results yet... Still no matches...

...Finally the results appear: enter image description here

share|improve this answer
  • 1
    I'm not actually implementing an auto-complete, but this is a good point. I would also love the server power that Google has at their fingertips! – Sonny Apr 23 '13 at 20:35

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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