web-dev-qa-db-ja.com

複数のデザインパターンによって導入されたページステータスの断片化-ページ読み込みのベストプラクティス？

最近のGoogle Chromeの更新の1つでは、ブラウザーのタブのファビコン領域にロードアニメーションが導入され、ページのロードステータスを処理するさらに別の方法を見てきました（ちなみに、Firefoxブラウザーは左右に使用します） LinkedInによって悪名高くなった不確定な読み込み状態アニメーション。

enter image description here

私の知る限り、これにより、ページの読み込みステータスを示すことができる少なくとも5つか6つの異なる方法が作成されます。その多くは同時に発生し、ページコンテンツの現在の状態をユーザーに混乱させます。

だから私が見たものは次のとおりです：

  • 上の画像に表示されているブラウザータブのファビコン領域読み込みインジケーター（これに名前はありますか？）

  • マウスカーソル読み込みインジケーター
    enter image description here

  • ページヘッダーの読み込み進行状況インジケーター-例 ここ

  • モーダル/ポップアップページの読み込み進行状況インジケータ enter image description here

  • 行動を促すボタンの進行状況インジケーターのアニメーション enter image description here

  • ページ読み込みインジケーターの下部（無限スクロールが実装されている場合など）-例 ここ

ページコンテンツのステータスの処理に関して「ベストプラクティス」があると仮定すると、ページのステータスが完全にロードされていないことをユーザーに示すために非常に多くの異なる方法が必要な理由はありますか？これは非常に一貫性のないユーザーエクスペリエンスを提供し、ユーザーのフラストレーションを高めませんか？

design-patternsbrowserloadingstatuspage
1
Michael Lai

まあ、すべての可能なシナリオを検討することは非常に難しいので「ベストプラクティス」がないと確信しています（余談ですが、忘れていましたスケルトン）。

まず、ブラウザーとアプリの少なくとも2つのレイヤーを混在させます。あなたが見る多くのアプリがChrome=がこれをローンチする前に作られたものであることを考慮しなければならないので、これらのアプリはこれから何が来るのかをどのように推測しますか？

これで、冗長な（そしていくつかのEdgeのケースでは競合する）情報を持つ少なくとも2つのレイヤーができました。合計が ユーザーの摩擦認知負荷 になることを確認するための調査は必要ありません。これは、測定の定義 認知負荷 のようなものです。

確立された眼球運動と認知負荷の瞳孔反応指標は次のとおりです。

pupillary diameter mean
pupillary diameter deviation
number of gaze fixations > 500 milliseconds
saccade speed
pupillary hippus

（念のために、複数の注目点が上記の値の1つ以上を増加させます）

ただし、ページが正しく使用されている限り、ページの読み込みステータスに関する情報を表示することは確かに有益です（詳細については ローダーと空の状態を使用する場合 ）。

だから、私たちはこれを持っています：-読み込みステータスに関する情報を追加することは良いです。 -冗長な情報があるとユーザーの摩擦が増える

私たちは何をすべき？

まあ、ブラウザの読み込みステータスは 何が発生するのか について不確実性が生じるため、あまり良くありません。しかし、それを制御することはできません。さらに、ブラウザはあなたがその情報を提供しているかどうかを知りません。

一方、ユーザーに有用な情報を提供する必要があります。それはユーザーの責任であり、ユーザーがURLバーに小さな機能を表示するかどうかは信頼できません（個人的に、私はその機能に気付かなかったあなたはそれを言及しました）。

したがって、正しい答えは提供する必要がある情報を完全に制御して提供し、ユーザーが何を期待し、それを待つ時間を知ることができると信じています

ブラウザのネイティブ機能は、ユーザーのために作成する必要のあるエクスペリエンスを妨げてはなりません。最悪の場合、小さな認知的負荷がかかり、それを測定して最終的には克服することができます

1
Devin

ページの読み込みは非常に複雑なプロセスであるため、最初に考慮すべきことは、「レイヤー」（コード、ビューポート、ブラウザ、OS、帯域幅、インターネット、サーバーなど）が所有していないことですが、すべてに関係します。 。つまり、多くのレイヤーでローダー（Webコンポーネント、Webページ、ブラウザー、OSなど）を表示できます。

フィッツの法則 により、アクションに近い1つの指標が最も効果的です。ただし、ロードアクションはさまざまな場所から発生するため、効果がありません（フィッツの法則によりCTAとカーソルが当てはまりますが、見やすさが疑わしく、おそらく見落とされています）:(

それで、可視性に戻ります。私にとっては、ユーザーが「それを探す」必要がないので、より良いものはより多くの可視性を与えるものです。

それは「ページヘッダー読み込み進行状況インジケーター」を勝者にします。また、次の利点もあります。

  • ブラウザ間で簡単に移植可能
  • クッパレベルであることにより、トランザクションをより詳細に制御できます（つまり、ブラウザはページよりもチョークが少なくなります）。
  • 簡単に識別できるパターン（「ロードバー」）を意図している
  • パーセンテージ、読み込まれているさまざまな読み込まれたコンポーネントのセクション、速度制御などの細かさのレベルを取得できます。

最後に、何度も冗長性が損なわれていなくても、この場合は、すべてのローダーが同期されておらず、最も正確にロードを追跡しているユーザーを混乱させれば、そうなると思います。したがって、最も賢明な解決策は、ウェブサイトが詳細な読み込みデータを渡すのを助けることができるブラウザAPIであるかどうかです（ページが提供しない場合でも、進行状況を示します）。

1
Victor Zambrano

ページ読み込みステータスは、何かが進行中であることを示す必要があります。

プロセスの複雑さにもよりますが、0.000001から数分（そして多かれ少なかれ）かかります。

多くの場合、いわゆるlazy loading（これにより、一度にすべてを読み込まずに、APIからデータを徐々にダウンロードして、小さな部分に分割するだけで済みます。

手術時、ユーザーは落胆するべきではなく、刺激を与えられるべきです（それが長続きしない場合（最大数秒）、進行状況バーは必要ありません）。

enter image description here

ただし、プロセスがより高度になる場合もあります（コンピューターのスキャン、デフラグ、モジュール全体の削除、上書き、データベース全体のインポートなど）。

この場合-プロセスの進行状況、進行状況、および推定時間について通知する価値があります（15分かかるため、リラックスしたり、買い物に行ったり、別のタスクを開始したりできます）

enter image description here

フラストレーションに関する質問に戻ります。ユーザーがすべてを制御下に置いているとき、彼はそれほどフラストレーションがありません。

Nielsen Heuristicsによると：

システムステータスの表示ユーザーに完全な制御権を与える

それでは、情報を提供して、可能な機会を提供しましょう。たとえば、次のようにします。

  • 手術の延期
  • 運転を停止する
1
Piotr Żak