スクロールバーが問題になっている
(artemis.sh)- スクロールバーがますます小さくなったり隠されたりすることで、スクロールホイールやタッチジェスチャーを使いにくいユーザーだけでなく、文書内で素早く位置を移動したいユーザーにとっても、実際のユーザビリティ上の問題になっている
- 細かな運動制御が難しいユーザーや、アイトラッカーのように精度に制約のあるポインティングデバイスを使うユーザーにとって、幅8ピクセルのスクロールバーを狙うのは難しく、音声制御ユーザーも繰り返しスクロールする代わりに目的の位置を直接クリックしたいと考えている
- GTK、Qt、Firefox、Chrome、Electronでは、スクロールバーの幅や表示方法を調整できる場合でも、CSSの修正、
gsettings、about:config、テーマの再コンパイル、アプリごとの設定といった、一般ユーザーにはアクセスしにくい方法に依存している - 以前は押し続けると少しずつ移動するスクロールボタンがあったが、ひっそりと消えてしまった。矢印キーは一部の機能を代替できるものの、フォーカス状態によって動作が変わる
- 文書のミニマップのように、コンテンツを見ながら大きなクリック領域で移動できるUIは、アイトラッカーやタブレットペンのユーザーにも有用な代替的なナビゲーション方法になり得る
小さくなり、隠されるスクロールバー
- スクロールバーは、クリックしてドラッグすることでスクロール可能な領域内の現在位置を変える基本的なUIである
- 最近のスクロールバーは小さくなりすぎてスクリーンショットで示すことさえ難しく、さらに小さくしたり隠したりする流れがユーザビリティを損なっている
- 「スクロールホイールを使えばよい」という考え方は、すべてのユーザーがスクロールホイールやタッチスクリーンのスワイプを使えるという前提に立っている
- スクロールホイールをうまく使えるユーザーでも、ときには特定の位置へ素早くジャンプしたいことがある
アクセシビリティへの影響
- 細かな運動制御が難しいユーザーは、細いスクロールバーを正確につかむのが難しい
- アイトラッカーのようなポインティングデバイスは印象的ではあるが、幅8ピクセルのスクロールバーを安定して狙うには不十分である
- 音声や音でコンピューターを制御するユーザーは、Talon Voiceのようなツールを使っていても、
scroll downを繰り返したり自動スクロールを使ったりするより、スクロールバー上で目的の位置を見てクリックする方法を好む場合がある - 2015年にもGTK3のスクロールバー幅問題が議論されており、細いスクロールバーは非技術系ユーザーや、手の操作・視覚に問題を抱えるユーザーの負担になる
スクロールバーが使いにくくなった理由
- 場合によってはスクロールバーの幅はピクセル基準ではそのままだが、モニター解像度が高くなるにつれて、実際の操作対象はより小さくなっている
- 別の場合には、スクロールバー自体が実際により小さくなっている
- かつてUbuntuが試した非常に細いスクロールバーの事例にも言及されている
- スクロールバーが小さくなる一方で、押し続けると少しずつ移動するスクロールボタンも消えた
- 矢印キーが一部の機能を代替するが、現在どのコンテンツにフォーカスがあるかに依存する
- ボタンはフォーカス状態に関係なく使うことができた
- 全体としてスクロールバーは使いにくくなり、それを直すユーザー設定は存在しないか、一般ユーザーには見つけにくい技術スタックの中に埋もれている
GTK設定の壁
- GTK2では
gtkrcでスクロールバー幅を直接変更でき、それ用のGUIプログラムもあった - GTK3ではCSSで調整する必要があり、テーマを理解していなければ、ユーザーフレンドリーな設定方法は乏しい
- Redditのスレッドでは、GTK3・GTK4の
gtk.cssにslider { min-width: ...; min-height: ...; }を追加し、Flatpakのオーバーライドとoverlay scrolling設定まで処理するスクリプトが紹介されている - Flatpakアプリには別途オーバーライドが必要で、システムテーマがそのまま適用されない場合がある
- GTKはデフォルトでスクロールバーを隠し、その位置にマウスを乗せると表示する方式も使っている
- GTK3では次のコマンドで常に表示できる
gsettings set org.gnome.desktop.interface overlay-scrolling false - Dconf Editorでも見つけられるが、その場所を知っている必要がある
- GTK3では次のコマンドで常に表示できる
- GTK4ではこの設定をグローバルに指定できないというGNOME Bugzillaのスレッドが引用されている
- 議論では、アプリごとにnon-overlay scrollbarオプションを求めなければならない状況が問題になっている
Qt設定の壁
- Qtのスクロールバー幅は、使用しているQtウィジェットスタイルプラグインによって決まる
/u/cfeck_kdeはr/kdeでの回答で、サイズ設定を許可しているのはSkulptureスタイルだけだと認識しており、Breezeのような他のスタイルではC++ソースを変更して再コンパイルする必要があると説明している- Qtスタイルプラグインは実際のコードなので強力な制御が可能だが、望む設定を提供するプラグインを見つける必要がある
- Kvantumはスクロールバー幅の設定を見つけにくいが、「Transient scrollbars」というスクロールバーが消える機能はオフにできる
- Skulptureは試してみる価値があるが、KDE PlasmaなしでGUIから設定する方法は確認できなかった
- 1つのテーマエンジンに依存しなければならないなら、Qt開発が続く間それが維持されるのかという懸念が残る
Firefox、Chrome、Electronの状況
- Firefoxも非常に小さなスクロールバーを使っているが、現在は
about:configで調整できる- アドレスバーに
about:configを入力する widget.non-native-theme.scrollbar.size.overrideを希望する数値に変更するwidget.non-native-theme.scrollbar.styleを変更して見た目を変えられる- 値
4は太い長方形の形状に設定される - 通常の設定画面
about:preferencesで「Always show scrollbars」をオンにできる
- アドレスバーに
- 例としてFirefoxのスクロールバーサイズを
50に設定でき、実際にそこまで大きく使いたいわけではなくても、大きくできる点が利点である - Athena Lilith MartinのFirefoxスクロールバー追加設定の記事は、WebページのCSSオーバーライド無効化など追加の改善設定を扱っている
- Chromeには有用な設定を期待しにくいと評価されている
- Electronアプリも設定が難しく、カスタムCSSの注入で直せるかもしれないが、確実な解決策は示されていない
よりよいナビゲーション方法：ミニマップ
- ミニマップではコンテンツを見ることができ、コンテンツをクリックでき、クリックしたコンテンツの位置へ移動できる
- クリック対象が非常に大きいため、アイトラッカーユーザーやタブレットペンのユーザーにも有用である
- 一般的な「モダンなデザイン原則」が、スクロールバーや、多様な方法でコンピューターを使う人々に不利に働いている
1件のコメント
Hacker News のコメント
スクロールバーだけの問題ではありません。ウィンドウの枠線削除のせいで、背景と似た色のウィンドウと見分けもつかず、端をつかんでウィンドウサイズを調整するのもほぼ不可能になりました。
タイトルバーには検索ボックスや不要なボタンが大量に入り、ウィンドウを移動するためにつかめる場所がほとんどなく、テキストボックス間のタブ移動も期待どおりに動作しないか、まったくできません。
ツールチップはインターフェースの邪魔をして混乱させ、見たい内容を隠すことも多く、95%は重複しているか役に立たない情報です。
この10年で、カーゴカルト的な UI/UXが何十年も積み上げられてきたユーザビリティの原則を捨て、見た目だけはよく、多くの人にはまともに機能しない結果を生みました。
Postman、Teams、最近の Microsoft アプリの大半、Chrome、Insomnia のようなアプリは、デスクトップソフトウェアの UI をどう作ってはいけないかを示す事例として使うべきです。
さらに大きな罪は、こうした要素がウィンドウシステムのレベルで設定可能で、アプリ開発者が上書きできないようになっていれば問題ではなかったはずなのに、Windows と Gnome/GTK はむしろ既存のオプションをなくす方向に進んでいる点です。
「New Teams」を起動するたびに Old Teams に戻すか尋ねられ、ファイルエクスプローラーで New Teams から PDF を開くと、ファイルシステム上の場所を失わずに PDF を閉じる方法も明確ではありません。
しかもすべてが恐ろしく遅いです。Microsoft/Apple/Googleで働くかなり多くの人が自分の仕事をできておらず、それを恥じるべきです。
Windows については確実にそうで、それ以降のすべての Windows バージョンでユーザー体験は悪くなったと思います。
ユーザビリティが美学より重要だという点には根本的に同意しますが、「カーゴカルト的 UI/UX のバカ」が具体的に誰を指すのかは分かりません。
20年以上 UX/UI のリーダーとして働いてきた立場から言うと、ユーザビリティを壊す主犯はデザイナーよりもビジネスリーダーやマーケターであることが多かったです。
もちろん、形が機能より重要だと考えて小さなスクロールバーを押し通すデザイナーもいますが、問題を説明すれば引き下がり、使えるデザインを作る場合が多いです。
C レベル、マーケティングリーダー、マネージャーたちは UI に無知なのに意見は強いのでさらに危険で、「この Web サイトのスクロールバーがいい」「デザインがモダンに見えない」といった要求をします。
ユーザビリティとアクセシビリティを守るために戦うのは本当に苦痛で、一部の役職の人はもっとプロらしく振る舞い、専門家を信頼すべきです。デザイナーもユーザビリティを第一に考えるべきなのはそのとおりです。
設定メニューはリストの上にリストが積み重なった悪夢で、アプリごとにメニュー構造が完全にランダムで、ローカルで設定できるものまで外部サイトへのリンクに飛ばすことがよくあります。
デザイナーの意図を理解するのは本当に難しく、設定を自分が見つけられないのか、そもそもこのメニューに入らないように作られているのか区別できません。
デフォルト設定を変えようとして Google で検索しなければならなかったことがあまりにも多く、体験が製品価値の半分を占めるゲームでも同じです。
CS2 の設定メニューは、上部のテキストボタンがタブのように見えますが、実際には長い設定リスト内の任意の位置へスクロールさせるだけなので、それぞれのボタンが何を意味するのかを頭の中で切り分けにくいです。
概念の意味が互いにつながらず、構造化もされていないため、コンピューティングを探索することが不必要に難しくなりすぎました。
Macromedia Flash の UI が懐かしいです。あまり使ってはいませんでしたが、本当に単純で使いやすかったです。
プライバシーや自作の解決策を探す大きな動機の一つも、最近目にする体験と知識の汚染から逃れたいからです。
昔のサイズ変更ボックスは、縦スクロールバーの一番下、下向き矢印ボタンのすぐ下に、ウィンドウサイズ調整専用のハンドルとして別にありました。
初期画面には表示されていない内容を見るためのスクロールボタンのすぐ近くなので、ビューポートと相互作用する自然な開始点であり、基準点に近いものでした。
皮肉なことにアプリ UI ではほとんど消えましたが、Web ブラウザは textarea のようにスクロールバーと resize が有効な要素では今でもレンダリングすることがあります。ただし、ほとんどの UI には関連するスクロールボタンがもうありません。
最近、面白い気づきがあった。自分の視力が悪くなったのではなく、UIが悪くなったのだ
笑ってしまうほどコントラストの低い小さなスクロールバーは、誰にとってもアクセシブルではない
最近KDEをOxygenテーマで使い始めたが、目が疲れず使いやすくて楽しい
こういうスクロールバーはカスタマイズの余地もない情けない代物で、ロックされたアプリにテーマを適用できるかは運任せだ
UIデザイナーがユーザーの必要を気にしていないことがあまりにも露骨で、FOSSの世界でも例外ではない
見た目がよく、機能的で、アクセシブルで、高速なソフトウェアがあった時代から、ロックされていてテーマも当てられないElectronのゴミへ退化したのは悲しいことだ
UIに十分なコントラストと可読性があれば、「ダークモード」のようなものも必要なかったはずだ
ホワイトモードしかないソフトウェアを使うと、明るすぎて近くの壁が懐中電灯をつけたように明るくなることがよくある
そこで画面の明るさを下げると、色とコントラストがめちゃくちゃになり、結局何も見えない
Win 9x時代の灰色のインターフェースが懐かしい。きれいではなかったが、実際に見えた
眩しいフラットUIが支配したあとに人々がダークモードを求めたのは、まったく不思議ではない
メニューから出てしまいやすく、戻ろうとしてまったく別のものを調整してしまうようなデジタルの手動操作は、あまりにデジタル的で面倒になりすぎた
昔はディスプレイのコントラストや明るさ、アンプの音量、アナログテレビ、サーモスタット、カーラジオなどを調整しやすかった
まだ多くのアナログ操作を再導入する流れにはなっていないが、結局のところ私たちの世界はアナログだ。入力は言葉や筋肉の動きなどアナログであり、出力も光や振動のように感覚に届くアナログだ
なぜ操作がもっとアナログ的でないのか分からないし、おそらくコストの問題なのだと思う
アナログコントロール付きのディスプレイやノートPCなら、すぐに買うと思う。実際には1,600万段階のダイヤルであっても、反応が即時で本物の可変抵抗のように感じられれば十分だ
状況に応じて強度を素早く変えたり、選択肢を巡回して読みやすく聞きやすくしたりできるノブがあるといい
今日やっていることの90%はブラウザ内で行われているので、ブラウザがアクセシビリティAPIを提供し、Bluetoothでも何でも回転ノブで操作できるようになるといい。スクロールホイールの強化版のようなものだ
スクロール可能なポップオーバーや奇妙な内部フレームのあるWebサイトによく出くわすが、小さな内部フレームのスクロールバーが隠れていて、まだコンテンツがあるのか分からず、サイトが完全に壊れていると思ってしまう
本当に腹が立つし、この狂気を奨励し流行させたiOSとmacOSのせいにしたくなる。何が何なのか推測しにくくした「フラット」UIブームを推し進めた側にも間接的な責任がある
UIはコミュニケーションなのに、UIデザイナーたちは、もごもご話すのが格好いいと決めたようなものだ
一方、デスクトップOSでは使われる最小の画面でさえずっと大きいので、スクロールバーを隠すよい理由はあまりない
子どもたちが静かにしていても、寝ていても、学校に行っていても、最近の多くの映画やドラマは字幕なしでは見づらい
あらためて、Firefoxがabout:configでこういうものをオフにできる手段を用意してくれている点を称賛したい。良く見てもかわいい装飾で、悪く見れば苛立たしく悪用的だ
ブラウザUIは、Webサイトが変更できる領域からほぼ完全に除外されるべきで、スクロールバーもそこに含まれる
記事全体はとてもよく書けていて、著者を称賛したい
私もEdgeがBing検索やほかの機能をしつこく押し付け、タブ復元のプロンプトまでうるさすぎたので、またFirefoxへ移った。ただ黙って、もうやめてほしい
年を取った今、振り返る余裕と悪くなった視力という弱点を併せ持つ立場から、自分が間違っていたと認められる。あまりにも簡単に悪用される
幸い、uBlock Originで上書きできる
https://addons.mozilla.org/en-US/firefox/addon/minimap-scrol...
おそらくこれで合っていると思う
<https://www.makeuseof.com/change-firefox-scrollbar-style/>
筆者は問題の半分を見ていながら、解決策の悪い半分を提案している
スクロールバーは制御装置であるだけでなく、位置インジケーターでもある。長いリストのようなより大きなビューの中で、現在のビューポートがどこにあるかを示してくれる
macOS のような一部の GUI みたいにスクロールバーを隠すのは、ボタンをテキストと区別できなくしたり、明るいグレーの背景に明るいグレーの文字を載せたりするのと同じくらい不親切だ
解決策はすでにあり、ほぼ普遍的に実装されている。マウスのスクロールホイールとトラックパッドのスクロールジェスチャーだ
スクロールバーではスクロールできるのに、標準のトラックパッドジェスチャーやマウスホイールではスクロールできないビューは非常にまれだ。私のマウスはホイールで横スクロールもできるし、TrackPoint のコントロールも同様だ
こうしたスクロールでは、ポインターがスクロールバー上にある必要すらなく、目的のビュー／コントロール／ウィジェットの上に乗っていればよい
精度の低い入力デバイス、震える手、視力の悪さがあっても、とても簡単にできる
しかし、このように自然で簡単なスクロール方法があると、スクロールバーがインジケーターとして機能するときの存在が、かえって恋しくなる
ミニマップは役に立つこともあるが、そうでないことも多く、個人的にはテキスト編集では図体が大きいだけで役に立たないと感じる。もちろん、好きな人のためのオプションとして存在することには賛成だ
文書が適切に反応するという前提があれば、特に大きな文書ではスクロールバーで大きな範囲を簡単に移動できる。最近の Web ではその前提を信じにくいが
リンクがなく、「B-29」のようなセクションページ番号を使う古い巨大な PDF で、埋もれたページを探すためにスクロールバーで実質的に二分探索をしたことは数え切れない
もちろん現代の Web は、遅延読み込みと無限スクロールの濫用によって、スクロールバーをインジケーターとして使う可能性をほとんど破壊してしまった
Mac で Cmd-下矢印を使って文書末尾へジャンプし、末尾が存在することを願い、レイアウトを壊す埋め込み要素がすべて読み込まれることを期待したことは何度もある
しかし結局、終点の見えない列車に乗ったように、どれだけ進んだのか、どれだけ残っているのかも分からない
だからスクロールバーが事実上役に立たなくなったので、高速 doom scrolling のために設計された、ベアリング付きの重みのあるマウスホイールを使っている
すぐ次の段落でも、小さい／隠れたスクロールバーが視線追跡装置のような別の入力方式にもたらす困難を扱っている
スクロールバーの第一の役割は、文書がウィンドウより大きいことをユーザーに示すことであり、第二の役割は文書のどの部分が見えているかを示すことだ。ユーザーにスクロールさせることは主機能ではない
Apple が macOS でデフォルトでスクロールバーを隠し始めたときは本当に驚いた。Apple の UI デザイナーたちは、基本的な UI コントロールが実際に何をしているのか分かっていないように思える
Wacom／ペンユーザーにはスクロールホイールがない
多くのトラックボールにもスクロールホイールはなく、一部にはボールの周囲にスクロールリングがあるだけだ
スクロールする指に反復性ストレス障害が出たので、マウスからスクロールホイールを取り外した。マウスを使う腕を伸ばしすぎて、数週間は反対の手でトラックボールを使わなければならなかったこともある
ウィンドウ枠の話もしなければならない。黒い背景と黒い枠の VS Code ウィンドウをいくつも重ねて開いていて、影もない
あるウィンドウのフレーム／境界が、別のウィンドウの上でどこにあるのかまったく見えない。これは OS レベルの問題であるべきなのに、どうやらアプリの問題らしい
しかも VS Code は境界線設定のサポートを「撤回」した: https://github.com/microsoft/vscode/issues/160159
https://news.ycombinator.com/item?id=37865824
私の説では、デザイナーたちは一度に全画面ウィンドウを1つだけ見るユーザーを想定しているのだと思う
彼らのモデルユーザーは、理想的な照明で反射のない部屋で 13 インチのノート PC の前に座り、ウィンドウを移動したりサイズ変更したりせず、1日にタブ／文書も3つ以上は開かない
こういう記事や UX ブログを読むたびに、私たちがアクセシビリティをどれほど気にしていないかがあまりにもはっきりする
アクセシブルな「良い」デザインは、現代の Web アプリに期待されるものよりかなり退屈で、余計なものが少ない
Adam Silver のフォームに関する本を読んで、アクセシビリティの観点では私たちが完全に間違っていることに気づいたが、アクセシビリティは優先事項ではない
特にダークパターンはアクセシビリティと非常に相反する
だからアクセシビリティを義務化する法律が必要なのだ
40代以上の多くの人にとってアクセシビリティ上の問題になるものが何か知っているだろうか？ 暗い背景に白い文字だ。
私の年代の人たちがウェブページを読めるようにしよう、という主張なら何度聞いても飽きないと思う。
開発者ツールを開いて作者のCSSを修正すれば読めるようにはなったが、シェルスクリプトは読めなくなった。
あまりに不快なので、全文を選択しても暗い背景／白い文字のコントラストが緩和されないなら、そのページはそもそも読まない。
CSSを完全にオフにすることも検討できる。
この5年間で本当に良かったのは、主要なユーザーインターフェイスのほとんどが、今ではダークモードとライトモードの両方を提供していることだ。
私の解決策はこれだ。
https://addons.mozilla.org/en-US/firefox/addon/font-contrast...
少なくともテキストを黒に強制してくれる。かなり安定していて、たまに必要になる例外設定も簡単にできる。
スクロールバーが死につつあり、使いものにならなくなっているという点には同意する。スクロールバーは幅広く、はっきり見え、狙いやすいものであるべきだ。
文書のうち現在見えている割合を示すように比例したサイズであるべきで、動く部分には滑りやすさではなく摩擦感を示唆する特徴があるべきだ。
矢印ボタンは互いに反対側の端ではなく一緒に配置されるべきで、ホバー状態とマウス押下状態を色で知らせるべきだ。
ここに出ているクラシックなスクロールバーの中では、https://scrollbars.matoseb.com/ のNextstepが最も条件に近く、Mac OS 8が全体として一番美しいと思う。
かつてはヒューマンコンピュータインタラクションという研究分野があり、Fittsの法則や、画面端が事実上無限の大きさを持つため特に価値があるという事実を学んだものだ。
OS Xで罰ゲームのようにMS Teamsを開きっぱなしにしているのだが、ウィンドウは画面右側にぴったり接しており、右端にスクロールバーがある。
マウスを右へ押しやり、マウスオーバーで拡張されて端のピクセルまで届いたスクロールバーをつかもうとしてクリックすると、ウィンドウ全体がドラッグされてしまう。
どうしてここまで来てしまったのかわからない。良いユーザーインターフェイスとは何かを積極的に研究していた時期があり、その研究が実際のユーザー体験に反映され、結果として表れていたのに。
「昔からそうだったから」以外に、なぜそんなに珍しいのか気になる。
「デザイナーは非技術系ユーザーと一緒にユーザビリティテストをしない」と言うが、たとえしても大差はないだろう。
ほぼ25年ウェブ開発者として働き、多くのデザイナーと協業してきたが、彼らが気にするのは自分の「ビジョン」と一致するピクセルパーフェクトなレイアウトだ。UXは一瞬よぎる考えですらない。
こういう場合、説得は通じない。