ユーザーが入力を停止したかどうかを判断するための時間
リスト用のフィルターフォームがあります。フィールドの1つはテキスト検索フィールドです。ユーザーがフィールドに入力するとき、ユーザーが0.5秒（500ミリ秒）入力を停止するまで待ってから、検索を実行します。この値は、使用すると自然に感じられるため、任意に選択しました。先日、上司が検索を使用しているところを見ていましたが、彼がまだ入力しているときに検索がトリガーされていることに気づきました。 1秒（1000ミリ秒）の遅延は私には長すぎるように見えますが、任意の値を選択するのではなく、遅延の長さに何らかのコンセンサスがあるのではないかと思っていました。
その他の詳細
- それはウェブフォーム/リストです
- フォームの
selectフィールドは、検索を即座に呼び出します - bindWithDelay プラグインとjQueryを組み合わせて使用し、
keyupイベントをリッスンします - 検索はjsonを使用したjQuery ajax（）呼び出しで行われます
それは本当にユーザーとユーザーが入力している内容によって異なります。物理キーボードでの入力は、タッチデバイスよりもはるかに高速です。
したがって、質問は、システム上の平均的なユーザーの平均WPMタイピング速度がどのくらいかであり、そこから逆方向に作業します。
それが25 WPMであるとしましょう。通常、Wordは5文字と見なされるため、その速度は1分あたり120文字、つまり約0.5秒（60/120）です。キーストローク間の時間が均一ではない（そうではない）と仮定し、その約2倍の変動（かなり正確です）を考慮すると、1.0秒の数値になります。
75 WPMでより速く入力するユーザーの場合、入力の終わりを示すギャップはわずか0.3秒です。
オートコンプリートで同様の問題に遭遇しました。タイピングしているときにしばらく作業していましたが、タイピングが完了するまで結果を見ることはありませんでしたが、タイピングの間に一時停止するとバックエンドが発生したため、タイピング中に別の同僚がそれを見ましたトリガーされる呼び出し。
ここには実際には銀の弾丸はありませんが、次の理由により、1000ミリ秒の遅延は500ミリ秒の遅延よりも優れていると思います。
- ユーザーが停止したと想定したくないので、通話を開始します。すべてのユーザーが500ミリ秒後に再び入力を開始し、500ミリ秒が経過すると最初の検索が無効になり、別の検索を開始する可能性があります。これは、1000ミリ秒の呼び出しにも当てはまる可能性がありますが、ギャップがあるため、呼び出しを開始する前にユーザー入力を待つ時間を増やすことができます。 1秒は非常に速く経過するため、ユーザーはそれに気付くことさえありません。
- 入力されたキーの長さになんらかのデリミタなしで時間値のみを指定すると、不要な呼び出しが発生する可能性があり、バックエンドで検索が開始されたときにタイパーの速度低下に役立ちません。
結局のところ、1000ミリ秒のオプションを使用すると、不要な処理時間を節約でき、結果が返されているというフィードバックが表示されれば、検索が実行されるまで待つ必要はそれほど多くありません。単一の文字を入力して待って検索を開始した場合、それはあまり役に立ちません。文字数の制限とタイマーを併用すると、共通点が見つかる可能性が高まります。
私は一般的に、プロジェクトの非開発者またはテストに使用する人々（タイプが遅い場合でも）は、システムの使用方法のより一般的な反映であると考えたいと思います。お役に立てば幸いです。
静的遅延に関するコンセンサスではなく、もう少し適応性の高いものを検討することもできます。
たとえば、数語または数文字よりも短いものを検索することがまれである場合は、ユーザーの1分あたりの単語数または1秒あたりの文字数を特定してみてください。これらを取得したら、大幅な減少があったときに検索をトリガーできます。
なぜ遅延が必要なのですか？検索テキストフィールドが常に利用可能である限り、最初のキーが押された後に検索を開始し、連続する各キーストロークで検索を絞り込むことができます。たとえば、Google検索を見てみましょう。 
最初のキーストロークの後、検索が開始されます。 
まだ結果がありません... 
...最後に結果が表示されます： 