Average Inter-Keypress time when typing

Question

I have tried to google for answers to this, but perhaps there isn't widely available research or perhaps I'm not using the right terms.

Basically, I would like to have some idea as to the average time it takes between key presses when typing. The reason I want to know this is I'm working on a fuzzy search that would be used in a drop down. There are some things we can do to improve accuracy in our results but they would result in slower speed. However, if such a speed would still be below a reasonable threshold for inter-keypress times, it makes sense to implement the change.

Any help would be appreciated.

Emigrate

I got a different keyboard recently and discovered that nearly all my typing mistakes were a result of accidentally hitting an adjacent key immediately after the intended key. This got me thinking - what if I could create a program to monitor for that and if a second key is pressed quicker than a set time, don't allow that key to be typed? I made the program and it needs to be set to 35ms for me (I type about 75 WPM) so in my case, I know the absolute shortest time between any two key presses is about 40ms (because at that, some keys weren't registering, but at 35ms they all do). – Catchy

Answer 1

The other way of approaching this would be to consider the 100ms threshold which is (roughly) the amount of time that can elapse before the user actively notices a delay. Clearly the context is important as are the users expectations but in the context of typing which people perceive to be instantaneous I would guess that's probably the sort of number you want to be going for.

It probably also depends whether you're talking about interrupting the typing or whether you're talking about the delay between updating the drop down as a result of typing. The former will mean your targets need to be more aggressive as users will expect no delay in typing, but for the search results you might get away with a slightly longer delay.

Unintentional

I don't suppose there's any chance you have any kind of research/documentation behind the 100ms comment? It would be helpful for convincing my architect to accept a slightly slower speed (right now it's about 25-30ms per term in the search, so there's definitely leeway). – Emigrate

I got the number originally from Jakob Nielsen's research. Have a look at useit.com/papers/responsetime.html – Unintentional

Thank you so much. That is exactly the kind of thing I was hoping to find. – Emigrate

Answer 2

These would vary between character pairs and would also be a function of the typing speed. For example, a person that types 60 WPM (where words are an average of five chars), is typing 360 characters per minute (which includes spaces between words, but excludes punctuation). This is about six characters per seconds which gives us an average inter-character time of 167 ms. However, this is just an average, it will be higher or lower for different character combinations.

Equatorial

Answer 3

A wild guess is that you have trouble with the interface lock up because the search takes a while. Instead of trying to guess a delay when the user has stopped typing you should do a search in the background on a separate thread. When the search is completed you check if the user has changed the value in the search box or not. If the value has changed it depends in your application if it is relevant to present the partial search result or if you want to wait for a new search.

The interval between different search attempts should be configured to give a reasonable max load on your search service or to the local computer if the search is local.

Poynter

Answer 4

I worked in a search engine once and in order to not fetch data every keystroke I iterate the amount of time to wait before trigger the fetcher (this sounds simpler that it was) until I sit in 250 milliseconds to be user friendly. If the average time between keystrokes is 167 ms, it sounds ok 250 to sit near the upper valley of the average keystroke distribution graphic. But depending on the specific usage and the population, using an 90 percentile or so should be enough.

Basic theory for search engines at least is: to short, you might end fetching every keystroke and saturating searches, to long and the user will perceive a false delay for data.

The sweet spot is sitting somewhere so you don't punish old people that type slow, but give early results to lazy people that won't write the full word.

Scatter