コンテンツをアプリにロードするのに時間がかかる場合はどうすればよいですか？
私は、作業中のアプリのすべてのローダー（スピナー）を置き換えています。待機とあまり結びつかない別のソリューションが必要だからです。ローダーが待機する必要があることをローダーが示すため、ローダーを見るとイライラします。ローダーの代わりに、LukeWróblewskiが推奨するように、プリロードスケルトン画面を表示します。 Facebookは（印刷画面）を使用しています。スケルトン画面は基本的に、情報が徐々に読み込まれるページの空白バージョンです。これにより、画面に情報が徐々に表示されるので、物事がすぐに起こっているという感覚が生まれます。
この場合、ユーザーはネットワークに接続していますが、接続が不良です。 2gまたはサーバーの応答時間が通常より長くなります。
私の質問：
- コンテンツが長時間（たとえば、5秒または10秒を超えて）表示されない場合はどうすればよいですか？コンテンツが到着するまで、プリロードスケルトン画面を常に表示するか、それとも他のものに置き換える必要があるか。追加情報-「コンテンツをロードするのに時間がかかりすぎて申し訳ありません。ネットワークを確認してください」。
あなたは（文字通り）ユーザーを待たせることはできません
ユーザーが必要な情報を取得していないときに、ユーザーが携帯電話をポケットに戻さないようにする「魔法のメッセージ」はありません。文字通り、彼らは待ちません。
確かに、ネットワーク接続または「 Lie-Fi 」の状態は、多くの場合、制御不能です。ユーザーはこれも認識できますが、それによって一部の患者がより辛抱強くなることもあります。
表示何か高速
ユーザーが欲しいものを画面にできるだけ早く入れる必要があります。
これは、チームがユーザーエクスペリエンスを向上させるために達成する必要がある最大のことであり、 ユーザーの損失を防ぐ です。
いくつかの 接続不良に対処するためのベストプラクティス があります。一般的なものを2つ示します。
システムが遅延を最小限に抑えるように最適化されていることを確認してください
開発チームがユーザーにデータをすばやく提供することがいかに緊急であるかを理解していない可能性があります。技術レベルでできることはおそらくいくつかあります ユーザーのデバイスに少しだけ情報をすばやく取得する 。
あなたはまた、ビジネスに反対する必要があるかもしれません。画面上の「ページの読み込み時」にプロセスが数秒遅くなる特定のデータが必要な場合は、その要件がどのように害を及ぼしているかを示す必要があります。その遅いデータは、ページが利用可能になったときにページに「入力」できます。
キャッシュされたコンテンツを利用する
表示しているコンテンツの種類については言及していません。昨日のコンテンツが役に立った場合は、それを表示します（おそらく、アプリが新しいデータを取得しようとしているというメッセージとともに）。たとえば、昨日の天気予報は、空白の画面よりも優れています。
はい、動的な進行状況インジケーターが役立ちます
冷酷な真実は、ユーザーが絶対にタスクを完了する必要がある場合（たとえば、法的に強制されている場合）を除いて、ユーザーにアプリの応答を20秒待つように要求することはおそらく機能しません。つまり、ユーザーに情報を提供するというあなたの傾向は正しいです。
ユーザーが大幅な遅延に直面すると、進行状況インジケーターが表示されます
「重要」はあなたが考えるよりも短いかもしれません：
Nielson Norman Groupは、次のような率直な結論を出します：「 進行状況インジケーターは遅いシステムを十分に利用できないようにする 」および次のガイドライン：
約1.0秒以上かかるアクションには、進行状況インジケーターを使用します。
これは、画面上の「ちらつき」を煩わせずに、アプリケーションが機能しているというフィードバックを提供するための優れた一般的なガイドラインです。理想的な条件下で、データ転送が1秒未満で完了する場合、インスタンスの進行状況バーが点滅するのは煩わしいだけです。サーバーからの応答がないまま1秒が経過すると、2つのことがわかります。
- ユーザーは遅延があることに気づきました
- この遅延がさらに数秒続く可能性は十分にあります
そのため、接続が予想よりも遅いことを示すメッセージが表示されますが、それでも完了することが予想されます。 時々接続は1.01秒で完了します（エラーメッセージが点滅してから消えます）が、まれです。
進行状況インジケーターは、真実で明確な情報を提供する必要があります
「しばらくお待ちください」というメッセージを長期間にわたって効果的にしたい場合は、アプリをユーザーに正直にする必要があります。 「しない「接続を試行しています」というメッセージを永久に残しておきます。適切な場合は、タイムアウトメッセージまたは接続失敗メッセージに置き換える必要があります。
真の実用的な情報が求められます。サーバーエラーが発生した場合は、エラーメッセージでそれを認め、可能であればサポートの連絡先を提供してください。あなたがそうであると信じる理由がある場合にのみ、問題が彼らの接続性にあると信じるようにユーザーを導く。
さらにメッセージを追加する
特定のケースでは、（残念ながら）すべてのデータを取得するためのモノリシックな同期リクエストがあります。このダウンロードに1秒以上かかる場合は、「サーバーに正常に接続しました。データをダウンロードしています…」
同じルールが適用されます。メッセージが画面全体で数秒間点滅するのを避けます。ユーザーがアプリで「ギアがまだ回転している」と伝えるのに十分なフィードバックを提供します（そしてアプリが機能しなくなったときはすぐにユーザーに伝えます）
まず、たとえばx秒経過しても何も起こらない理由を特定する必要があります。それが非常に間違っていることを知らずに、ネットワークの速度が遅い可能性があることをユーザーに示す（ここではFacebookの画面の例を挙げているため）。
- ユーザーのネットワークが遅い場合は、Facebookの
アプローチ、また、ユーザーにreconnectボタンを与えることもできます。
接続を再確立してください。 - アプリがなんらかの理由で失敗している場合は、正直に言って「何かが本当にうまくいかなかった、もう一度お試しください」画面を表示してください。
他の人が言ったように、あなたの優先事項はデータをできるだけ早くユーザーに届けることです。それでもインターネット接続が遅いために問題が解決しない場合は、次のことをお勧めします
- 接続を改善するように指示する
- ロード中に読み物を提供して、待つのをやめられるようにします（アプリに関連するいくつかの興味深い事実に基づいています）
- スピナーの代わりにプログレスバーを表示します。スピナーの最も苛立たしいことは、人々がどれだけ待つ必要があるかわからないことです（どれだけ私はもっと待つ必要があるのですか？、私はデータを受け取ることさえしていますか？など）。プログレスバーは、どれくらい時間がかかるかという感覚を与えるので、必要とされる「未知の」時間から心が幾分緩和されます。
編集：
Progressabarに対するコメントに基づいて、
さて、あなたはあなたのアプリが実行しようとしているステップの抽象的なメッセージを与えることができます。例えば、
接続を確立しています...（1/5）認証しています...（2/5）データを要求しています...（3/5）データを受信しています...（4/5）準備完了...（5/5）
あなたのアプリが何をするのか私にはわからないので、これは単なる例です。ただし、必要に応じて抽象メッセージを追加することもできます。
ロード時間を改善できない場合は、ユーザーの注意散漫について question も確認してください。
このプリロードスケルトン画面を基にして、表示されるフィールドの説明を表示できます。何が近づいてくるのかをユーザーが理解（読む）できるようにするためです。
プロセスは多かれ少なかれこのようなものです：
1. "You are sending a request" (interaction)
- There are difficulties sending the request (message)
x The request couldn't be send (message)
2. "We received your request and we are sending the information"
- There are a difficulties receiving the information (message)
x The information couldn't be received (message)
3. "You received the information" (interaction)
常にフレージングを考慮し、ユーザーに責任を負わせないようにします。
- ユーザーにプロセスのどのポイントにいるのかを知らせます、対話/応答または明示的なメッセージのいずれか。
- 正しく動作しない/失敗する可能性のある理由のユーザー情報を提供します。
- 彼が修正するために何ができるかを彼に知らせてください問題があれば、それが手にあれば。
症状を解決する代わりに（またはそれに加えて）、問題を攻撃することをお勧めします。
読み込みに時間がかかるのはなぜですか？必要に応じて画像や動画のコンテンツを埋め戻すプレースホルダーを使用して、基本的なテキストコンテンツを1秒以内にユーザーに送信することは問題ありません。
DBクエリは可能な限り最適化されていますか？検索対象のテーブルは適切にインデックス化されていますか？等。
データをクライアントに最適な方法で返していますか？たとえば、最小限のJSONと肥大化したXMLの違いは？
only必要なデータを取得/返していますか？...別のAPI呼び出しを再利用していません関係のないデータを取り戻しますが、便利ですか？
クライアントのリソースを適切にキャッシュしていますか？古くなっているデータのみをフェッチしていますか？
ネットワークの問題を克服しようとしている場合、静的/キャッチ可能なコンテンツを地理的に多様なCDNに分散して、負荷を分散し、ボトルネックを減らしましたか？
ユーザーが必要な場所に到達したときに準備ができるように、必要になる前にセカンダリコンテンツを遅延ロードできますか？
これのいずれかが過酷または軽視されている場合は申し訳ありません...それは意図されたものではありませんが、失速したUIの視覚的な問題を解決するために何人の開発者/デザイナーが解決しようとするのか、コードが修正されないようにして驚かされることがよくあります克服するための遅延。