無限スクロールで、スクロールバーはまだ意味がありますか？
今日、Google Plusでこれに気づきました：
Google+ギャラリーの仮想スクロールバー
これは仮想スクロールバーであり、ネイティブスクロールバーとは異なり、WindowsまたはLion以前のOS Xの誰もが知っています。
これが無限スクロールコンテキストのスクロールバーになりました。つまり、実際のドキュメント（ギャラリー）ははるかに長くなり、約3000の画像が含まれます。
しかし、スクロールバーはネイティブスクロールバーのように動作します。その全長は、クライアントにダウンロードされたの時間ではなく、実際のドキュメントは、マウスポインタでドラッグできる最小サイズに達するまで、ドキュメントのより多くの部分がダウンロードされるにつれてスクロール自体が小さくなります。
私はここでライオンに「いいえ」と言った最後の人の一人だと思います。おそらく、スマートフォンからデスクトップインターフェースに至るまで、これらすべてのトリッキーなスクロールバーにだれもが慣れているので、おそらく最後のスクロールバーユーザーの1人です。全世界に。
それでも、それは私に質問をもたらします：スクロールバーはまだ便利です、特に無限スクロール/大きなデータで？
元のスクロールバーの概念は単純でした。ドキュメントがあり、その一部しか表示していません。
従来のスクロールバーでは、スクロールにより、全体と比較した表示部分のサイズと、最初から求めた距離がわかります
しかし、無限スクロールの登場により、次のようになりました。
無限のスクロール状況では、スクロールバーはドキュメントのサイズと直接関係ありません
したがって、ドキュメントのダウンロードされた部分が表示されます。これはネイティブスクロールバーの技術的な制限かもしれませんが、ここでは仮想スクロールバーについて話しています：これは実際に手作業でプログラムされ、おそらくUX設計です。
歴史的に、ワードプロセッサ（すみません、Wordなど）はドキュメント全体をロードしませんでした。むしろ、ロードするすべてのオブジェクトの幾何学的なサイズを格納し、それらを追加して、スクロールバーを作成し、閲覧済み、またはすでに閲覧済み。 （*）
したがって、私の主な質問は次のとおりです2012年にスクロールバーが必要な場合、それがどのように表示されるか（フォールバックを含む）、ない場合は代わりに何が表示されるか？なぜ、なぜ表示されないのか？
私たちのコンテキストは消費者コミュニティサイトなので、フォトギャラリーやニュースフィード（「あなたの友人」と呼ぶものは何でも[〜＃〜] xy [〜＃〜]がしました何か私たちのサイトのページ "）、対象ユーザー30 + -5、スマートフォンを所持しているが、特定のタスクにデスクトップコンピューターを使用している。
（*）（これに関する技術的な履歴については、Gang of FourからDesign Patternsをお読みください：これは「プロキシ」と呼ばれますパターン
更新：明確にするために：説明、パターン、ワイヤーフレームを確認したい。 「依存する」は答えではありません。もちろん依存します！それは何に依存し、「たとえばXの場合」、何を推奨しますが、「Yの場合」、何を推奨しますか、例、アイデア、モックアップ。
今日は無限スクロールが豊富で、スクロールバーは80年代頃からここにあります（おそらくXerox Starパターンでしょう）。しかし、私はそれらの現在の組み合わせは無意味でナンセンスだと感じています。私たちが独自のスクロールバーを実装する計算能力を持っているとすると、その仮想スクロールバーは無限スクロールのように見えるはずですか？どうして？
（50の賞金と15の賛成投票があっても、他に選択肢はありませんか？）
だから、いくつかの選択肢。
無限スクロールを維持しながら「実際の」スクロールバーをエミュレートする
エミュレーション指向のアプローチは、通常のスクロールバーを復元しながら、無限のスクロールを提供します。コンテンツが実際に妥当な終わりを持っている場合、は役に立ちます。
上記の例のような画像ギャラリーはそのようなものですが、反例は9gagの「Vote」セクションになります-それは決定的な終わりがないと確信しています...
行指向のアプローチ
まず、上記のG +の解は悪いです。限られたメタデータからページの合計サイズを簡単に計算できます。必要なもの：
- ウィンドウの幅と高さ
- 1つの画像の高さ（定数）
- 表示されるすべての画像の幅（480、480、640、480などの一連の数値）、一般的な場合、この特別な場合の行数（正当化されていることに気付きましたか？）
- 表示している一番上の行のインデックス
1つの行の高さがわかっていれば、簡単です。
基本的に、スクロールバーの「物理的な長さ」は次のとおりです。
height of one image * number of rows
ただし、その表示はウィンドウの高さと同じです。したがって、1行の画像は次のように表されます。
single row = height of window / number of rows
巻物はどれくらいを表しますか？表示される行の数によって異なります。
nr of rows on the screen = height of window / height of one image
したがって、スクロールのサイズは次のとおりです。
scroll size = single row * nr of rows on the screen =
(height of window)^2 / (height of one image * number of rows)
スクロールのオフセットのサイズは常に：
scroll offset = (index of topmost row / nr of rows) * window height
それは少し数学ですが、あなたはそれで生きることができます
ユーザーが（スクロールをつかんで）下にスクロールするたびに、これを逆に適用することで、ロードを開始する行を計算できます。
index of topmost row to load = (scroll offset/ window height) * nr of rows
この単純な数学を使用することで、ワードプロセッサーのように振る舞い、手元に完全なスクロールバーができあがります。
ページ指向のアプローチ
行がわからない場合でも、おそらくトリックがあります。同じ高さの情報を常に1つのページに読み込むことができます。 Web上のページは多かれ少なかれ任意であり、通常は20の要素を含みますが、ユーザーが気付かないうちに1つまたは2つの要素によってオフセットされる可能性があります。
基本的な計算は同じです（行をページで置き換えます）、ただし、グリッド指向のページデザインとアプリケーションの一部が必要ですこのグリッドを認識する必要があります。また、バックエンドでカウントできるように、独自の平均文字/行を計算する必要があります。
したがって、バックエンドはこのような計算を行う可能性があります。
article size = headline (const.) + sum of margins (const.) +
height of text + sum height of images
height of text ~ length of text (in characters) / average characters in a line
たとえば、理想的なサイズに近いものに基づいて、20 + -5結果を提供します。
もちろん、レイアウトが変更されるたびに、このメソッドは機能しなくなります。
Pager-scrollbar
これらすべてを計算したくない場合でも、「デジタル」スクロールバーを使用できます。このようなスクロールバーは、実際には垂直のページインジケーターです。それでも、ユーザーはより大きなコンテキスト（ドキュメント全体）の中で自分自身を方向付けるのに役立ちますが、実際の画面領域については忘れてしまいます。 「デジタル」で移動します。つまり、ドラッグすると、次のページに「スナップ」します。
それは内部の「ページ内」スクロールでサイドインプリメントできます。そのようにして、ユーザーはアプリケーション全体のより大きなコンテキストと現在表示されているページのローカルコンテキストの両方でをナビゲートできます。
pager-scrollbarのscroll-within-scrollソリューションを使用すると、ユーザーはWebサイトのより大きなコンテキストとロードされたページのローカルコンテキストの両方ですばやくナビゲートできます。
これは実際にはかなり簡単に実装できます。通常のページャーを実装し、少し異なる方法で視覚化します。次に、サーバーから新しいページをダウンロードするときに、単一のdivにロードします。 jQueryは、divの大きさをすばやく通知するので、
size of outer scroll = height of window / nr of pages
offset of outer scroll = page number
size of inner scroll = height of window / height of current page
offset from top of webpage - (sum of height of loaded pages -1)
offset of inner scroll = _______________________________________________________________
height of current page
無限スクロールが設定されていることをユーザーに視覚的に示す
データが長すぎて意味のあるスクロールバーを作成できない場合や、実際の計算を処理したくない場合があります。それでも、このサイトにオープンエンドのページがあることを視覚的な手掛かりで示す必要があると思います。
良い例はtumblrです。1人のtumblr-userが無制限の量のデータを収集するのに十分な速さではありませんが、データは十分に長いです。
この場合、他の種類のナビゲーションも必要であることを理解してください。タイムラインベースのソリューション（日数などに基づくページ）でも可能です。
「春」モデル
無限スクロールには常に"スクロール依存領域"があります：スクロール依存領域が表示されるようになると（通常、画面に表示されるデータよりも少ない場合）、アプリケーションは次のページのロードを開始します。
実際、この領域を視覚化することができます。下部にこの領域がないスクロールバーは「通常の」スクロールバーですが、無限スクロールスクロールバーはスクロールバーです。
良い比喩は春です：底に春があり、マウスホイールが重力のような力であると想像してください。スプリングを押すと、最初に圧縮されますが、次に拡張しようとします。これがピンボールランチャーの動作方法です。
ピンボールランチャースプリングは、スクロールの影響を受けやすい領域のよいメタファーになる可能性があります
私たちの場合、力が非常に大きいため、ジャンプ後にスクロールが実際に小さくなります。これは完全に未知の現象ではありません。ジェット戦闘機のコックピットからイジェクトすると、数センチ短くなります。私たちの春は本当に強いです:-)
このロジックは実際にはかなりうまくいくかもしれませんが、テストする必要があります。
ぼやけたスクロール
単一の単純なメタファーを表す精巧なアニメーションが必要ない場合は、簡単な方法をとることができます。ユーザーに伝えなければならない情報は、それがどこで終わるかまだわからないということです。 「霧」があり、道の終わりが見えません。
一種の「フォグ」はドキュメントの終わりを隠します。ぼかしやグラデーションを使用して、無限を表すことができます
本当に無限のデータ
データは「本当に」無限になり得ます。私は2007年頃からFacebookを使用しています。ニュースフィードを2007年まで下にスクロールした場合（それが不可能であることはわかっていますが、約10ページで停止します）、それは巨大です。
または 9gag （仕事をしているのではない場合）に移動し、[トレンド]または[投票]をクリックします。そのデータは「真に」無限であり、2005年頃から毎日何千もの画像を処理しているという意味です。
また、下にスクロールすると、「トップ」に新しい情報が表示される場合があります。 9gagの画像は継続的に投稿されますが、これはFacebookにも適用されます。下向きにブラウジングしているときに、新しいニュースが表示される場合があります。
これらの場合、スクロールバーは意味がありません：データの明確な開始も、明確な終了もありません。あなたは無限の情報の流れを見ています。いくつかの要素に戻ることが重要な場合もありますが、ストリーム自体は双方向に無限であるため、情報内の進行状況を把握することはできません。
また、無限スクロールはブラウザに害を及ぼします：ブラウザは、すでにダウンロードしたデータを「忘れる」ように設計されていません。したがって、ブラウザはあなたの記憶を食べ始めます。
それはかなり速くなくなるので、いわゆるスワッピングを実行する必要があります（メモリの未使用部分をハードドライブに書き込み、それがメモリの一部であるように見せかけます）。SSDハードドライブがない場合は、システムの速度を低下させます-SSDハードドライブがある場合、その寿命は文字通り数年短くなります。
今回はどうですか？
- 私が見ている投稿
- 私が立っているページ
- 私が今日見た最後の40-50の投稿について覚えているかもしれません
- 移動を開始してから投稿された新しいアイテムの数/開始したページ。
- 私が時系列にいるところ
- 私が始めた場所と比較される場所
- いくつのページ/アイテムを踏んだか。
また、重要なのはリンク可能性です。無限のスクロールの最中にページ全体を実際にリンクできないのはかなりイライラしますよね？
したがって、スクロールバーを手掛かりに置き換えることができます。
シンプルなアイテムナビゲーター
最も単純なケースは、「ページ」（高速ナビゲーション用）と「アイテム」を区別し、スクロールバーを非表示にする場合です。
ユーザーがスクロールを使用するたびに、アイテムナビゲーターの色を別の色に変更（または点滅）して、機能していることを示します。
ページの下部に「フォグ」（ぼかしまたは単純なグラデーション）を使用して、ドキュメントの最後ではないことを示す場合があります。
シングルページスクロール
これらに加えて、現在表示されているページのみのスクロールバーを常に持つことができます。以前のページはどうなりますか？私たちはそれらを非表示にします。メモリからそれらを削除するのではなく（おそらくそれが解決策でもあります）、現在のオフセットに基づいて常に表示することができます。オフセットがゼロに達した場合、次のページの最後にいます。
このメソッドは、実際にはOS Xプレビューがページを処理する方法をモデルにしています。
バッファ領域も必要です。現在のページの最後を表示している間、現在のページの最初はすでに表示されています。
このバッファーの大きさはどれくらいですか？ちょうど1画面の高さ！
この限られたスペースに新しいコンテンツをロードして、表示できるようにします。画面の上部に到達するたびに、ページを入れ替えます。
（全体を見る ここ ）
最終的な考え
これらは、回答の対象になる可能性があると私が考えたソリューションの一部でした。
私はこれらのいずれかを受け入れたでしょう、そしてこれらに似たすべての答えを賞金として（今後23時間以内に）受け入れます。
人形の赤ちゃんは正しい無限スクロールについて話すときはいつでも追加のナビゲーションが必要である一方で、私はのように賞金を受け取る資格があるとはまだ感じていませんスクロールバーに関しては、彼女は今でも現状維持することを推奨しました。
創造性は現状維持にとどまるべきではないと思います。フォードがかつて言ったように、「人々が何を望んでいるか尋ねるなら、彼らは言ったでしょう：より速い馬」
これらのソリューションのいくつかは非常に数学的なものです。私は誰もがそれらを理解することを期待していませんし、実装するのが難しいことは確かですが、私はそれらの価値を期待しています。
簡単な実装については、blurry endが最も簡単です。
ただし、これらは実装されておらず、ユーザーテストも行われていません。それらのほとんどは、実際のニーズにも依存すると思います。私はそれらがどこに役立つのかについていくつかのコンテキストを提供しようとしました。いつか誰かがそれらを実装し、テストして、結果を報告してくれることを願っています。
これらの例があなたの想像力を育む場合、あなたはまだ賞金の対象となる可能性があります。ここにない例を提供してください。
コンテンツのリストがある場合、スクロールバーは必須です。ユーザーは、ロードされたコンテンツの最後までスクロールすること、そしてTwitterやFacebookなどのプラットフォームを使用してコンテンツがさらにロードされた後、さらにスクロールできることを理解するように教えられています。スクロールバーは、Webアプリケーション上ではリストの長さのインジケーターとは必ずしも見なされなくなりました。
スクロールバーは、ユーザーが項目の拡張リストを表示できるようにする認識されている要素です。極端に大きなリストの場合、リストのはるか下にある項目に到達しようとすると、大量のスクロールが必要になるため、スクロールバーだけを使用するのは難しい場合があります。
非常に大きなリストの場合は、追加のメタスクロールをユーザーに提供して、リストの特定の部分にジャンプし、スクロールを使用してそのポイントにローカルなアイテムを表示できるようにする必要があります。
これが機能する例として、facebookのタイムラインがあります。facebookには「無限」のスクロールがありますが、ユーザーは特定の期間にジャンプできます。
質問への回答の明確化：
「2012年にスクロールバーが必要な場合、ある場合はどのように見えるか（フォールバックを含む）、ない場合は代わりに何が必要ですか？なぜ、そうでないのですか？」
私の答えは「はい、必要です。認識された機能であるため変更しないでください。認識された機能を変更すると、使いやすさが損なわれます。無限スクロールの場合は、ユーザーのニーズに応じて「メタスクロール」機能を実装する必要があります。さらなる正当化以下
スクロールバーは、大量のコンテンツを閲覧するための確立された方法です。それらを削除することは無責任で無謀です。動作が異なるか、見た目があまりにも違って認識できないように変更することも、無責任で無謀です。 Googleのjscriptスクロールバーは、通常のスクロールバーと同じように見え、動作も同じなので問題ありません。
あなたが話しているコンテキスト（つまりソーシャル）内の無限スクロールのパターンはすでに確立されています-ユーザーは読み込まれたコンテンツの一番下までブラウジングし、さらに読み込むのを待ちます。ユーザーには学習済みこのパターンとそれ使いやすさを妨げないがあります。
ユーザーは通常、ローカルおよび最新のコンテンツを見たいだけなので、これはユーザーのニーズに適しています。特定の何かを探しているわけではありません。また、3000枚すべての写真を表示する必要もありません。
唯一の例外は、過去のある期間に固有のローカルコンテンツを表示したい場合です。これにより、無限スクロールが困難になります。これが、ユーザーのタイムライン内の特定の期間にジャンプできるFacebookの機能など、メタスクロールが役立つ理由です。 **これは、ユーザーがコンテンツの大規模なセット内のさまざまな場所に「ジャンプ」できるようにするコンテンツ領域内のリンクのセットです。
ユーザーがカテゴリ、日付、タグなどのメタデータに基づいて特定のコンテンツを検索したい場合は、フィルターオプション、並べ替えオプション、または検索オプションを指定できます。 これらの機能の使用は、コンテンツとユーザーによって異なります。たとえば、fickrの場合はこれを指定しますが、g +の場合は指定しません。どちらも質問のコンテキストに適合します。
このコンテンツを閲覧する新しい方法を作成することは、ユーザーが使用方法を学ぶ必要がある新しいインターフェースを意味するでしょう。 これは絶対に避けてください。既存のメンタルモデルを利用して、直感的な機能を作成します。確立された機能を使用します。
標準のスクロールバーは、すでにダウンロードされているコンテンツをスクロールするという最も一般的なユーザータスクを満たしていると思います。
ユーザーがリストをはるかに下にスクロールしたい場合（、Facebookの場合、さらに前に戻る）、標準のように機能するスクロールバーを想像できます。スクロールバー。ただし、スクロールするコンテンツを示すために上下に移動できる開始および停止の「範囲バグ」が追加されています。
以下のモックアップは、長期間にわたって編成されたコンテンツを表示しているページの例を示しています（これもFacebookと同様です）。これは、名前、番号、またはその他の便利なカテゴリで編成されたコンテンツでも機能します。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
このデザインの重要な側面は、ページの「ダウンロードオンデマンド」側面を維持することです。もちろん、3年間のコンテンツを一度にダウンロードしようとすると、ユーザーは長い間待たされることになります。したがって、ページはほとんど空白である必要があり、コンテンツは、そのコンテンツが移動するページの部分が明らかになったときにのみ入力する必要があります。このプロセスが高速になるほど、UXはシームレスになりますが、それは帯域幅、サーバーとクエリのパフォーマンス、データベースのインデックス作成などに依存します。
Sausage.js は、スクロールバーに関連する無限スクロールのユーザビリティの問題を解決できる興味深いパターンを提供します。 「pager-scrollbar」の例に似ています-それは、そのセクションにリンクするページの各セクションに対して「ソーセージ」を作成します。通常のスクロールバーはまだ残っています。
無限のスクロールページの場合、ページセクションを表すソーセージの代わりに、コンテンツの新しいバッチが入れられるたびにソーセージが作成されます。これは増え続ける「ページ」のすべてのセクションにすばやくアクセスできます。
スクロールバーと一緒にソーセージを表示するには、 デモを体験する する必要があります。
これは「スクロールバーはまだ意味があるか」という質問には答えませんが、無限スクロールのコンテキストで意味のある代替手段を提供します。通常のスクロールバーは、ピンボールレバーの例のように引き続き機能する可能性があります-私たちはまだWebブラウザーにいるので、それを取り除くことが賢明であるかどうか確信が持てません。
スクロールバーが表示されているのは理にかなっていると思います。ユーザーは、見たコンテンツとオンデマンドでダウンロードされたコンテンツの間のどこにいるかがわかるからです。
コンテンツが無限であっても、スクロールバーを使用して、ユーザーが上または中央に移動したり、見たコンテンツを探すことができます。
はい、スクロールバーはまだ便利です。しかし今、スクロールバーにはより多くの機能が必要です。スクロールバーにはマーカーインジケーターが必要です。私はここで高度なスクロールバーの私の理解を説明しました： https://ux.stackexchange.com/a/25127/17466