デスクトップブラウザでの全画面「読み込み」オーバーレイ
私たちは最近、小さな画面でより良いUXを提供するために、Webアプリで操作をロードするための全画面モーダルを導入しました。問題は、以前のローディングスピナーが小さい画面で画面の外に出てしまうことがあったことです。
私たちのソリューションは、サーバーがそれを処理するのに少し時間がかかる操作のために、スピナーが入った半透明のオーバーレイを表示するだけです-通常これは高速ですが、低速の接続では数秒かかる場合があります。オーバーレイはモバイルデバイスで優れたUXを提供すると思います。
大画面でも同じオーバーレイを使用するようになりました。私たちのチームメンバーの一部はそれを気に入っていますが、他のメンバーはそれが非常に煩わしいと思っています。特にサーバー側の操作がすばやく完了すると、半透明のモーダルがすぐにフラッシュに表示され、ユーザーは何が起こったのか疑問に思います。
Webアプリケーションでの全画面「読み込み」オーバーレイに関するベストプラクティスまたはガイドラインはありますか？それらは良いですか、それとも避けるべきですか？
クイックフラッシュはモバイルデバイスでも発生する可能性がありますが、画面が小さく、ユーザーがそのようなデバイスで全画面表示のモーダルに慣れているため、気が散ることが少なくなります。
「ロード」画面、プログレスバー、スピナーなどは、プログラムがクラッシュしたり応答しなくなったりしていないことをユーザーが再確認するのに十分な時間がかかる操作に必要です。期間が短い操作の場合、スピナーまたはロード画面は実際に遅延の（実際の期間ではないとしても）知覚される期間を増やすことができます。
進行状況バーのデザインが感知された遅延にどのように影響するかなど、感知されたパフォーマンスに関するかなりの量の調査が行われました（「後方に移動して減速するリブ付き進行状況バー」はこの研究で感知されました たとえば、実際の時間よりも11％速い）-ただし、一般的にはJakob Nielsenの経験則はまだ問題ありません。1で、ユーザーは何か問題が発生したのではないかと考え始めます。 10代になると、仕事を放棄する可能性が高くなります。したがって、1秒未満の読み込みや進行状況バーは一切表示せず、10秒を超えてUIをブロックすることは可能な限り回避する必要があります。
（とはいえ、10秒は長い時間です。UIをブロックするのではなく、長い操作をバックグラウンドにプッシュする方法がある場合は、そうするようにしてください：ユーザーに作業を続けさせ、操作が完了したら通知する代わりに、スピナーを全時間見つめるように強制します。これが有効になる正確な時間は、特定のタスクとユーザーがそれを実行するのにかかると予想される時間、および実装の詳細に依存します。たとえば、単一ページアプリフレームワークは、より「伝統的な」構造化アプリケーションと比較して、XHRを介したバックグラウンド操作を比較的無痛にし、準備ができたときに通知します。）
ロードスクリーンオーバーレイの実装が表示される前に遅延を導入することが難しいような場合、簡単な解決策は、CSSトランジションをオーバーレイに追加して、最初の1秒間は透明でオフスクリーンに保つことです（使用する例えば animation-delay、または@keyframeingは、1秒が経過した後にのみ、0から不透明度を変更します）。短い操作の場合、要素は引き続き描画されますが、必要になるまで長く維持されるまでユーザーには表示されません。
モバイルvsデスクトップ
読み込み画面のユーザーエクスペリエンスがモバイルデバイスでは異なると何度か主張します。
...モバイルデバイスでもクイックフラッシュが発生する可能性がありますが、画面が小さく、ユーザーはそのようなデバイスでの全画面読み込みモーダルに慣れているので、気が散ることはほとんどありません。
ここでの結論には非常に注意します。注意散漫は、画面のサイズに関係なく注意散漫です。 「ユーザーはそれに慣れている」とは、「他のユーザーがモバイルに標準以下のエクスペリエンスを提供しているので、私たちもそれを回避できる」ということです。モバイルデバイスとデスクトップデバイスの違いは、時間の経過とともに小さくなっています。フォームファクターは異なりますが、少なくとも平均的なWebアプリに関する限り、デバイスの機能はほぼ同等です。
システムの応答と遅延についてユーザーに適切な情報を提供することに関するガイドラインがあります。
この記事は1993年に最初に書かれましたが、2014年に更新されました。
応答時間に関する基本的なアドバイスは、30年前とほぼ同じです[Miller 1968;カード他1991]：
0.1秒は、システムが瞬時に反応していることをユーザーに感じさせるための制限です。つまり、結果を表示する以外に特別なフィードバックは必要ありません。
1.0秒は、ユーザーが遅延に気づいたとしても、ユーザーの思考の流れが中断されないようにするための制限についてです。通常、0.1秒を超え1.0秒未満の遅延の間は特別なフィードバックは必要ありませんが、ユーザーはデータを直接操作する感覚を失います。
10秒は、ユーザーの注意をダイアログに集中させるための制限とほぼ同じです。より長い遅延の場合、ユーザーはコンピューターが完了するのを待っている間に他のタスクを実行する必要があるため、コンピューターがいつ完了するかを示すフィードバックをユーザーに提供する必要があります。遅延中のフィードバックは、応答時間が非常に変動する可能性が高い場合に特に重要です。ユーザーは何を期待するかわからなくなるためです。
したがって、これは遅延応答を実装する「方法」について具体的には触れていませんが、その背後にある理由付けを繰り返します。したがって、オーバーレイなどを使用するかどうかにかかわらず、ポイントは効果的かつ効率的に機能する必要があるということです。たとえば、適切なレベルのシステム応答を提供するには、インテリジェンスを設計して組み込む必要があります。何かが非常に迅速に発生する場合、ユーザーに何かを提示する必要はありません。