ユーザーはどの時点でビジースピナーへの信頼を失いますか？
最初のシナリオは、ユーザーがボタンを押した後、実行に約2〜5秒かかるアクションです。処理が完了するまで、ビジースピナーがボタンに表示されます。
アクションが完了すると、フィードバックがユーザーに表示されます。
2番目のシナリオは、完了するまでに数分かかるアクションです。このシナリオでは、ボタンにビジースピナーを表示するだけでは適切ではないと思います。何か進歩していると、ユーザーは疑問を持ち始めると思います。代わりに、ダイアログが表示されます：
テキストとともにダイアログを表示することで、ユーザーはアクションisが実行されていることを確信できると思います。
私の質問は、単純なビジースピナーにはどのくらいの長すぎるのですか？およそどのくらいの時間枠で、アクションが大まかにかかるかを示すダイアログを導入し始めるべきですか？
Jakob Nielsenが 応答時間-3つの重要な制限 という記事を書きました。
応答時間に関する基本的なアドバイスは、30年前とほぼ同じです[Miller 1968;カード他1991]。彼は1993年にこれを書いた：
- 0.1秒は、システムが瞬時に反応しているとユーザーに感じさせるための制限とほぼ同じです、つまり、結果を表示する以外に特別なフィードバックは必要ありません。
- 1.0秒は、ユーザーの思考の流れがとどまる限界に近いユーザーは遅延に気づくでしょうが、中断されません。通常、0.1秒を超え1.0秒未満の遅延の間は特別なフィードバックは必要ありませんが、ユーザーはデータを直接操作する感覚を失います。
- 10秒は、ユーザーの注意を対話。より長い遅延の場合、ユーザーはコンピューターが完了するのを待っている間に他のタスクを実行する必要があるため、コンピューターがいつ完了するかを示すフィードバックをユーザーに提供する必要があります。遅延中のフィードバックは、応答時間が非常に変動する可能性が高い場合に特に重要です。ユーザーは何を期待するかわからなくなるためです。
2014年に彼はこれで彼のガイダンスを更新しました：
- 0.1秒：ユーザーがのオブジェクトを直接操作していると感じるユーザーの制限UI。たとえば、これは、ユーザーがテーブルの列を選択してから、その列が強調表示されるか、選択されていることをフィードバックするまでの制限です。理想的には、これは列をソートするための応答時間でもあります—その場合、ユーザーはテーブルをソートしていると感じます。 （彼らがコンピュータにソートを行うように命令していると感じているのとは対照的に。）
- 1秒：ユーザーが自由にコマンドをナビゲートしていると感じているユーザーへの制限コマンドコンピュータを不当に待たせる必要がないスペース。 0.2〜1.0秒の遅延は、ユーザーが遅延に気づき、コマンドがユーザーのアクションの直接の影響であるのではなく、コンピューターがコマンドで「機能している」と感じることを意味します。例：選択した列に従ってテーブルを並べ替えることが0.1秒でできない場合、それは確かに1秒で行う必要があります。そうしないと、ユーザーはUIが遅く感じられ、実行中の「フロー」の感覚を失います。彼らの仕事。 1秒を超える遅延の場合、コンピューターが問題に取り組んでいることをユーザーに示します。たとえば、カーソルの形状を変更するようにします。
- 10秒：タスクに注意を向けているユーザーの制限。 10秒より遅いものには、完了パーセントインジケーターと、ユーザーが操作を中断するための明確な標識付きの方法が必要です。ユーザーが10秒以上の遅延後にUIに戻ったときに、ユーザーの方向を変える必要があると想定します。 10秒を超える遅延は、タスクの切り替え時など、ユーザーの作業の自然な中断中にのみ許容されます。
あなたと私が通りで互いに話していると想像してください。私に時間があるかどうか尋ねてきましたが、ためらうことなく時計を見て話します。二度と考えないでください。それから、きちんとしたコーヒーショップへの道順を教えてもらえるかどうかを尋ねます。いくつかのオプションが発生する可能性があります：
すぐに一連の指示を出し始めます
私は何かを考えているようです-現在の場所を考慮に入れて最高のコーヒーショップを検討しているのかもしれません。あるいは、徒歩の最適な方向を考え出そうとしているのかもしれません。
私は知らないと言いますが、私は次に知っている誰かに会っています、そして私はあなたに数分で答えをテキストで送ることができます。
私はあなたに何も聞いていないかのように、実際には何もせずに立っています。
オプション1または2を期待している可能性があります。オプション2を示した場合、これには少し時間がかかる可能性があり、少し待つ準備ができていることを理解していますが、最初に検討することを知らせれば、間違いなく役立ちます。 1つを選んで指示を出す前に、本当に良いコーヒーショップはほとんどありません。
オプション3を使用すると、生活を続けて、すぐに通知を受け取ることができます。すぐに答えは得られませんが、役に立たないだけでなく、待つ必要がないことに感謝しています。
オプション4は完全に当惑させます。答えを検討しているという手がかりを与えずに私がそこに立っていると、「どのコーヒーショップでもいい」または「この近くにコーヒーショップがない場合は問題ありません」などのメッセージが表示されます。または「忘れてください、私はたださまようだけです！」。
それはコンピューターでも同じです-それはまだあなたとコンピューターの間の会話の一部です。 10分の1秒以内に複雑なものに対する回答を期待できない場合があります。リクエストが有効に検討されているという手がかりを期待しています。 typeの応答が1秒程度で示され、anyフィードバック数秒以内。そして、合計待機時間が数秒より長い場合は、何が考慮されているかを知りたいと思います-私はいくつかの地元のコーヒーショップを考えていますか、それとも私はロンドンからシアトルの素晴らしい小さなインディーズコーヒーアウトレットへの道順を計算しています。
Scott Klemmer's 経験則は次のとおりです。
1秒未満の回答：フィードバックなし
1〜5秒の回答：BusySpinner
5秒を超える回答：進行状況バー
10秒は長い時間です。ユーザーにフィードバックを提供する必要がありますbefore彼/彼女は自然にあなたのソフトウェアがしていることに興味を失い、あなたのソフトウェアが彼/彼女の時間を浪費していることに苛立ちます。
これによると、認知心理学研究に基づいたNNGroupからの 記事 ：
- 1秒後、ユーザーは現在のプロセスについての思考の流れを失い始める可能性があります。
- 10秒後ユーザーはおそらく他のタスクに注意を向けます
ユーザーが注意を他の何かに切り替える危険を冒したくないので、10秒前にダイアログを表示する必要があります。また、調査は25年以上前のものであるため、コンピューターの処理速度が大幅に向上し、ユーザーはすべての読み込みが速くなることを期待しています。
そのため、遅延情報を含むダイアログを表示する必要があるしきい値を約3秒にすることをお勧めします。
基本的に、ロード中にユーザーに提供する情報が多いほど、プロセスを中止しない可能性が高くなります。表示してみてください：
- プログレスバーを使う
- 読み込みに時間がかかる理由を説明してください
- 読み込みのおおよその時間を表示
10秒後、「これはうまくいかない」と思い始め、クレジットカードが処理されない、または処理されない、または2度処理されるのではないかと心配になります。
10〜15秒後にメッセージを「まだロード中です。心配する必要はありません」またはその他の積極的な安心メッセージに変更することをお勧めします。
ほんの一例は、添付ファイルを事前アップロードせずにGmailでメールを送信することです。メッセージが「送信中」から「まだ機能しています」に変わります。
プロセスがまだ実行中であることを確認したり、ユーザーにエラーを報告したりするには、サーバーから何らかの応答が必要であることに注意してください。
申し訳ありませんが、古い研究を引用しています。 Googleはこれを更新しました。
125msユーザーは、クリック後にロードアイコンが表示されるなど、何らかの応答を期待しています。
250msのユーザーは、アクションが発生していることに気づき始めます。
500msは、ユーザーが応答時に更新されることを期待しています。
1sユーザーはコンテンツがロードされることを期待しています。
10代はあきらめます。
https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/rail?hl=ja
ここに提出されたすべての優れた回答とは別に、私は付け加えたいと思います。低帯域幅インターネット接続でのユーザーの期待（はい、存在します！）は、高速光ファイバー接続でのユーザーの期待とはまったく異なります。 。
タスク自体が変化するため、または異なる速度のプロセッサで実行される可能性があるため、タスクがかかる可能性のある時間を（事前に）知らない場合、プログラミングの課題が発生します。理想的には、コードをタスクサイズとハードウェア/ OSの制限の両方から独立させ、すべての状況またはほぼすべての状況で一貫して実行したいと考えています。
プログレスバー（またはスピナー）を表示すると、画面上でちらつくだけですぐに消える可能性があります。
これに対する（理想的には実装されていない）解決策は、ユーザーがある程度の時間待機することを単純に決定することですタスクがどれだけ速く完了しても ... 1秒+タスク時間。スピナー/プログレスバーは、少なくともしばらくの間表示されたままです。
少し良い解決策は、所要時間が既に1秒を超えているの場合にのみ固定遅延を追加して、スピナーまたはプログレスバーを表示することです。これにより、遅延が追加された場合、ユーザーが待機する必要がある時間に比べて、遅延は比例してはるかに少なくなります。