- 新しいソーシャルメディアプラットフォームやクライアント、アプリ、React NativeベースのWeb移植が増える中で、Webサイトがユーザーの期待する基本的なWebの挙動を失うケースが多くなっている
- 迅速なリリースへの圧力、UIエンジニアの不在、モバイルのタッチ優先設計、JavaScriptでブラウザの標準動作を置き換える実装が主な原因として挙げられる
- テキストのコピー、リンクの右クリックや
ctrl + click、ブラウザのズーム、レスポンシブレイアウト、:hoverと:focus、URL・履歴の更新、スクロールバー、ctrl + fのようなブラウザの標準機能はそのまま動作すべき
- クリック可能なカードで
pointer-eventsを取り除いたりレイヤーを重ねる実装、アンカーの代わりにdivとon-clickで遷移させる実装は、通常のリンク体験を壊してしまう
- アクセシビリティ違反と重なる部分は多いが、Webアプリはモバイルアプリのように見せることよりも、ユーザーが期待するごく普通のWeb機能を維持すべき
Webサイトが失った基本動作
- Webプロジェクトが、ユーザーの期待するごく普通のWeb機能を妨げることが増えている
- 新しいソーシャルメディアプラットフォームが増えるにつれて、さまざまなクライアントやアプリが作られ、React Nativeのようにプラットフォーム間でコード共有を試みる事例も多くなっている
- こうした試み自体は前向きだが、画像の
altテキストのような基本的なアクセシビリティ要件だけでなく、Webの一般的な操作方法まで抜け落ちることがある
- 原因としては次のような点が考えられる
- テスト可能なレベルまで素早く公開しようとする圧力
- プロジェクトにUIエンジニアがいない状況
- モバイルのタッチ入力を優先し、他の入力方式やデバイスを無視する設計
- JavaScriptでブラウザの標準動作を回避または置き換える実装
維持されるべき、ごく普通のWeb機能
- テキストをコピーできるべき
- クリック可能なカードコンポーネントで
pointer-eventsを取り除いたり、クリック対象のレイヤーを重ねたりすると、テキストの選択やコピーが妨げられることがある
- リンクのように遷移する要素は、リンク機能をそのまま提供すべき
- 右クリックでコンテキストメニューを開き、リンクテキストやアドレスをコピーできるべき
- Windowsの
ctrl + clickのように、新しいタブで開く一般的なリンクショートカットが動作すべき
divにon-clickを付けて遷移させるのではなく、アンカー要素を使うべき
- ブラウザのズーム時にレイアウトが崩れてはならず、ユーザーが読むために拡大できるべき
- レスポンシブWebは、1200pxより狭くなった瞬間に単純なモバイルレイアウトへ落ちるのではなく、狭いビューポートでも空間を適切に使うべき
- MastodonとTwitterは、ブラウザ幅を狭めたときにもUIが馴染みのある形で保たれ、空間をおおむねうまく活用している例といえる
- Webアプリは、
:hover、:focus、:activeのようなインタラクション状態を正常に提供すべき
- React NativeアプリをWebに移植した事例では、
:hoverや:focusのスタイルがなかったり、妙に無効化状態のように見える:activeスタイルが現れたりすることがある
- クリック後にUIが新しいページのように完全に変わるなら、ブラウザの履歴とURLも合わせて変わるべき
- 独立したページのように見えるUI状態にリンクできず、移動後に状態が失われると使い勝手が悪くなる
- スクロールバーは隠すべきではない
- ユーザーはスクロールバーをクリックしてドラッグしたいかもしれない
- 一般的なブラウザショートカットを、アプリ内機能のために横取りすべきではない
ctrl + fでカスタムのアプリ内検索ボックスを開くようにすると、ページ内検索が普段どおり動かなくなることがある
- アクセシビリティ違反と見なせる項目と重なる部分は多いが、焦点はWebアプリがユーザーのブラウザに対する基本的な期待を壊さないようにすることにある
- 抜けている事例はMastodonで引き続き話せる
3件のコメント
本文の内容が誤っているようです
おや、不思議ですね。該当ブログ記事自体のクロールが少しおかしくなっているようです。
クローラー部分を一度確認してみる必要がありそうですね。
Hacker News の意見
React で先に Web を学び、HTML を後から学ぶと、リンクのデフォルト動作を気にしなくなることがある
私がチームに加わったとき、すべてのリンクがボタンだったり任意の要素だったり、
onClickで処理されていたりして、誰も不満を言っていなかったが、Ctrl+クリックは役に立たず、右クリックメニューも期待する選択肢を出してくれなかったリンクに関してだけは、交渉の余地はないと思う
YC の投資を受けた archbee というドキュメントプラットフォームでも、検索結果を新しいタブで開けないので、現在のタブで1つ開き、違ったら戻って再検索して次の結果を開かなければならない
例はここで見られる: https://docs.sparklayer.io/
これほど大きなインターネットサービスが、こんな明白なアクセシビリティ問題を抱えているのは本当に奇妙で、気が狂いそうになる
アカウントが不要というのもあるが、ツイートスレッドを右クリックして新しいタブで開ける
Twitter の会話の性質上、元のページ位置を維持したまま複数のスレッドを新しく開いて見たいのに、実際の Twitter UI はそれを非常に難しくしている
これ以上に気になることはあまりなく、あえて挙げるならブラウザの閲覧履歴を壊すことくらい
戻る操作が即座に滑らかに動作するならまだ許せるが、実際にはコンテンツの再読み込みを待たされ、スクロール位置も失うことになる
さらにひどい場合、Facebook のように複数タブで同じチャットポップアップの状態を強制するサイトもある。1つのタブで閉じると他のタブでも閉じるが、複数のタブを開いているのには別の理由がある
標準で提供される動作に手を加えた瞬間、それに対する責任も一緒に背負うことになると思う
作った「機能」は設計者が意図した狭い範囲にとどまらず、訪問者が実際に経験する全体の体験になる
戻るボタンのロジックを変えるなら、そのサイトで戻る操作が持つ意味そのものを変えることになり、その結果として混乱し怒ったユーザーが「壊れたサイト」と罵ることにも責任を負うべきだ
スクロールバーのように、ブラウザや OS ごとに異なる動作まで本当に責任を持つ準備ができているのか考える必要がある
結局、Web サイトに一種のクレオール語を話させるようなもので、訪問者がその言語を理解できなかったり「誤解釈」したりしても驚くことではない
こうした機能は、訪問者に親切にするために避けるべきという程度ではなく、得られる利益は限定的で、損失はほぼ無制限に見える
こうしたイディオムを無視するサイトは、ユーザーが慣れ親しんだ言語を話していないため、より使いにくくなる
デザインのイディオムの喪失について詳しく書いた記事もある: https://loeber.substack.com/p/4-bring-back-idiomatic-design
これはWeb サイトのアプリ化だと思っていて、もう止めるべきだ
Web サイトはサーバーサイドレンダリングに戻り、必要な分だけ JavaScript を載せる方向に行くべきだ
逆に Web アプリはユーザーに価値があるなら UX をもう少し扱ってもよいが、ブラウザの中にある限り基本原則は依然として適用される
Web アプリはアプリストアの壁の外で誰でもアクセスできる開発プラットフォームなので支持するが、すべての Web サイトをアプリのように扱うのは止めるべきだ
検索エンジンの結果に表示されることを望むページなら、それは Web アプリではなく Web サイトだ
Accept: text/markdownを送れるとよいが、CSS が登場した瞬間にその船は出てしまったと思う幸い React Server Components のようなもののおかげで、Web サイトに JavaScript を少しずつ載せる方向へ戻りつつあるようでよい
十分な時間をかければ可能な問題だ
銀行のWebサイトがなぜ貼り付けを禁止するのか分からない
貼り付けられないと気づいた時点では、もうテキストをコピーした後である
手入力するとミスが増えるし、クリップボードが汚染されているなら、貼り付け禁止に気づいた時点でコピーはすでに終わっている
人々がそれをセキュリティ対策だと思い込み、自発的に写しているところまで来ているようだ
そもそもユーザーの貼り付けを妨げる理由が分からない
その「パスワード」はたかだか6桁の数字で、しかも自分で設定もできない。パスワードマネージャーが生成する16文字のランダム文字列より、6桁のほうがずっと安全だと言わんばかりだ
ページ内のランダムな位置にあるボタンで入力することを強制するが、デバイスがすでにキー入力やクリックを記録されるほど感染しているなら、攻撃者はブラウザのメモリからパスワードも普通に読める気がする
セキュリティの観点からすると、本当に信じがたいほど悪い判断だ
ボットを邪魔しようといろいろ試し、ある日、中間管理職に押された開発者たちがログインページでコピー＆ペーストを禁止すると、ボットが一時的に止まる
数日後にボットは回避するが、以前の「修正」は「一部のボットは止められるかもしれない」という考えとして残る
そうして10行そこそこのJavaScriptがリライトv6まで生き残り、新しく始めてから数か月または数年が経つと、また同じ禁止が入る
決して経験から言っているわけではない
https://techcrunch.com/2018/07/03/new-malware-highjacks-your...
そういう類いを意識したのかもしれない
派手なJS開発者たちが、誰も求めていない複雑さや機能を、ネイティブHTMLに見えるselectメニューの裏に隠すときは腹が立つ
都市と州の入力でよく見るが、都市はテキスト入力で、州はドロップダウン/selectメニューという場合だ
テキサスの人間なので、都市を入力してTabで州選択メニューに移り、
t、tを押して次のフォーム要素へ進むことがよくあるところが最近は、ドロップダウン風に装ったテキスト検索入力なので、
t、tがTennesseeの次にTexasを選ぶのではなく、文字どおりttの検索になってしまうマウスで三角形をクリックし、州の一覧をスクロールする人にだけ期待どおり動く
壊れていないなら直すべきではない
歴史的に、本物の
<select>はスタイル変更や動作拡張が非常に難しいか不可能だったため、多くのアプリが自前で再実装し、たいてい出来はひどかった新しくスタイル指定可能な組み込みの代替物が出てきているようだ
また、アプリ・フレームワーク・企業間でコード共有が難しかったため、完全な機能、アクセシビリティ、カスタマイズ性を備えた組み込みコンポーネントの代替品は大企業にしか作れなかった
Web Componentsは、
<select>のような共通の末端コンポーネントで世界規模の協業を可能にし、この問題を解決できる関連記事: https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...
壊れたリンク動作の多くは、デフォルトのリンク動作を上書きするための上位レベルのメソッドが不足しているせいだと思う
たとえばリンクをモーダルで開きたいからといって、クリックイベントリスナーを付けたくはない。クリックイベントは低レベルすぎて、修飾キーを自分で確認しなければならない
本当に欲しいのは、「このアンカー要素のせいで現在のウィンドウURLが変わろうとしたら、代わりにこの関数を呼べ」とブラウザに伝えることだ
そうすればユーザーはリンクを新しいウィンドウや新しいタブで自由に開け、その場合、私のコードは実行されない
CSSも同様で、すべての要素や疑似クラスごとにカーソル画像を指定したいわけではない。「デフォルトの手形/待機/リサイズカーソルを使おうとしていた場所では、このカスタム画像を使え」と言いたい
そうすれば新しい要素やUIが出ても、コードは将来にわたって安全になる
一部のブラウザAPIは、ときどきXY問題を抱えているように思う
タグに
onclickを登録し、イベントハンドラーでデフォルトのナビゲーション動作をキャンセルすればよいユーザーがJavaScriptをオフにしていてもサイトは引き続き正常に動作し、右クリックのリンクメニューや
Ctrl+クリックのような組み込みのブラウザ動作もそのまま機能するただし、かなりobscureな「トリック」なので、DOM APIがもっと簡単にしてくれるといい
これがNavigation APIのユースケースだと思う
クリックやポインターイベントではなく、上位レベルのvisitイベントが必要だ
Flutter Galleryを初めて見たとき、Webブラウザ上ですべてが壊れているように感じて驚いた: https://gallery.flutter.dev
特にReplyの例がそうだったように思う
リンクで
Ctrl+クリックやマウスの中ボタンが使えず、右クリックもできず、テキストの選択やコピーもできず、技術構造上、要素の検査もできず、ページの拡大を試しても何も起きなかったその体験と、より伝統的な技術で作られた一部のSPA実装を思い出すと、この記事は正しいことを言っているように聞こえる
Webであれモバイルであれ、どのFlutterデモも使えるUXだと納得させてくれたことはない
Flutterの約束がどこでも同じということなら、このデモもデスクトップで同じようにひどいはずだ
スクロール動作も上書きしないでほしい
スクロールを「もっと滑らかに」しようとして改善しようとすべきではない
Windowsでは問題なさそうに見えるかもしれないが、MacでAppleの入力デバイスを使うと、トラックパッドやマウス上で指を動かすこととスクロール対象の動きが1:1で対応する
こうした「改善」はたいてい、糖蜜の中をスクロールしているような感覚になる
一般に、ブラウザのデフォルト動作を改善しようとすべきではない
ひどい現代のWebで嫌いなことの一つは、History APIをいじることだ
HNのような場所で面白そうなリンクをクリックしてページに入り、スクロールすると、すべてのヘッダーや大して重要でない要素まで履歴に項目を追加する
元のサイトに戻るには、戻るボタンを100万回くらい押さなければならない
こういうことをする人たちはみんな嫌いだ
ただページネーションを使えばいい
リンク可能で、検索可能で、ナビゲート可能で、履歴ともきちんと動作する
無限スクロールは、これらすべてを特に理由もなく壊してしまう
ここには実は、Webと同じくらい古い二つの問題がある: 低い期待値と、人や実務を定義する標準・基準の不在だ
最近の求人を見るとどれも「Senior Fullstack Engineer」だが、ふたを開けてみると実際に求めているのはJavaやPython、R、Spring、SQLの組み合わせであることが多い
フルスタックではないのにそう書けば、人々の時間を無駄にし、技術を理解していないか気にしていないというシグナルを世間に送ることになる
プログラミングではこれを「X/Y問題」と呼ぶ。望む最終状態Xを解くべきなのに、代わりに自分が取りたいアプローチYだけを語るアンチパターンだ
その結果、雇用主は一つの求人に500通の履歴書を受け取っても、誰も適任ではないと感じることになる
出発点は目標であるべきだ: 「私たちはこのようなクライアント/サーバーアプリを作るために採用しており、候補者はX、Y、Zの機能を書き、サポートする必要があり、制約はA、B、Cだ」のように書くべきだ
企業がこれをできない理由は、多くの場合、自分たちが実際に何をしているのか分かっておらず、すでにいくつもの誤った道を通って壊れた技術を抱え込んでいるからだ。だから技術的負債と呼ばれる
このように目標が明確なら、面接時に会社と候補者の双方が何を確認すべきかを理解し、互いを適切に選別できる。そうでなければ、ブラインドデートとゲームショーが混ざったようなひどいプロセスになる
たとえば、高度に分散したメディア会議アプリケーションを作るために採用しており、開発者はTypeScriptを書き、ソケットのストリームデータをパイプでつなぎ、ブラウザとサーバーの両方で作業し、テスト自動化を書く必要がある、と明示できる
運用上の制約には、WCAG AA準拠、法務チームが作成したプライバシー遵守チェックリスト、実行速度とネットワーク遅延を対象にした性能面の考慮事項が含まれ、理想的な候補者は面接でネットワーク遅延、ブラウザアプリケーションロジック、ストリーミングデータの状態管理の解決策を示す必要がある