非常に大きなモジュール式のWebアプリケーションがあります。
それが始まるとき、私は3つの方法のうちの1つをすることができます:
ユーザーにログイン画面が表示される前に、サーバーからすべてのモジュールを取得するための適度に長いロード時間(約60秒)(進行状況インジケーターでうまく表示されます)。ログイン画面の後、ユーザーは再び待つ必要はありません。
非常に短いロード時間(3秒、インジケーターなし)、必須のコアモジュールのみがロードされ、ユーザーはすぐにログイン画面が表示され、ユーザーが初めてモジュールにアクセスしようとするとオンデマンドでロードされます(その結果、モジュールごとに約3〜7秒の読み込み画面で)
必須のコアモジュールと最も頻繁に使用される2/3のモジュールがロードされる中程度のロード時間(インジケーター付きで約20秒)、ログイン画面が表示され、使用頻度の低いモジュールがオンデマンドでロードされます(ここでも3〜7秒待つ)
私の最初の反応はユーザーが選択できるようにすることですが、これは実際、ほとんどのユーザーが変更することを気にしない、または単に考える必要がないような詳細のようです。
モジュールは自由にロードできますが、モジュールのロード中にユーザーインターフェイスが遅くなるため、ユーザーがアプリケーションをアクティブに操作している間は、バックグラウンドでモジュールをロードし続けるのが嫌です。
ユーザーとしてどのオプションを選択するか(およびその理由)、またはより良いエクスペリエンスを提供できる他の戦略がある場合でも、ぜひお聞かせください。
研究を思い出すことはできませんが、速度の知覚は最初のアクションまでの時間に大きく影響されることがわかっています。
だから私の提案は4番目のオプションです:
これにより、顧客がオプションを選択する必要がなくなるため、顧客の応答性とシンプルさの間の最良のバランスが得られます。
私にとって、あなたのケースではオプション3を試す価値があるように思われます。それが理由です。
調査から 中断された作業のコスト:速度とストレスの増加 :
中断のコンテキストが違いを生むかどうかを調査するために、実証研究を行いました。コンテキストによって違いが生じることはありませんが、意外なことに、中断されたタスクを短時間で完了し、品質に違いはありませんでした。私たちのデータは、人々がより速く働くことによって中断を補うことを示唆していますが、これは代償を伴います: より多くのストレス、より高い欲求不満、時間的プレッシャーと努力を経験している。
モジュールの読み込みによる遅延中作業はinterruptionsのようだと思います。私にとっては、アプリが起動するのを待って、(ほとんど)遅延なしで作業を行う方が常に速く起動し、モジュールの読み込みなどによって引き起こされる遅延によってときどき中断されるよりも優れています。
私が理解している限り、ユーザーは時々(または定期的に)サービスを使用するため、起動時間が長くなっても、その後はスムーズに動作することがわかります。
また、本当にUIが豊富なアプリを開発している場合は、ユーザーがログイン後に画面を観察しながらいくつかの追加モジュールをロードするなど、いくつかのトリックを使用していると思います。
できるだけ早く(長いロードが発生する前に)ログイン画面を表示することが重要だと思います。
したがって、すべてのモジュールをロードするかどうかが問題になりますOR必須モジュールのみORログイン成功後、ユーザーがアプリの使用を開始する前にモジュールなし。
これはアプリの種類に依存すると思います:
アプリによっては、ユーザーが構成していないモジュール(初回の構成が必要な場合)、または最初の数回のセッション後にユーザーが使用したことがないモジュールをプリロードしないことが可能です。
多分あなたは提供することができますお気に入り?ユーザーがダッシュボードで目立つようにリンクしたいモジュールに「スターを付ける」/ブックマークモジュールを使用できるようにして、ユーザーがそれらにすばやくアクセスできるようにします。これで、ユーザーごとにお気に入りのモジュールをすべてプリロードできます。