你应该多长时间去除文本输入

Question

让我们说我们有一个简单的例子如下.

<input id="filter" type="text" />
<script>

    function reload() {
     // get data via ajax
    }

    $('#filter').change($.debounce(250,reload));
</script>

我们正在做的是引入一个小延迟,以便reload在用户在输入中键入文本时减少调用次数.

现在,我意识到这将取决于具体情况,但考虑到平均(或可能应该是最低公分母)打字/交互速度,是否应该知道去抖延迟应该有多长.我通常只是玩弄它的值,直到它"感觉"正确,但我可能不代表一个典型的用户.有没有人对此做过任何研究？

Answer 1

正如你所暗示的,答案取决于许多因素 - 并非所有因素都是主观的.

一般来说,使用去抖操作的原因可归结为具有以下两个目的之一:

1. 降低提供动态交互元素的成本(成本可以是计算,IO,网络或延迟,可能由客户端或服务器决定).
2. 减少视觉"噪音",以避免用户在忙碌时分页更新.

反应时间

要记住的一个重要数字是250毫秒 - 这代表人类的(大致)中位反应时间,通常是一个很好的上限,你应该在其中完成任何用户界面更新,以保持你的网站的响应.您可以在此处查看有关人类反应时间的更多信息.

在前一种情况下,准确的去抖间隔将取决于操作成本对双方(客户端和服务器)的影响.如果您的AJAX呼叫的端到端响应时间为100毫秒,那么将去抖动设置为150毫秒以保持在250毫秒的响应阈值内可能是有意义的.

另一方面,如果您的通话通常需要4000毫秒才能运行,您最好在实际通话中设置较长的去抖动,而是使用第一层去抖动来显示加载指示(假设您的加载指示不会模糊你的文字输入).

$('#filter').change($.debounce(250, show_loading)); $('#filter').change($.debounce(2000, reload));

后端容量

记住这些请求在后端的性能成本也很重要.在这种情况下,平均打字速度(每分钟约44个单词,或大约每分钟200个字符)和用户基本大小和后端容量的知识的组合可以让您选择一个可以管理后端负载的去抖动值.

例如:如果您有一个后端能够处理每秒10个请求并且峰值活跃用户群为30(使用此服务),您应该选择您的去抖时间,以避免每秒超过10个请求(理想情况下具有错误).在这种情况下,我们每秒每个用户处理一个输入所需的容量为33.3%,因此理想情况下,我们每3秒钟最多为每个用户提供一个请求,从而为我们提供3000ms去抖期.

前端表现

要记住的最后一个方面是客户端的处理成本.根据您移动的数据量和UI更新的复杂程度,这可能是微不足道或重要的.您要尝试并确保的一件事是您的用户界面仍然响应用户输入.这并不一定意味着它总是需要能够做出反应,但是当用户与它进行交互时,它应该对它们做出快速反应(60FPS通常是这里的目标).

在这种情况下,您的目标应该是以一定的速率进行去抖动,以防止用户界面在用户与其进行交互时变得迟钝或无响应.同样,统计数据是获取此数字的好方法,但请记住,不同类型的输入需要不同的时间来完成.

例如,抄写短词的句子通常比输入单个长而复杂的词快得多.同样,如果用户必须考虑他们输入的内容,他们往往会输入更慢的内容.这同样适用于使用特殊字符或标点符号.

主观答案

在实践中,我使用的是去抖时间,其范围从100ms非常快速检索的数据到对性能的影响非常小,5000ms对于成本更高的事物.

在后一种情况下,将短的,低成本的去抖期配对以向用户呈现反馈并且实际计算工作的较长时间倾向于在用户体验和浪费的操作的性能成本之间取得良好的平衡.

在选择这些值时,我要记住的一个值得注意的事情是,作为每天使用键盘工作的人,我的输入速度可能比我的大部分用户都快.这可能意味着对我来说感觉平稳和自然的事物对于输入速度较慢的人来说是不和谐的,所以做一些用户测试或(更好)收集指标并使用它们来调整界面是个好主意.

Answer 2

我想提供有关搜索文本输入的简洁答案。

我通常做 300ms，考虑到节省硬件资源和提供足够好的用户体验，这感觉很合适。

--

一个有趣的想法...

让我们举一个大师的例子：Google。

如果您注意到（您必须是一个快速打字员），Google 实际上对于前几个字符（我认为是 2 个）的去抖时间非常少或没有，但之后它会增加去抖时间。显然，他们的主要目标是给人一种即时的感觉，并平衡他们的用户界面与用例。我不知道他们做了哪些数据或研究，但他们已经完成了，并且当搜索输入是网站的主要功能时，他们是一个很好的例子。

因此，我想说这是一种出色的用户体验，尽管会增加额外的复杂性和编程时间。谷歌需要它。也许，不太常用的搜索栏不会产生额外的复杂性。