打字时的平均按键间时间
我试图用谷歌搜索这个问题的答案，但也许没有广泛可用的研究，或者也许我没有使用正确的术语。
基本上，我想了解打字时按键之间的平均时间。我想知道这一点的原因是我正在研究将在下拉列表中使用的模糊搜索。我们可以采取一些措施来提高结果的准确性，但它们会导致速度变慢。但是，如果这样的速度仍然低于按键间时间的合理阈值，则实施更改是有意义的。
任何帮助将不胜感激。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这些在字符对之间会有所不同，并且也是打字速度的函数。例如，一个人每分钟键入 60 WPM（其中单词平均为 5 个字符），则每分钟键入 360 个字符（包括单词之间的空格，但不包括标点符号）。这大约是每秒 6 个字符，这使得我们的平均字符间时间为 167 毫秒。然而，这只是一个平均值，不同的字符组合它会更高或更低。
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.
解决此问题的另一种方法是考虑 100 毫秒阈值，该阈值（大致）是用户主动注意到延迟之前可以经过的时间量。显然，上下文和用户的期望一样重要，但在人们认为是瞬时的打字上下文中，我猜这可能是您想要的数字。
这可能还取决于您是在谈论中断打字还是在谈论由于打字而更新下拉列表之间的延迟。前者意味着您的目标需要更加积极，因为用户希望输入时没有延迟，但对于搜索结果，您可能会遇到稍长的延迟。
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.
一个大胆的猜测是，您在界面锁定方面遇到了麻烦，因为搜索需要一段时间。您应该在后台在单独的线程上进行搜索，而不是尝试猜测用户停止输入时的延迟。搜索完成后，您检查用户是否更改了搜索框中的值。如果该值已更改，则取决于您的应用程序是否与显示部分搜索结果相关或您是否要等待新的搜索。
应配置不同搜索尝试之间的间隔，以便为搜索服务或本地计算机（如果搜索是本地的）提供合理的最大负载。
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.
我曾在搜索引擎中工作过一次，为了不在每次击键时都获取数据，我迭代了触发获取器之前等待的时间（这听起来更简单），直到我在 250 毫秒内等待以方便用户使用。如果击键之间的平均时间为 167 毫秒，那么坐在平均击键分布图的上谷附近听起来可以 250 毫秒。但根据具体用途和人群，使用 90% 左右的百分位数就足够了。
搜索引擎的基本理论至少是：如果时间太短，您可能会最终获取每次击键并使搜索饱和；如果时间太长，用户将感知到数据的错误延迟。
最好的办法就是坐在某个地方，这样你就不会惩罚那些打字速度慢的老人，而是给那些不会写出完整单词的懒人提供早期结果。
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.