スクロールバーは2020年に機能しなくなっていますか？
最近、デザイナーが最近のWebデザインではビジュアルスクロールバーを使用しない、または少なくともスクロール時にのみ表示されるという効果について何かを言うのを聞きました。私はフロントエンドの開発者であり、実際にはこれを聞いていませんでした。これに真実はありますか？特に私の質問は：
Webアプリの場合、コンテンツがスクロール可能な場合：
- 目に見えるスクロールバーがあるべきですか（そしてその理由）？
- スクロールバーが表示されないようにする必要がありますか（なぜ表示されないのですか）。
はい、あります。
表示されるスクロールバーは、「このページはスクロール可能です」というアフォーダンスです。
このような視覚的なヒントがないと、機能が失われる可能性があります。
いくつかの最新のデザインガイドラインでは、永続的に表示されるスクロールバーを推奨しますが、すべてではありません。たとえば、 Material Design guide では、メニューの場合、メニューがスクロール可能な場合、スクロールバーが表示されます。いずれにせよ、コンテンツがスクロール可能である場合、スクロールできることはコンテンツを見ると明らかです。
そのアフォーダンスが、スクロールできる程度を示すスクロールバー（従来）、「もっと読む」リンク、または画面を指す矢印（最新の多くのアプリのホームページやブログなど）によって明確に示されるかどうかは、個々のデザイナーまたはガイドライン次第です。 ）、またはコンテンツ領域の端に近づくにつれてフェードアウトします。つまり、その方向に移動して、よりはっきりと見ることができますが、アフォーダンス自体が必要なコンポーネントです。スクロール可能なコンテンツを提示するが、そのスクロール可能性をユーザーに示さないことは、設計としては不十分です。ユーザーを失望させたり、重要な情報や行動を促すフレーズを見逃したりする可能性があります。
マウスユーザーとして、スクロールバーの表示とアクセスを許可しないスクロール可能なコンテンツを嫌います。
スクロールバーはコントロールです。それは私が大きなページを素早くナビゲートすることを可能にします。また、スクロールホイールよりもほとんどのページで精度が高くなります。
スクロールバーに情報が表示されます。これにより、ページのコンテンツを読み取るのにかかる時間（ハンドル：ガター比が画面：ページ比と等しい適切なスクロールバーを想定している）をすばやく決定し、ページをどのくらい進んだかがわかります。また、すばやく上にスクロールして下に戻る場合に、ページのどこにいるかを判断するためのインデックスも提供します。
スクロールバーが占めるスペースはわずかです。現在、画面は1920 x 1080 = 2.1 Mpxです。このページが含まれているFirefoxウィンドウは1125 x 905 = 1.0 Mpxです。スクロールバーは16 x 816で、合計で13 Kpx、つまり画面の1.3％を占めています。私のモニターはゲーム用に使用しているので、かなり近くにあります。ウィンドウをモニターよりも狭くする傾向があるので、スクロールバーは実質的にスペースをまったく占有しません。
コンテンツがスクロール可能かどうかさえわからない場合がありますが、バーを確認することなくホイールでスクロールしようとする傾向があるので、これはWebページにとって大きな問題ではないかと思います。通常はスクロールしないデスクトップアプリケーションの場合は、さらに大きな問題になります。
非表示のスクロールバーが必要な場合は、手動でスクロールしたとき（マウスホイール、キーボードのキー、トラックパッドなどを使用）、およびマウスを画面の右端に向かって移動したときに表示されます。
特に使用するのに十分な大きさの場合、スクロールバーがそのような大量のスペースを占めるため、モバイルデバイスは扱いにくいです。
A.通常、私はデスクトップビューに切り替えることで問題を解決します（モバイルバージョンがデスクトップバージョンより優れていることは言うまでもなく、デスクトップバージョンよりも優れているWebサイトをまだ見ていません。したがって、とにかくデフォルトでデスクトップビューに設定します）。次に、ズームアウトしてから下にスクロールしてからズームインします。スクロール、スクロール、ズームイン中にスクロールするよりも高速で正確で、グラブ可能なスクロールバーは必要ありません。 （また、画像や図などをよりよく表示するためにズームインすることもできます。ほとんどのモバイルサイトでは、不可解に許可されていません。）
B. Android上のFirefoxには、デフォルトの「インターネット」と同様に、アクセスしているスクロールバーがあり、私がページのどの部分（サイトのデスクトップバージョンとモバイルバージョンの両方）か）を教えてくれます。 "ブラウザ。インデックスを付けたり、ページの長さを決定したりするために、マウスを使ってデスクトップブラウザで使用するのと同じように使用します。
C.また、適切なモニターで大きなWebページのみを表示する傾向があるため、モバイルデバイスで900ページの.pdfなどをスクロールしようとしている可能性ははるかに低くなります。 Webアプリが2画面または3画面を超えない場合、スクロールはそれほど問題にはなりません。
D.タッチスクリーンでの指のスクロールは通常、マウスホイールを使用するよりも速くて正確であるため、すばやく移動するのが困難になる前にページを大きくする必要があることにも注意してください。
結論
マウス（またはトラックパッドやトラックボール）の設定では、スクロールバーは常に表示され、グラブ可能である必要があると思います。少なくとも、スクロールするとき、またはスクロールバーの近くでマウスを動かすときに表示されます。
モバイルタッチスクリーンセットアップの場合、スクロールバーはスクロール時に常に表示されている必要があると思いますが、取得可能である必要はなく、スクロールしていないときは非表示にして無駄なスペースを減らす必要があります。
私はタブレット/ iPadまたはそれ以上のタッチスクリーンに手を出していないので、私はそれらについてどう思うかわかりません。
もちろん、（ユーザーがゲストであるかアカウントを持っているかに応じて、一時的なCookieまたは保存されたユーザー設定のいずれかを介して）視覚スタイルを変更するオプションを持つことは最善の策ですが、デフォルトで機能的なものにする必要があります。
この視点は主にMac環境に由来し、コンテンツが最初に表示されたときにスクロールバーが通常は短時間表示され、その後フェードアウトします。スクロールが発生すると（ユーザーがトリガーしたかどうかに関係なく）、スクロールバーが再表示されます。ハンドルのみが表示されます（半透明の丸い黒いバーとして）。矢印やガターはありません。カーソルが表示されたときにスクロールバーの上にある場合、カーソルは幅が広くなり、カーソルでドラッグできるようになります。コンテンツのサイズが変わることはありません。スクロールバーが存在しないかのように動作し、スクロールバーが上にレンダリングされます。
これは、トラックパッドまたはトラックパッドのような入力メカニズム（ラップトップなど）を使用する場合に適用されます。通常のスクロールバーは、マウスを使用する場合でもデフォルトで表示されます。
もちろん、これはモバイルにも当てはまります。 iOSはほぼ同じ動作を使用します（カーソル操作を除く）。実際、私はそれがiOSで始まり（スクロールバーが小さすぎて確実にタップできない）、macOSに移行したと思います。
全体として、これには長所と短所があります。
- スクロールバー用のスペースを作成する必要がないため、ページのデザインが簡素化され（煩わしい要素が少なく）、特に複数の場所でスクロールできる場合は、コンテンツ用のスペースを増やすことができます。
- Macのユーザーはこの動作に慣れており、期待しています。
領域が突然スクロール可能になったときにコンテンツサイズが急激に変化することはありません。これにより、スクロールバーが表示されている限り必要であり、非表示の場合（テキストの折り返しなど）は必要ないという一般的な曖昧さが修正されます。
マイナスの面では、すでに述べたように、コンテンツがスクロール可能であることを示す別の方法を考え出す必要があります。これはいずれにしても予想されるため、Webページのメイン部分ではそのような問題ではありませんが、ユーザーの期待によっては内部コンテンツの問題である可能性があります。最初のフラッシュは役立ちますが、常に十分であるとは限りません。
- ドキュメント内の別の場所にジャンプするためのユーザー操作は不格好です。ユーザーは、スクロールバーが表示される場所にカーソルを移動し、マウスホイールまたは「2本指のスクロール」で少しスクロールし、スクロールバーが表示されたらそれをつかんで、目的の場所にドラッグします。運動量のスクロールは、これを回避するのに役立つ場合があります。
- スクロールバーは透明な背景上に表示されるため、背景が暗いと見づらくなる場合があります。 macOSは、この場合に使用できる白い代替スクロールバーを提供します（背景が十分に暗い場合、ブラウザーは自動的にこれに切り替わると思いますが、100％確実ではありません）。また、それはバーにほんの少しだけ十分なフェイルセーフとしての微妙な輝き（または影）を与えます。
もちろん、可能であれば、この種のものについてはブラウザネイティブのコンポーネントを使用してください。彼らは、各ユーザーが自分のプラットフォームで自然な体験を確実に得られるようにします（多くのWebサイトが勢いのあるスクロールと伸縮性のあるスクロールを残酷な最終結果で再現しようとしているのを見てきました）。 Macユーザーは、スクロールバーを予期しない場所に強制的に表示することについては感謝せず、Windowsユーザーは、スクロールバーを予期するところを非表示にすることについては感謝しません。
私の見解では、スクロールバーの削除は、機能よりもスタイルを優先するというばかげた浅いイデオロギーのもう1つの例です。これは、本来あるべき姿に正面を向いており、私にとって社会の沈黙を示しています。スクロールバーは、他の代替方法では常に再現できない重要な機能上の目的を果たします。この変更は、一部は人々がタッチスクリーンを使用するという概念に基づいていると思います。したがって、それは必要ではありませんが、多くの人々はまだ使用していません。多くの代替方法では、操作に余分な集中力と巧妙さが必要です。これは、悪いユーザーインターフェイスとの戦いではなく、仕事に費やしたいエネルギーの浪費です。従来のスクロール方法は、通常、下矢印キーを押すことによるキーボードスクロールと一緒に行われます。これは、集中力を必要とする他の方法よりもはるかに簡単ですが、スクロールバーが削除されているため、キーボードの矢印スクロールも消えて、大きな問題になるはずです。 -番号！例として、Big Fソーシャルネットワークは、メッセージの履歴を上にスクロールしている間、「動的」なスクロールスタイルでイライラを引き起こし続け、上にスクロールしているときに会話のどこにいるのかわからないが、次にスクロールして、ある時点で、突然余分な会話履歴が読み込まれ、最終的には希望した場所のはるか先にジャンプしてしまいます。
これは、一部は無知であり、一部はサーバーのリソースと帯域幅を節約して、ユーザーエクスペリエンスを犠牲にして企業の費用を節約したいという欲求でもあると思います。それはまた、馬鹿が物事を「簡単」にして非常に基本的なコマンドに使用できるようにすることで、物事を沈黙させることでもあります。ブロックチェーンがユーザーエクスペリエンスを犠牲にしてお金を節約するこの時代の終わりを告げることを願っています。システムが迅速に動作し、基本ユーザーと上級ユーザーの両方にとって手間がかからないようにすることができます。
たとえば、SkypeやFメッセンジャーなどのソフトウェアを使用して、セクションが読み込まれるのを永遠に待つのではなく、メッセージ履歴の最初まですぐにスクロールできたら、すばらしいと思いませんか。ロット全体を一度にロードするリソースを節約することだといつも思っていました。しかし、少し知性と微妙な考えを持つ誰かがこれを設計している場合（ブロックチェーンのサークルでは、私が望む企業よりも一般的です）、全員がケーキを手に入れて食べることができます。リソースを節約でき（ブロックチェーンでも簡単なことではありません）、ページ読み込みシステムによってこの恐ろしいページに我慢する必要なく、必要な情報を即座に取得できます。
タイムライン履歴全体のフレームワークをスクロールバーにレイアウトし、スクロールするとポップアップする日付を表示します。マウスボタンまたはStropスクロールを放すとすぐに、その特定のセクションが読み込まれます。最初からやり直したい場合は、一番上まで右にスクロールすると、最初のページだけを読み込む必要があります。たとえば、キーワードを検索するなど、すべてをすぐに読み込む必要がある場合は、必要に応じて押すことができる単純なボタンを提供するだけで、メッセージの履歴全体またはスクロールしたものの履歴を取得できます。
誰かがすべてをロードする必要があることを明確に示す場合、ブロックチェーンはリソースに対応する必要があります。これは、それと古いモデルの企業との違いです。私は、特にすべてをロードする必要があるものでさえ、そうすることで、不潔な利益の動機のためにリソースを保護し、ユーザーをねじ込むことができるようにするのを嫌がるのではないかと思います。これがブロックチェーン、そしてできればオープンバージョンが必要な理由です。
混合視点として...
水平スクロールバーは通常悪いことです。 PCモニターの画面幅に合わせて最適化されている可能性がありますが、モバイルデバイスにはうまく対応できません。下にスクロールするとき、ページ全体を読むには、コンテンツの各画面にたくさんの左右のスクロールが必要です。そして逆に、それらのサイトは大きな画面でスペースを無駄にしてしまいます。 （年配の読者は、「1024x768で最高の表示」と言っているWebサイトを覚えていますか？ええ、そうです。）2019年はこれに我慢する必要はありません。これは1990年代ではなく、まだNetscape Navigatorを使用していません。そこに行かないでください。
一方、垂直スクロールバーは問題ありません。私たちは直感的に何かを下にスクロールすることに慣れています-たとえば、新聞紙をどのように読んだかを考えてみてください。上/下にスクロールするだけで、ページ全体を簡単に表示できます。
ただし、2つまたは3つ以上の画面のコンテンツで構成するのは多すぎると考える学校もあります。その後、ものを見つけるのは難しくなります。したがって、スクロールバーが機能している間、無制限の長さのページに移動させないでください。
はい、アクセシビリティを確保する以外の理由がない場合は、スクロールバーを表示する必要があります。
スクロールバーを非表示にすると、サイトやプログラムがイライラして境界線が使用できなくなる場合が多くあります。
- 支援ハードウェア/ソフトウェアを使用してページにアクセスする
- スクロールホイールのないマウスを使用する
- スクロールイベントを通過しないリモートデスクトップシステムの使用
- マルチフィンガージェスチャーを使用してスクロールするタッチパッドを使用する（ほとんどの平均的なユーザーは、それらが存在することを知りません）
- タッチスクリーンを使用すると、ページの高さが数画面を超えるため、ページの反対側のどこかにスクロールする必要があります
- タッチスクリーンを使用して、リンク/ボタンでいっぱいのページをスクロールする（タップアンドフリックモーションが誤って何かを誤ってアクティブにする可能性が高い場合）
表示されるスクロールバーは、これらの問題をすべて回避する簡単な方法です。同僚の主な主張が他のサイトで行われている場合は、彼の話を聞いてはいけません。ピアプレッシャーは、有意義で有意義な理由を伴わない限り有効な議論ではありませんwhyそれを行うのは良い考えです。そのような考え方は、<blink>タグが人気になりました。
また、アクセシビリティのために、独自のスクロールバーを実装しないでください。システムが提供するものを使用してください。支援技術は、自家製のスクロールバーを常に識別して操作できるとは限りません。
スクロールバーは非常に便利です
- ページがスクロール可能であることをユーザーに示します
- ユーザーが現在スクロール可能なページにいる場所を示します
スクロールバーを削除するのは良い考えだと考える不機嫌なデザイナーがいたので、私が何回腹を立てて迷子になったかはわかりません。
MichaelSの答えに追加するには、
タブレットやiPadでは、スクロールできないときに非表示になる非取得可能なスクロールバーが推奨されます。彼が言ったように、タッチデバイスでのスクロールははるかに正確であり、目に見える、つかみやすいスクロールバーは不格好で煩わしいものです。ただし、ページの長さによっては、[トップに戻る]ボタンを使用できます。
また、12.9インチのiPad proを使用してStackExchangeでこれを書いているときに、リンクを誤って開かずにスクロールできるため、まともな（〜1cm）のパディングを少し異なるトーンで追加すると便利であることに気付きました。
興味深い質問です。私の2cは開発者から来ていますが、UXのリーダーであり、いくつかの内部スクロール可能領域を持つインターフェースも設計しています。
いくつかのポイント：
- スクロールバーの存在はコンテンツをスクロールできることを示し、提供するため、コンテンツがスクロールを必要とするのに十分な大きさである場合、可視スクロールバーが存在する必要があります。
- 特にトラックバーをクリックしてドラッグしている場合（接線上）、無限スクロールは私の個人的な考えです。
- コンテンツをスクロールできない場合、スクロールバーは、起こり得ないことを示唆する反アフォーダンスです。
- Edgeケースとは、スクロールできないものですnowですが、コンテンツのサイズが大きくなる場合があります。これは、エディターや動的出力を備えたシステムでは一般的です。特に、スクロール機能を追加または削除すると、レイアウトが乱れる可能性があるため、コンテンツが拡張されてスクロールバーが表示されると、水平jankが表示されます。 （たとえば、
overflow: autoを使用する場合）。この場合、これはスクロール可能な領域であることを示す無効なスクロールバーを配置するeasierにすることができますが、コンテンツはまだこの動作を有効にするのに十分な大きさではありません。
- Edgeケースとは、スクロールできないものですnowですが、コンテンツのサイズが大きくなる場合があります。これは、エディターや動的出力を備えたシステムでは一般的です。特に、スクロール機能を追加または削除すると、レイアウトが乱れる可能性があるため、コンテンツが拡張されてスクロールバーが表示されると、水平jankが表示されます。 （たとえば、
- 水平スクロールバーは、それが導入する暗黙のモード選択と垂直スクロールバーを組み合わせる場合、通常は悪い考えです。のように、マウススクロールのデフォルトは通常垂直スクロールですが、暗黙の追加キープレス（またはトラックパッド操作）で水平スクロールを実現できます。これが複雑になることはほとんどありません。
- 一部のアプリケーションインターフェイス（Slippyマップなど）では、コンテンツがそのパラダイムでブラウザーウィンドウの下に移動するので、すべてのスクロールバーを削除することをお勧めします。コントロールは、ほとんどのユーザーによく理解されています。
- 多くの特定のカスタムバージョンが必要でない限り、スクロールバーのスタイルを設定することは99％の時間で素晴らしいアイデアではありません。
デザイナーは、スクロールバーをフローティングスクロールダウン/アップボタンに置き換えることについて話しているのですか？これはモバイルファーストのアプローチであり、特定の状況でうまく使用されているので、それは妥当だと思いますが、これらのボタンはグリッド内のスクロールバーを置き換えることはできません。