web-dev-qa-db-ja.com

単一の長いロード-または複数の短いロード、どちらがより良いエクスペリエンスを提供しますか?

非常に大きなモジュール式のWebアプリケーションがあります。

それが始まるとき、私は3つの方法のうちの1つをすることができます:

  1. ユーザーにログイン画面が表示される前に、サーバーからすべてのモジュールを取得するための適度に長いロード時間(約60秒)(進行状況インジケーターでうまく表示されます)。ログイン画面の後、ユーザーは再び待つ必要はありません。

  2. 非常に短いロード時間(3秒、インジケーターなし)、必須のコアモジュールのみがロードされ、ユーザーはすぐにログイン画面が表示され、ユーザーが初めてモジュールにアクセスしようとするとオンデマンドでロードされます(その結果、モジュールごとに約3〜7秒の読み込み画面で)

  3. 必須のコアモジュールと最も頻繁に使用される2/3のモジュールがロードされる中程度のロード時間(インジケーター付きで約20秒)、ログイン画面が表示され、使用頻度の低いモジュールがオンデマンドでロードされます(ここでも3〜7秒待つ)

私の最初の反応はユーザーが選択できるようにすることですが、これは実際、ほとんどのユーザーが変更することを気にしない、または単に考える必要がないような詳細のようです。

モジュールは自由にロードできますが、モジュールのロード中にユーザーインターフェイスが遅くなるため、ユーザーがアプリケーションをアクティブに操作している間は、バックグラウンドでモジュールをロードし続けるのが嫌です。

ユーザーとしてどのオプションを選択するか(およびその理由)、またはより良いエクスペリエンスを提供できる他の戦略がある場合でも、ぜひお聞かせください。

14
PhonicUK

研究を思い出すことはできませんが、速度の知覚は最初のアクションまでの時間に大きく影響されることがわかっています。

だから私の提案は4番目のオプションです:

  1. 最低限必要なものをロードこれは、顧客がアプリを見て、何をしたいかを決めるために必要です。基本的に、オプション2として説明した内容。
  2. 他のモジュールを自動的にloading queue(使用頻度に基づく)に入れ、一度に1つずつ取得します。
  3. モジュールがまだロードされていない何かを顧客がしようとする場合は、ロード中のイメージを表示し、そのモジュールをロードキューの前に配置します。

これにより、顧客がオプションを選択する必要がなくなるため、顧客の応答性とシンプルさの間の最良のバランスが得られます。

12
JohnGB

私にとって、あなたのケースではオプション3を試す価値があるように思われます。それが理由です。

調査から 中断された作業のコスト:速度とストレスの増加

中断のコンテキストが違いを生むかどうかを調査するために、実証研究を行いました。コンテキストによって違いが生じることはありませんが、意外なことに、中断されたタスクを短時間で完了し、品質に違いはありませんでした。私たちのデータは、人々がより速く働くことによって中断を補うことを示唆していますが、これは代償を伴います: より多くのストレス、より高い欲求不満、時間的プレッシャーと努力を経験している

モジュールの読み込みによる遅延作業はinterruptionsのようだと思います。私にとっては、アプリが起動するのを待って、(ほとんど)遅延なしで作業を行う方が常に速く起動し、モジュールの読み込みなどによって引き起こされる遅延によってときどき中断されるよりも優れています。

私が理解している限り、ユーザーは時々(または定期的に)サービスを使用するため、起動時間が長くなっても、その後はスムーズに動作することがわかります。

また、本当にUIが豊富なアプリを開発している場合は、ユーザーがログイン後に画面を観察しながらいくつかの追加モジュールをロードするなど、いくつかのトリックを使用していると思います。

2
alexeypegov

できるだけ早く(長いロードが発生する前に)ログイン画面を表示することが重要だと思います。

  • ログインが必要であることを知らないユーザーは、60秒待つ必要はありません。ログインできない(またはログインしたくない)ことに気づくだけです。
  • ログインデータがわからないユーザーは、正しいパスワードを忘れたことに気づくだけで、ログインを試行できるようになるまで60秒待つ必要はありません。

したがって、すべてのモジュールをロードするかどうかが問題になりますOR必須モジュールのみORログイン成功後、ユーザーがアプリの使用を開始する前にモジュールなし。

これはアプリの種類に依存すると思います:

  • セッションの長さはどのくらいですか?ユーザーは1日中ログインしていますか、それとも数分間しかログインしていませんか?セッションがかなり長い(おそらくバックグラウンドで、ユーザーがアイドル状態になっている)ときに、より多くのモジュールをプリロードします。セッションがかなり短いときにモジュールをプリロードしないでください。
  • ユーザーが使用するモジュールの数ユーザーがセッションでallモジュールを使用するのは一般的ですか、それともユーザーは1つまたはいくつかのモジュールにのみ関心がありますか?すべてのユーザーが同じセッションで使用する典型的なモジュールのセットがある場合、それらの「必須」モジュールをプリロードします。多くのユーザーが1つまたは2つのモジュールでのみアプリを使用する場合は、モジュールをプリロードしないでください(したがって、「必須」モジュールはまったくありません)

アプリによっては、ユーザーが構成していないモジュール(初回の構成が必要な場合)、または最初の数回のセッション後にユーザーが使用したことがないモジュールをプリロードしないことが可能です。

多分あなたは提供することができますお気に入り?ユーザーがダッシュボードで目立つようにリンクしたいモジュールに「スターを付ける」/ブックマークモジュールを使用できるようにして、ユーザーがそれらにすばやくアクセスできるようにします。これで、ユーザーごとにお気に入りのモジュールをすべてプリロードできます。

1
unor