偽の遅延をネットワーク遅延に追加する場合
機能のあるアプリを考えてみましょう（たとえば、ボタン、またはReturnキーを押してテキストを送信する場合など）。
その結果、ネットワーク接続が確立され、接続が行われる間、少しの遅延が生じます。
遅延の間、ネットワーク接続が「発生している」ことを示すスピナー（または他のインジケーター）が表示されます...
...確かにその指標何かが「実際に起こった」ことを示します。
ここで、スピナーがネットワーク接続中に表示されることに注意してください。最近では、ほとんど瞬時に表示されることが多く、スピナーがほとんど表示されないか、表示されないこともあります。
考え：実際には、意図的にスピナーが表示されるための最小時間（たとえば、1/3秒）を作成します。つまり、接続がほぼ瞬時である場合でも、「偽の遅延」（おそらく1/3秒）を追加します。
このように、上で述べたように、ユーザーは何かが起こったことを確実に知っています。
良いアイデア？悪いアイデア？すでに使用されています？
- ここで質問を大幅に簡略化しました
私の2セント：
開発者の観点から、それは「明白な愚かさ」です、
しかし、ビジネス上の決定として、それは「天才！」です。
この架空の状況を検討してください：
あなたは占い師に行きます、
質問：「いつ死ぬのですか？」
それは即座に答えます：「2049年6月5日」
水晶玉なし、ハミングなし、何でも...
？どう思いますか？
意図的な遅延の例：
私が5 [秒]でさえ、偽の遅延を導入した1つの商用製品（私が書いたもの）を知っています。そして私は説明します：
私が書いた製品は、業界で広く使用されている有名な作図ソフトウェアのアドオンとして構築されたエンジニアリングツールとして提供されました。
しかし、それは広大であり、独自に「実行できる」機能が追加されました...
アドオンを開始すると、ソフトウェアの図が作成されず、製品に組み込まれていることがほとんどわかりませんでした。デザインは同じスキーマに従っており、読み込み時間はやや瞬時でした。
私たちのチームは、ユーザーが「親」ソフトウェアではなく、自分の作業に対する「私たちの貢献」がどこにあるかを確実に把握したいと考えていました。
それで...「スプラッシュスクリーン」を導入しました：
どちらがいいか、製品の名前、会社名、製品バージョンが含まれていました。
しかし...スプラッシュスクリーンが非常に短時間ポップしたため、スプラッシュスクリーンに遅延を導入しました。これは完全なプログレスバーであり、その後、ツールの使用に関するいくつかのヒントです。
実装に関する注意：
どちらの方法でも、最初に操作を実行し、その後（必要な場合のみ）遅延を導入することをお勧めします。逆も同様です。さらに、操作が失敗した場合は、遅延をあきらめて、ユーザーはすぐにわかります。
注2：
「操作が正常に完了しました！[OK]」を示すモーダルノートの代わり。
G-Mailの「メールが正常に送信されました！[X-却下]」のような警告フレームを使用できます。
しかし、もちろん、すべてのケースには独自の考慮事項があります。
これをプロダクションアプリで見ましたか？ （つまり、あなたは開発チームに参加していたと思います-必ずしもそれについて知っているとは限らないので、私はユーザーとして推測します！）
はい、私たちのほとんどはおそらく彼らも自分の賢い小さなローダーを見たいのでこれを行ったと思います...しかし次に進みます。ローダーは、何かが予想よりも長い場合にのみIMOを使用する必要があります。 300ミリ秒後、スピナーを表示する必要があるので、何の反応も確認されていないとします。
これは以前に文献で扱われましたか？ （何も見つかりませんでした。）既にかっこいい名前はありますか？
それをすることに誰かが正式な名前を付けたとは思いませんが、話されているのはユーザーが彼の行動のフィードバックを必要としているということです。これは、ユーザビリティのヒューリスティックです。ただし、システムの実際のステータスをユーザーに通知するためのより良い方法があります。あなたのビジネストランザクションの場合は、ボタンを削除して、「トランザクションが承認されました」というラベルを付けるだけです...または、おそらくそれを灰色にしてください...とにかく、ボタンをそのままにしないでください。私はかつて設定ページに関して同じ問題を抱えていました、ボタンをクリックしても何も起こりませんでした...なので、設定フォームで何かが変更されるとすぐにボタンを有効にし、ボタンが押された後、ボタンを再び無効にしました。
もちろん、最も基本的なフィードバックの形式は、さまざまなボタンの状態自体です。
- プレス：色を変更（例：青）
- リリース時：色を通常の色に戻します（例：グレー）
- ホバー時：中間の色に変更します（例：水色）
これに失敗すると、最も重要なのは、ここにいるみんなの意見は何ですか？
...私は実際には意見があまり好きではありませんが、これを行うだけでは悪い習慣のようです。ユーザーに実際にwaitを実行して他の場所に移動しないようにしたい場合は、このブロック手順が終了するまで、画面全体をオーバーレイし、そこに大きなスピナーを配置するのが最善です...ただし、トランザクションがほとんど瞬時（例：300ミリ秒未満）である場合は、それを行わないでください。ケースをサポートするよりも、煩わしく混乱します。
確かに良い考えです。
スピナーの全体的なアイデアは、ユーザーに知らせることです。バックグラウンドで何かが起こっているので、完了するまで待つ必要があります。
特にネットワーク接続の場合は、ネットワークの受信や速度を判断できず、変更される可能性があるため、スピナーが必要でした。ネットワークにもダウンタイムがあります。
ただし、スピナーの問題は、開発者は通常、1つを画面の中央のフォアグラウンドに配置し、画面自体のコンテンツをフェードインすることです。これは、ユーザーが途中で何かを編集する必要があり、ネットワークが遅い場合、逆効果になります。
これを行うには、スピナーをボタンの右側に配置し、ボタンよりも小さいサイズにして、ボタンがフェードしたまま回転し始めることで、データ転送の重複を防ぐことができます。
ネットワーク接続が成功し、データが転送されて+操作が実行されると、スピナーがアニメーションでチェックされます。
そうでなければ、十字架に。
このようにすると、操作が成功した時期と、重複が解消されなかった時期がわかりやすくなります。
私の意見では、ユーザーが何らかのアクションを実行するとすぐに、彼は応答を期待します。つまり、アクションが処理されたことを通知するアプリです。 3〜4秒間画像を読み込むと、ユーザーの入力が受信され、処理されたことをユーザーに明確に示します。ユーザー接続が非常に高速で、読み込み中のスピナーが0.5秒間画面に表示されてから消えた場合。それはちらつきを引き起こし、それは有益なものよりも気を散らす（または邪魔をする）でしょう。しかし同時に、アプリはユーザーにアクションが実行されたことを通知する必要があります。そのためには、アプリが視覚効果を示す必要があります。たとえば、スライド効果で次のフォームに移動するようなものです。もう1つは、ユーザーがアクションを実行した入力/ボタンであり、フェードアウトをスムーズにして、データがユーザーに表示されます。これらの視覚的表示は、ユーザーの目で識別できない0.2秒間の読み込みgifを単に表示/非表示にするよりも直感的である必要があります。
スピナー、ローディングバー、または他のそのようなデザインパターンは、システムがユーザーのアクションに必要なフィードバックを提供するのに十分な速度で応答できない場合に、ユーザーにフィードバックを提供するために使用されます。システムが十分に速く応答できる場合、必要なフィードバックが提供され、スピナーは必要ありません。この場合、単にユーザーのタスクの完了を遅延させるためだけに、ユーザーのタスクの完了を意図的に遅延させる理由はありません。
インジケーターの読み込みは好きではありません。ユーザーは何かが壊れていると思うかもしれません。
ただし、多くの場合、ユーザーに通知されれば、より忍耐強くなる可能性があります。
今回は、ユーザーに何かすることを読んでもらうことをお勧めします。ほとんどのサイトは、何かを強調するためにこの待ち時間を費やしました。
ユーザーにフィードバックを与えるための相互作用の証拠はたくさんあります。 PCのウィンドウを最小化するときなどと同じように...これらはすべて、実行されるアクションを説明するすべてのアニメーションですが、コンピューティングの観点からは必要ありません。不必要な状況でスピナーを強制する1つの代替策は、「成功」メッセージを表示して、実行したアクションが完了したことをユーザーに知らせることです。これを数秒後に非表示にするか、ユーザーが閉じるオプションを設定できます。
1つの注意点：ユーザーに対して嘘をつくことができることとできないことについて想定を始めるときは注意してください。 UBERは最近 引っ掛かっている そのマップに偽の車を置いたことに対して。インタラクションデザインの欺瞞についての本当に素晴らしい出版物が最近公開されています。ここで確認できます。 http://www.cond.org/benevolent.html （ページのPDFへの小さなリンクがあります）
したがって、私はスピナーを起動し、単純に0.6と0.65と言ってから、実際に接続のためにcall1を呼び出します。実際、通常はほとんど時間がかかりません。
これのポイントは何ですか？接続の呼び出しが非常に高速になる可能性があるので、理由をまったく言及していません（見逃していない限り）。
上記のcoinstarの例とは異なり、ユーザーの99.99％は、データベース接続の速度について強い意見を持っていません（サーバーがどこにあるのかさえわからない場合でも）。 つまり、ユーザーが待つ必要があることに煩わしさを感じるのは、人為的な遅延によってユーザーが追加される時間だけです。
そのため、何か重要なことが起こっていることを示すために必要なことを行い、他のアクションを禁止します。背景を暗くして、アニメーション.gifなど。ただし、所要時間を超えて拡張しないでください。
サービスを使用していた場合、特にFREQUENTLYを使用しなければならなかった場合、次の点で何がいらいらしますか。
- アプリを再起動するたびに0.8秒待つ必要がありますが、Niceアニメーションを表示するには、
または：
- アプリを再起動するたびに.2秒待つ必要があり、アニメーションを垣間見るだけ
私にとって、この質問は非常に明白であり（失礼ではありません!!）、現在のルートを検討している理由に関する大きな情報が欠けているように感じます。
スピナーやプログレスバーなどの背後にある考え方は、スピニング要素を実行スレッドに追加して、操作が開始するとスピナーが表示され、終了するとスピナーが消えるようにすることです。スピナーをアクション自体に関連付けておらず、その結果、不必要な遅延がアクションに追加されているため、それを行う方法は間違っているようです。
とはいえ、これはUXよりも実装に多くのことを行う必要があります。