TL;DR:無限スクロールは場合によっては解決策を提供しますが、ユーザーにとっては理想的ではありません。
無限スクロールは混乱し、制御不能になり、ユーザーにストレスを与える可能性があります。
この記事では、なぜ無限スクロールでウェブサイトを構築するのをやめる必要があるのかを説明します。 しかし、開始するには、のは、スクロールの簡単な歴史を見てみましょう。
- スクロールの簡単な歴史
- コンピュータにおけるスクロールの進化
- 行(および列)
- Windows(OSではない)
- Webページ
- webページをナビゲートするために発明された経験
- オフセットベースのページネーション
- オフセットベースのページネーションの長所と短所
- カーソルベースのページネーション
- カーソルベースのページネーションの長所と短所
- 番号付きページネーション
- もっと読み込む
- 無限スクロール
- 無限スクロールでウェブサイトを構築するのをやめてください!
- フッターの検索
- タイムラインやフィードがない場合は無限スクロールを使用しない
- ユーザにより多くの制御を与える
- ユーザーが好きな場所に移動できるようにする
- 結論
- LogRocket:webアプリの完全な可視性
スクロールの簡単な歴史
スクロールが本当に何であるかを理解するために、スクロールという用語がどこから来ているのか見てみましょう。
スクロール(n.):c. 1400,”羊皮紙または紙のロール”
スクロールは、もともと情報が長くなったときに使用されました(宗教的な内容のように). そんなに多くのコンテンツは、管理、読み書きが困難になりました。
コンピュータが私たちの生活に入ってきたとき、私たちはまだ大きなコンテンツをナビゲートする方法が必要でした。
コンピュータにおけるスクロールの進化
行(および列)
インターネットの初期の頃、UXデザイナーはコンテンツをページング/スクロールする多くの方法を発明/ ウェブが普及する前に、私たちは画面上の行をスクロールしていました。
水平スクロールは、コンテンツを読むためのツールだけでなく、コンピュータの画面上を移動する方法をスクロールさせました。
Windows(OSではない)
スクロールを使って画面をナビゲートすることで、人々はwindowsを作成することを奨励しました。 Windowsを使用すると、一度に複数のコンテンツを表示できます。
Webページ
スクロールは、webページを閲覧している間に私たちが持っている非常に基本的な問題を解決します。 ただし、スクロールはユーザーに多くの問題を引き起こす可能性があり、ユーザーエクスペリエンスに悪影響を与える可能性があります。 詳しく見てみましょう。
webページをナビゲートするために発明された経験
開発者やデザイナーがwebページでユーザーをナビゲートするための経験をどのように作成したかを定義しようと
いくつかのバックエンドのページネーションシステムを学ぶことから始めましょう:
オフセットベースのページネーション
これは最も知られているページネーションシステムです。 この手法では、まず、ページネーションする必要があるアイテムの数を見つける必要があります:
-- All posts countSELECT COUNT(*) AS total FROM posts
すべての項目を数えた後、ページを計算する必要があります。 ページごとに10
アイテムを表示するとしましょう:
-- First page itemsSELECT * FROM posts LIMIT 10
そして、ページ3
にスキップしたい場合は、最初に30
項目をスキップする必要がありますOFFSET
:
-- Third page itemsSELECT * FROM posts LIMIT 10 OFFSET 30
そして私達は顧客に次の通り改ページ情報を送ります:
{ "pagination": { "items_count": 100, "current": 3, "total_pages": 10 }, "items": }
オフセットベースのページネーションの長所と短所
- 👍 良い:任意のページにジャンプしやすい
- ►良い:クライアントエクスペリエンスがより自由です
- ►悪い:パフォーマンスの問題
- ►悪い:
カーソルベースのページネーション
データが変更された場合、重複した項目が表示される可能性があります。 そこで、開発者はデータをページ分割するための新しい技術を思いついた:カーソル。
すべての行には一意のカーソルが必要です。 実際のページ数を知ることが不可能になるテーブル全体を数える必要はありません:
-- Get extra 1 item to get its cursor.SELECT * FROM posts ORDER BY id DESC LIMIT 11
ページネーションを助けるために、すべての投稿に一意のカーソルフィールド(またはこの例ではそのID)があると仮定します。 クライアントには、次のようなページネーション情報があります:
{ "pagination": { "next": 1234 // extra item's ID (cursor), null if end of data. }, "items": }
そして、カーソルを使用して次のページを求めることができます:
-- Offsetting records using 1234 cursorSELECT * FROM posts WHERE id >= 1234 ORDER BY id LIMIT 11
カーソルベースのページネーションの長所と短所
- 👍 良い:よりパフォーマンス、テーブルカウントなし
- 良い:誰かがテーブルの中央に行を挿入した場合、重複したアイテムを表示することはできません
- 悪い:任意のページにジャンプすることは不可能
- 悪い:クライアントは経験を持つ無料ではなく、合計ページと現在のページが計算されません
いくつかのナビゲーション技術を見てみましょう。
経験:クリックベース
テクニック: オフセットベースまたはカーソルベース
これは主にブログをナビゲートするために使用されます。 これは無限スクロールの最も古いバージョンです。 このアプローチを使用すると、ユーザーはコンテンツがどこで終了するかを知らない可能性があります。
番号付きページネーション
経験:クリックベース
テクニック:オフセットベース
これは、(私によると)最も使用可能なナビゲーションタイプです。 それはあなたが望むページにジャンプしたり、ワンクリックで最後または最初に行くことができますオフセットベースのページネーションを使用して
Googleは検索結果でこの種のナビゲーションを使用します:
もっと読み込む
経験:クリックトリガーベース
テクニック:カーソルベース-オフセットベースにすることもできますが、厄介です
これは最新のページネーション技術の一つであり、以前のバージョンの無限スクロールも使用しています。
上記の例では、ユーザーは”もっと読み込む”ボタンをクリックして、より多くのコンテンツを表示します。
無限スクロール
経験:スクロールベース
技術:カーソルベース-オフセットベースでもありますが、非常に厄介です
無限スクロールは、カーソルベースのページネーション技術の最新の経験です。
Hugh E.Williamsは、2005年にMicrosoftでinfinite scrollを発明したと主張している。
Metafizzyはまた、開発者が無限スクロールを構築するのに役立つツールを作成しました。
無限スクロールでウェブサイトを構築するのをやめてください!
このセクションまで、私たちはここに来た方法を見直しました。 さて、ここで吸う理由について話しましょう。
フッターの検索
フッターは、ヘッダーのように、ウェブページの解剖学の非常に基本的な単位です。 サイトでは、電話番号、住所、ヘルプとサポートのリンクなど、詳細な情報とリンクがフッターに保存されています。 ユーザーがこの詳細情報を検索している場合は、主に下にスクロールしてフッターを検索します。
無限スクロールでは、ユーザーはフッターを見つけようとするのに苦労することができます。 無限のスクロールは、ページの終わりを見つけることが不可能になります。 ウェブサイトの一番下に到達できないと、ユーザーが強調することができます(これは素晴らしいことではありません)。
無限のフィードを持つサイト(Twitterなど)は、この必要な情報とリンクをサイドバーに置くフッターの問題を解決します。 サイドバーはこの問題の解決策ですが、良いものではありません。 フッターはフッターに滞在する必要があります。
タイムラインやフィードがない場合は無限スクロールを使用しない
ソーシャルメディアアプリケーションは時間とともに動作します。 ユーザーの意図は、過去をナビゲートすることです。 この場合、無限スクロールはナビゲーションを容易にします。 ここでは、infinite scrollは、特にモバイルでのパフォーマンスに適しています。
しかし、あなたが電子商取引、ニュース、雑誌、またはブログのウェブサイトを持っていて、ユーザーの意図がアイテムや記事の周りを移動することである場 タイムラインベースのリストでは、人々は主に日付やユニークな瞬間を探しません。 アイテムベースのリストでは、ユーザーはアイテムを検索します。 無限スクロールは、ユーザーが見つけるためにあなたのアイテムはほとんど不可能にします。
ユーザにより多くの制御を与える
ユーザは、一般的にUiを制御できないと感じるときにUiを好まない。
スクロールイベントは、何かをするために非常に意図的ではありません。 人々はページをナビゲートし、アクションを呼び出したい場合は、主にクリックまたはタッチ(トリガーと呼ばれます)。 彼らは彼らの決定についてUIに通知します。 しかし、スクロールは何の決定もせずにトリガされます。
無限スクロールは、ユーザーのためにページを制御しにくくします。 ユーザーはジャンプの不具合にも遭遇する可能性があります。
無限スクロールの代わりに、トリガーである”もっとロード”ボタンを入れます。 これにより、ユーザーに制御が与えられます。 (私は古いスタイルの番号付きページネーションを好むだろうが、我々は今、カーソルベースのページネーションを使用することを前提としています)。
ユーザーが好きな場所に移動できるようにする
ユーザーはページ間を移動したり、ブックマークしたり、友人とページを共有したりすることができます。
しかし、無限スクロールはその設計によって状態を保持することはできません。 つまり、分析ツールを使用してユーザーのアクションを追跡することもできません。
バックエンドページネーションテクニックがカーソルベースの場合、ユーザーがどこにでも行くことを許可することはほとんど不可能です。 電子商取引ウェブサイトがある場合は、ユーザーが必要な製品に移動する制御をユーザーに与えます。
さらに、リストに”並べ替え”機能がある場合は、ユーザーにページネーションを表示する必要があります。 アルファベット順のリストでは、Kで始まる製品にユーザーを強制的にスクロールダウンさせてはいけません。
ユーザーがどこにいるかを確認できるようにする必要があります。 ユーザーはしばらくスクロールし、ステートレスなデザインなので、”次のページ”が何回読み込まれたのか分かりません。 ページを更新すると、元のページに戻ってリセットされます。 ユーザーは、以前の場所を見つけるために下にスクロールする必要があります。
結論
無限スクロールはいくつかのケースではいいですが、通常は問題解決者ではなく、問題作成者です。 UXの人々は、ページネーションの問題を解決するために無限スクロールを銀の弾丸と考えるべきではありません。 無限スクロールのウェブサイトを造ることを止めなさい。
LogRocket:webアプリの完全な可視性
LogRocketは、自分のブラウザで起こったかのように問題を再生できるフロントエンドアプリケーション監視ソリ エラーが発生した理由を推測したり、スクリーンショットやログダンプをユーザーに尋ねる代わりに、LogRocketを使用すると、セッションを再生して何が間違っていたかをすばやく理解することができます。 これは、フレームワークに関係なく、任意のアプリで完璧に動作し、Redux、Vuex、および@ngrx/storeから追加のコンテキストをログに記録するプラグインがあります。
Reduxのアクションと状態のログに加えて、LogRocketはコンソールログ、JavaScriptエラー、スタックトレース、ヘッダー+本文、ブラウザメタデータ、カスタムログを含むネットワーク要求/応答を記録します。 また、DOMを計測してページ上のHTMLとCSSを記録し、最も複雑な単一ページのアプリでもピクセル完璧なビデオを再作成します。
無料で試してみてください。