インタラクションが不自然に感じる/エラーメッセージが必要になるまでの許容可能な最長の遅延はどれくらいですか？
ユーザーが画面に何かを描画できるように、APIを呼び出す必要があるシナリオがあります。以下のシナリオが考えられます。
API呼び出しは迅速に実行され、成功します。ユーザーは、明確な遅延なしに画面に新しいオブジェクトを描画します。
API呼び出しは迅速に実行され、失敗します（まれですが、たとえば、3Gデータが一瞬途絶えた場合に発生する可能性があります）：ユーザーが画面上に新しいオブジェクトを描画しようとしましたが、これが発生していないという視覚的なフィードバックがすぐに得られます。この時点で、彼らはすぐに再試行でき、何が起こったのか、または再試行できることを説明するエラーを必ずしも必要としません。
API呼び出しは遅くなりますが成功します。ユーザーは画面上にオブジェクトを描画できますが、かなりの遅延があります（これがまれであることを願っていますが、発生する可能性があることを認める必要があります）。相互作用は「だらしない」と感じるでしょう。
API呼び出しが遅くなり、失敗します。ユーザーは、オブジェクトの描画を再試行する必要があることを最終的に検出する前に、視覚的なフィードバックを待つ時間を長くします。
ユーザーがクライアントの画面に「正常に」描画できるようにする（つまり、対話の応答性を高める）ことでAPIの呼び出しと応答がバックグラウンドで行われるようにすることで、待ち時間とAPI呼び出しの成功の不確実性を回避できます。ただし、API呼び出しが失敗した場合は、エラーメッセージが必要になります。「ええ、申し訳ありませんが、先ほど行った画面への描画はそれほどではありません」とユーザーに通知する必要があります。
だから私の質問は：
a）「画面に描画する」応答の待ち時間が長すぎるのはどれくらいですか？
そして
b1）インタラクションを高速化することを優先する必要がありますか（つまり、クライアントで実行し、舞台裏でAPI呼び出しを行います。「ええと、嘘をついたので、あなたはそれを描きませんでした。事」）
または
b2）ときどき遅くなることを受け入れ、ユーザーはもう一度描き直す必要があることを受け入れますか？ （それほど面倒ではないようで、おそらくあまり起こらないでしょう）
待ち時間の基準
Microsoftは、ソフトウェアが待機時間の最初の数秒間に実行できる/実行する必要があることについての標準を公開しています。
「これは正しいコントロールです Microsoft Windows UXガイドラインのこのページ（進行状況バーについて） 」の見出しの下にあるガイドラインを読み始めることができます。 無視してください「これは正しいコントロールです "セクションは、代替案のガイドラインに実際にリンクしています。
このページの他の場所のコメントで述べたように、Microsoftは待機時間の境界が短く、許容可能であり、長すぎても絶対的ではありません。
また、絶対値はコンテキストに大きく依存するため、役に立たない尺度になる場合があります。実際の待機時間と知覚される待機時間の長さは大きく異なる可能性があることを示す多くの調査があります。何かがすぐに起こったように人々に感じさせることができる場合は、ユーザーがそれを非常に遅く感じている場合と同じように対処する必要はありません。
流体規格の方が役立つ場合があります
追加の読書の出発点として、 Wikipedia on Time perception を試すか、インターネットを検索するか、またはSteven Seowの本 Designing and Engineering time を試してください。 、試してみてください Faster：ほぼすべての加速 James Gleick。
私は何をしますか？
私は流動的な標準を推奨しただけですが、私たちはしばしば開発者にこれを言い表すことができません。
- 4秒以内にシステムはフィードバックを提供する必要があります。理想的には、フィードバックは、ユーザーが実行したいタスクをすばやく実行することです。
- それより長い場合は、処理がバックグラウンドまたは段階で行われている間に、ユーザーに注意を向けて意味のあるものを提供する方法を考えてみましょう。
すでに2番目のオプションに傾いているようですが、私も同感です。遅延を引き起こすことは完全なフラストレーションを作成するよりも優れています。
どちらの方法でも、Jakob nielsenが言うように、ユーザーは遅い応答時間に対して異なる反応を示します。
応答時間制限
3つの応答時間制限は、1993年に私が書いたときと同じです（ヒューマンファクターのパイオニアによる40年の研究に基づく）。
0.1秒は、瞬時に反応するという感覚を与えます。つまり、結果は、コンピューターではなくユーザーによって引き起こされたように感じられます。このレベルの応答性は、直接操作の感覚をサポートするために不可欠です（直接操作は、ユーザーエンゲージメントとコントロールを向上させるための主要なGUIテクニックの1つです。詳細については、すべてのデザイナーが知っておくべきユーザーインターフェイスの原則コースを参照してください）。
1秒は、ユーザーの思考の流れをシームレスに保ちます。ユーザーは遅延を感じることができるため、コンピューターが結果を生成していることがわかりますが、全体的なエクスペリエンスを制御でき、コンピューターを待つのではなく自由に動いていると感じます。この程度の応答性は、良好なナビゲーションに必要です。
10秒はユーザーの注意を維持します。 1〜10秒の間に、ユーザーは間違いなくコンピューターのなすがままに感じ、それがより高速であることを望みますが、彼らはそれを処理できます。
10秒後、彼らは他のことについて考え始め、コンピューターが最終的に応答するようになると、頭を元に戻すことが難しくなります。
http://www.nngroup.com/articles/website-response-times/
これらの時間枠を使用して、物事がロードされたときにドキドキやさまざまなメッセージを表示し、ユーザーに何が起こっているのかと待機が報われることを通知できると思います。
最初に、問題の枠組みを再考するかもしれません。説明したとおり、ユーザーがオブジェクトを描画してもサーバーがそれを受信しない場合、オブジェクトは描画されませんでした。 UXの観点からは、これは正確に逆のシステム指向の考え方です。 UXはユーザー中心です。
システムは権限ではなく、ユーザーです。オブジェクトは、ユーザーが描画するとすぐに描画されます。彼はすべての適切なアクションを実行し、すべての適切なフィードバックを見たので、ケースはクローズされ、ユーザーの仕事は完了しました。待機する必要はありません。システムが事実に対応していない場合、それはシステムの問題です。
システムがタイムリーに自己修正できない場合は、ユーザーに通知する必要があります。しかし、彼は何かを再描画したり、それ以上のアクションを実行したりする必要はありません。代わりに、システムは図面を再送信する必要があります。ユーザーに同じ作業をもう一度行わせることで、システムの欠点を罰する理由はありません。
製品の性質がタイミングに非常に敏感で、ユーザーが迅速なフィードバックを必要とする場合、タイミングの良いアニメーションを組み合わせて「手のひら」の効果（レイテンシの多い操作が発生しているときに時間がかかるアニメーション）を使用できます。 ）と「スケルトン画面」の概念（ LukeW：モバイルデザインの詳細：スピナーを回避する ）は、数秒間のレイテンシ関連の問題をカバーします。これは、ユーザーの心に欠陥のないシステムの幻想を助長し、彼とは何の関係もない技術的な詳細について心配するのを防ぎます。
描画などの操作（またはマウスドリブン操作）でレイテンシを最小限に抑えることが非常に重要であると思うので、3番目のオプションを提案します。描画操作を（クライアントで）すぐに実行しますが、描画されたオブジェクトが保留状態であることを示します。保留状態は、オブジェクトがグレー表示されているか、特別な色または特別な背景が付いていることで示されます。確認がサーバーから返されると、オブジェクトのビジュアルが「通常のオブジェクト/保留中でない」を示すように変更されます。
これによって達成される重要なことは次のとおりです。
- uIインタラクションへの即時応答
- ステータスは非常に明白です（保留中のものとそうでないもの）。
ユーザーは、保留中のオブジェクトを検査し（それらが保留されている期間を確認）、場合によっては再送信できる必要があります。
知覚ラグ=レイテンシ+フレームレート
Nielsenが説明する応答タイミングは、知覚される遅延とは異なります。ページの読み込みを待機している間、ユーザーは遅延が発生することを予期しており、一定の入力を提供していません。
絵を描いている間、ユーザーは一定の入力を提供し、即時の応答を期待しています。
これらのいずれかが発生すると、ユーザーはラグに気づきます。
- フレームレートが12fpsを下回る
- レイテンシは約200msより高い
リクエストによってこれらのいずれかが発生する場合は、裏で実行するオプションを選択する必要があります。
レイテンシ
人間は、レイテンシーとフレームレートに非常に敏感です。ユーザーは、比較的短い遅延の後でも描画が遅れていることに気づき始めます。
レイテンシが顕著になるときのしきい値に関する複数の学術記事があります。興味深いことに、これはオーディオとビジュアルのレイテンシでは異なります。一部の人にとっては、ビジュアル出力のレイテンシが100ミリ秒でも許容できる場合がありますが、10ミリ秒では楽器の演奏がすでに困難になります。
https://en.wikipedia.org/wiki/Input_lag テストの結果、約200 msの（コントローラー入力から表示応答までの）全体的な「入力ラグ」時間は、ユーザーの注意をそらすことがわかりました。
https://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay 100ミリ秒のしきい値が30年以上前に確立されました。
フレームレート
https://en.wikipedia.org/wiki/Limited_animation 通常の速度の動きの場合、一般的にほとんどのアニメーションは「2倍」で行われます。つまり、各図面は2回表示され、合計12の図面になります。 24フレーム/秒。より速い動きは、各フレームに新しい描画を伴う「1つの」アニメーションを要求する場合があります。
遅延が発生した場合の処理に加えて、接続品質をユーザーに早期に知らせることは良いことだと思います。これの良い例は、Skypeで誰かに電話をかけるときです。これにより、ユーザーは何かに取り組んでいる間に不意を突かれるのではなく、接続強度に基づいて遅延を予期する準備ができます。
