- Scrolljackingは、ブラウザ標準のスクロール速度・方向・効果を上書きし、ユーザーが期待する予測可能なウェブ閲覧を揺るがす
- Nielsen Norman Groupのユーザビリティ調査では、多くの参加者が方向感覚を失い、一部は変更されたスクロールをバグと受け止めた
- モメンタム・スムーズ・慣性スクロールのプラグインは、筋肉記憶とブラウザ標準機能を壊し、長いページで現在位置を把握しにくくする
- 画面遷移アニメーションとJavaScript依存は、乗り物酔い・めまい、支援技術、低スペック端末、モバイル環境でアクセシビリティ・性能面の負担を大きくする
- ユーザーはスクロール演出ではなくコンテンツを見に来るため、サイトはネイティブで高速なスクロールをそのまま維持するほうがよい
Scrolljackingがウェブ閲覧を台無しにする仕組み
- Scrolljackingは、ブラウザ標準のスクロール動作を再定義し、ウェブページのスクロール速度、方向、効果を変える手法である
- モメンタムスクロール、スムーズスクロール、慣性スクロールのプラグインは、よくあるscrolljackingの形態にあたる
- 改善機能のように見えることもあるが、自然で効率的かつ予測可能なウェブ閲覧体験を妨げる
- 影響は大きくユーザビリティ、アクセシビリティ、パフォーマンスに及ぶ
ユーザビリティ調査で確認された混乱
- Nielsen Norman Groupのユーザビリティ調査は、scrolljackingがユーザーに方向感覚の喪失を引き起こし得ることを示している
- 参加者の多くが、少なくとも軽い方向感覚の喪失を経験した
- 一部のユーザーは、変更されたスクロール動作をバグと解釈した
- タスク志向のユーザーは、探索志向のユーザーよりもscrolljackingへの許容度がはるかに低かった
- ある参加者は「完全にスワイプしたのに、どこにも移動しなかった」という趣旨の反応を示し、潜在顧客の立場なら非常にいら立っただろうと述べた
- モバイルでは、長いスクロール継続時間と小さな画面のため、問題がさらに大きくなる
ユーザーの期待と制御権の侵害
- ユーザーは、スクロールすればコンテンツがすぐに動くという基本動作を期待している
- モメンタムスクロールのプラグインは、即時で予測可能な移動の代わりに、アニメーションを交えた動作を提供する
- こうした変化は、ユーザーが効率的な閲覧で頼りにしている筋肉記憶と既存の習慣を妨げる
- 標準スクロールを上書きすると、サイトの演出がユーザーの好みや必要性より優先されることになる
- ユーザーは、過剰に演出されたスクロール体験ではなく、コンテンツを見るためにサイトを訪れる
乗り物酔いとアクセシビリティの負担
- モメンタムスクロールのプラグインは、浮遊感やふらつきのあるアニメーションを追加し、乗り物酔いやめまいに弱いユーザーの負担になり得る
- 多くのサイトはこれをオフにするオプションを提供していないため、ユーザーは文章を読む過程で不快感を避けにくい
- スクリーンリーダーやキーボードナビゲーションのような支援技術は、タイミングの遅延によって妨げられる可能性がある
- 運動障害や視覚上の制約があるユーザーは、こうした遅延によりサイト利用がさらに難しくなる可能性がある
- アクセシビリティは選択機能ではなく、ウェブ利用の基本要件として扱われるべきである
パフォーマンスと端末間の一貫性低下
- モメンタムスクロールのプラグインはJavaScriptを読み込み、古い端末や低スペック端末では遅延、カクつき、故障を引き起こすことがある
- ページが「Smooth」に感じられるどころか、非力な端末では壊れているように見えることがある
- アニメーションのレンダリングには、肥大化したJavaScriptライブラリ、追加の依存関係、より多くのCPUサイクルが必要になる
- その結果、ページの読み込み時間が遅くなる可能性がある
- モバイルネットワークや接続状態の悪い地域では、派手なスクロール効果がページをさらに遅く、アクセスしにくいものにする
ブラウザ標準機能と位置認識の問題
- 現代のブラウザには、希望するユーザー向けのモメンタムスクロール設定がすでに含まれている
- サードパーティ製プラグインはこうした標準機能を上書きしたり競合したりして、カスタムスクロールジェスチャーやモメンタムスクロールを壊す可能性がある
- システム全体の動きを減らす設定のようなユーザー設定が、期待どおりに動作しない可能性がある
- モメンタムスクロールのアニメーションは、ユーザー入力と結果の間に遅延を追加する
- 長いページでは現在位置を正確に把握しにくくなり、素早い閲覧も面倒になる
パワーユーザーと保守コスト
- ドキュメントを素早く流し読みしたり、ページ内を精密に移動したりしたいパワーユーザーにとって、モメンタムスクロールは作業の流れを遅らせる
- 遅いアニメーションを待たなければならないため、素早く作業を終えたいユーザーの期待と衝突する
- モメンタムスクロールのプラグインは、一度インストールすれば終わりという機能ではない
- 最新のブラウザ、OS、端末と互換性を保つには定期的なアップデートが必要である
- アップデートのたびに新たなバグが入り込むリスクがあり、開発チームには、サイトをより高速・安全・最適化するために使えるはずの時間とコストの代わりに、追加作業が発生する
結論：スクロールは標準動作のままにする
- Scrolljackingとモメンタムスクロールのプラグインは不要な複雑さを追加し、ユーザビリティを低下させ、ユーザーをいら立たせる
- Nielsen Norman Groupの表現を借りれば、「ユーザビリティは楽しさの基盤」である
- スクロールを再発明するのではなく、ネイティブで予測可能かつ高速なスクロール動作を維持すべきである
- スクロールを特別なイベントにせず、ユーザーがただスクロールできるようにしておくべきである
1件のコメント
Hacker News のコメント
URL、ブラウザのナビゲーション、戻るボタンにも手を出すべきではない。
これはもうずっと前に負けた戦いのように思えるし、SPA が Web を壊して、はるかに悪くしてしまった。
History API はちゃんと機能するので、SPA と独自ナビゲーターをブラウザやユーザーに合わせて動作させることはできる。
ただ、多くの開発者がブックマーク可能性やナビゲーションといった Web の基本を気にせず、壊してしまった。
良い SPA は普通の Web サイトのように動作し、速くて反応が良いこと以外では SPA だと気づかれないべきだ。
特定の状態をブックマークしたり共有したりできるべきなのはその通りだが、そのために新しいナビゲーション段階を作るより、URL だけがその場で変わるほうがずっと良い。
Web の基本、URL、戻る操作、スクロールのユーザー体験などを気にしない人たちが Web を壊したのであって、SPA そのものが問題なのではない。
ブラウザが直すべきだが、慣性が大きすぎて実現しなさそうだ。
「ユーザーより自分たちのほうがよく分かっている」という態度は、Momentum スクロールだけでなく、現在の UX デザインの多くの流行にもそのまま当てはまると思う。
あらゆるものを犠牲にしてまで美学崇拝に陥るようになった経緯が気になる。
ユーザーが自分で一切責任を負えないようにする、極めて見下した態度が根底にある。
今日も macOS で「Touch ID を有効にするにはパスワードが必要です」という煩わしい動作をオフにする方法を探したが、再起動後に求められるのは理解できるとしても、時間ベースに見える要求はオフにできなさそうだった。
見つけた最も近い方法は
bioutilコマンドで時間制限を短くすることだったが、長くすることはできなかった。最大値チェックの場所をリバースエンジニアリングして、下位 API を直接呼び出して回避できるか見てみようかと思っている。
むしろUX デザインの不在に近い。
「Button presses You」のようなタイトルの良いブログ記事があったが、見つけられない。
要点は、アプリケーションの目的がユーザーにプログラムで何をさせるかを決めることではなく、アプリケーションがユーザーに何をどうするよう指示する方向へ流れている、ということだ。
スクロールバーにも手を出すべきではない。
最近はあらゆる場所で幅 1pxくらいにする流行があるようだ。
アプリを本当に人間工学的に作りたいなら、1 本指や 2 本指のジェスチャー、たとえば指でドラッグしてスクロールする動作がきちんとできるようにすべきだ。
そうなると、デスクトップでスクロールする唯一の方法が、フレームの端を越えてテキストをドラッグ選択することだけになる。
はみ出すコンテンツは使わないようにしているが、どうしてもはみ出す必要があるときは、スクロールバーがデザインの邪魔をし、標準のスクロールバーがあまりに見栄えが悪いので隠している。
マウスを動かした瞬間に現れ、止めると消える。
進行位置を見たければ、マウスを少し動かせばいい。
Gopher の時代からインターネットを使っていて、純粋な HTML の美学のミニマルさが好きだ。
記事の下に、この文章の着想元になった Web サイトへのリンクがあるのもとても良かった。
こういうページでソースを見ると、単なる懐古ではなく「この人たちは分かっているな」と感じる温かさがある。
Helvetica のドキュメンタリーで、デザイナーたちが 1950 年代風のいまいちなスクリプト書体の代わりに、新しく Helvetica を選べるようになったときの感覚を説明していた場面に似ている。
スクロールに応じて背景に表示される内容が変わったり、ページ区画自体が分かれたりする派手なランディングページも、ここに含まれると思う。
例: https://webflow.com/made-in-webflow/website/Translate-Webflo...
iPad の傾きスクロールは、年配の人でも速く読んでスクロールする助けになるし、自動スクロールもかなり良い。
本来は上下にだけスクロールするページだった場所の項目行に < > ボタンを入れるのも、初めて見たときと同じくらい今でも嫌いだ。
ストリーミングメディアプラットフォームがこの分野で最も悪名高いが、唯一の犯人ではない。
最近いちばん嫌いなのは、Ctrl+F や Ctrl+K を横取りすることだ。
ブラウザ側でこれを可能にするには、明らかに追加のコードが必要だったはずで、Google にせよ Apple にせよ Mozilla にせよ、そのコードを書かないことにコストはかからなかったはずだ。
ブラウザはこういう場合に使える Shift+Ctrl+F のような代替ショートカットを提供すべきだ。
Firefox で Shift+Cmd+F が何か動作することに今気づいた。
標準のキー組み合わせに手を出すべきではない。
他のアプリケーションの機能を奪って、ユーザーを驚かせるべきではない。
最近 Mac の Google Sheets で、スプレッドシート内検索用の Cmd-F が動作しなくなったが、その方式はシステムショートカットを横取りするものではあったものの、実際には代替機能もなかった。
そのため検索するには、Sheets のメニューバーに行ってメニュー内から探す必要があった。
下へスクロールするとアニメーションが進み、要素が横に動き、スクロール関門を通過しないと再びページ下部へ進めないものにも手を出すべきではない。
ひどく、目障りで、邪魔で、ユーザーに敵対的なデザインだ。
いちばん笑えるのは、「Back to the normal version」リンクが、ページ最上部までスムーズスクロールで戻らないとクリックできない点だ。
まんまとやられた。
Firefox でこれを
about:settingsからオフにできるのか気になる。それともイベント検知が壊れるのだろうか？
代替としてブラウザ拡張機能が役に立つかもしれない。
実装はケースごとに違いそうで、ページの例 [1] は luxy.js [2] ライブラリを使っている。
この特定のページ [1] では、開発者ツールのコンソールで次のコマンドを実行すると、スムーズスクロール動作を無効化できた。
luxy.init({ wrapperSpeed: 1.0});