UIをサンディングする
(blog.jim-nielsen.com)- UIの完成度は実装直後ではなく、実際に繰り返しクリックして試す過程の中で高まっていくものであり、この記事はそれを木工のサンディングになぞらえている
- ページ遷移やナビゲーションは、クリック、ブラウザの戻る、右クリックの「Back」、アプリ内の戻る、キーボードショートカットのような複数の入り口から確認する必要がある
labelとinput type="radio"をflexboxで整列し、gapを入れると、ラジオボタンとラベルの間がクリックできないdead zoneとして現れる- 解決策は
gapをなくしてlabelにpaddingを与える方法で、見た目の間隔を保ちながらクリック可能な領域を広げられる - 小さなインタラクションの欠陥でも積み重なるとユーザー体験を損なうため、UIを繰り返し使い、「とげ」がもう引っかからなくなるまで磨く必要がある
繰り返しクリックしてUIの粗い部分を見つける
- UI作業は何かを作った後にたくさんクリックし、修正して、またクリックするという反復に近い
- ページ遷移は1つのフローだけを確認していては不十分で、さまざまな方法で戻りながら見ていく必要がある
- クリック後にブラウザの戻るボタンを使う
- クリック後に右クリックのコンテキストメニューの「Back」を使う
- アプリ内の戻るナビゲーションを使う
- キーボードショートカットで戻る
- この過程はQAのように「クリックして壊してみる」に近いが、木工でやすりがけをしながら粗い部分やとげを探す感覚により近い
- ソフトウェアUIにはあまりにも多くの状態と変数があり得るため、繰り返し使いながら、もう「とげ」が引っかからなくなるまで磨くことになる
flexbox gapが生んだクリック dead zone
- ラジオオプションの一覧で、
<label>と関連付けられた<input type="radio">を同じ行に配置した - CSSはコンテナに
display: flex、flex-direction: row、align-items: center、gap: .5remを適用したシンプルな構成だった - 繰り返しクリックしているうちに、ラジオボタンとラベルの間の空間を押してもコントロールがトグルしないdead spotが見つかった
- 原因はflexboxの
gapだったgapは見た目の間隔を簡単に作れるが- ラベルや入力要素のクリック領域には含まれず、インタラクション上の空白になってしまう
- 解決策は
gapを削除してlabelにpaddingを与える方法だった- 間隔は維持される
- ラベルのクリック可能領域が広がり、dead zoneが消える
- 小さな欠陥1つは些細に見えても、こうした「小さなとげ」が増えるとUI体験は苦痛になり得る
1件のコメント
Hacker News のコメント
作っている製品を自分でもよく使うユーザーでもある開発者なら、こうした小さな問題を見つけるうえで非常に有利です。
ユーザーが先につまずく前に、開発者自身が小さな引っかかりに気づけて、すぐ直せる場所にもいるからです。
だから、強いオーナーシップを持つ小さなチームが効果的なのだと思います。製品に当事者意識があると、ユーザーが感じるささいな不便も自分ごとのように感じられ、UX をできるだけ滑らかにすることがプライドの問題になります。
エンタープライズ製品のように社内で使いにくい場合でなければ、直接的なオーナーシップは弱くても、製品の成功に対する利害関係は生まれます。
最も磨き込まれた UI は何なのか気になります。
FAANG くらいなら資金も潤沢なので UI/UX もかなり良いはずだと思いがちですが、Amazon.com や AWS、GCP、Azure を使ったことがある人は違う感想を持つでしょう。
個人的には mcmaster.com が最もよく磨き込まれた UI/UX だと思います。必要なものを数分以内に見つけられます。
一方で Home Depot や Lowe’s のような大型小売サイトでは、ネジや木材のようなものを正確なサイズで探すのに 10〜15 分かかり、モバイルではさらにひどくなります。
信じられないほどシンプルで実用的なのに、かなり強力です。部品を段階的に絞り込んで探すことも検索することもでき、価格比較は自動で行われ、価格／品質カテゴリも便利にまとめられています。
部品番号を見つけると、年式／メーカー／モデルの互換性、簡単な説明、写真、カート内の他の部品と同じ倉庫から発送されるかどうかも見られます。これらすべてが 1 ページ上で摩擦なく、どのプラットフォームでも非常に高速に動作します。
反応が非常に速く、使っている間にバグを見たことがありませんでした。Web アプリでどこまでできると考えるべきか、その基準を引き上げてくれました。
実際、ユーザビリティの問題だけを直す専用期間もありました。
https://linear.app/changelog/2022-12-01-polishing-season-202...
https://web.archive.org/web/20231003205004/https://linear.ap...
特に一時的なプロフィール写真がいちばん腹立たしいです。ほぼ 1 年前からまともに動作しておらず、元の写真に戻りません。
そこでは誰も磨き込みをしていないようです。
https://littlebigdetails.com がまさにそういう場所です。
この特定の問題に対する基本的な解決策は、ラベルの中に入力要素を入れることです。
理由が気になっていましたが、ラベルや入力要素の位置／パディングを調整するときに、テーマ適用がより単純になるからではないかと思います。
[1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
for/id属性が依然として必要です: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...ラジオボタンやチェックボックスは、ボックスとパディングだけでなく、テキストラベル全体を押してもトグルされるべきです。
Flexbox は少し大げさに見えます。入れ子にしない構文でもインラインで配置されるはずで、同じ方法でパディングだけ追加すればよいと思います。
緩和するには、
Fooを別要素で包む必要があります。こういうものは Agile からあまりにも消えてしまった
エンジニアにはプロダクトを磨き込む時間があるべきなのに、実際にはない。QA が余白の問題でチケットを作らなければ、絶対に直らない
顧客はおそらくこういうことに気づくだろうが、報告してくれること自体が奇跡で、それが最終的にチケットになるのも奇跡で、誰かが優先順位を付けて直すのもまた奇跡
実際、ほとんどの会社の課題ボードは顧客の立場から見ると不透明すぎて、小さな問題やバグを見つけても、それがバグであることを証明してトラッカーにチケットを入れるまでに50時間も行ったり来たりしなければならず、うんざりする
ウォーターフォールモデルが UI をテストして磨き込む時間を明示的に与えていたと思っているのだろうか？
これは普通、プロダクトマネージャーが優先順位を決め、有能な UX エンジニアやデザイナーと一緒に対処すべきプロセスだ。望むならどんな開発手法にもその優先順位を組み込めるので、ここで Agile は関係ない
過去3年間に何度も報告した。編集中のテキスト編集が極端に難しく、腹立たしいからだ
Web 開発者として、そもそもどうやってこんなものが壊れたのか不思議だ。デフォルトで動くものを壊すにはどれほどの無能さが必要なのか分からない。30分以上かかるはずのない修正で、全員のユーザー体験を1000倍良くするはずなのに、報告してから3年たってもそのままだ
Teams でも電話番号入力欄で HOME/END キーが使えないバグを Microsoft Premiere Support 経由で報告したが、返答は「設計どおりに動作しています」だった
顧客がこうしたバグをもう報告しなくなるのも驚きではない。従業員/開発者も会社も、どうせ気にしていないからだ
プロダクトのリード開発者だが、あちこちに小さな問題がたくさんある。何かに責任はあるのに直す権限はない、という状態が気持ちいいはずがない
ビジネスの観点では、売上やブランドに打撃がないのに、なぜ時間とお金をかけて直すのか、という理屈になる。長期的にはブランドに影響するだろうが、たいていの人は5年以内に役割や会社を移るので気にしない
返事をもらえるなら、まだましなほう
顧客のニーズを満たしていないプロセスが明らかにあるのだから、チームと一緒に直せばよい
Scrum の儀式があるならレトロスペクティブで取り上げられるが、実際にはいつでもできる。レトロスペクティブは直近数週間を意図的に振り返る場にすぎず、途中で気づいたことは途中で解決しようとすべきだ
小さな UX の問題を見つけて直せる感覚を持った人は本当に重要
UX デザインではこういうものを、ユーザーに生じる紙で切った傷にたとえることがある。致命的ではないが、ユーザー満足度を削っていく
筆者に付け加えると、そのラジオボタンは選択状態にチェックではなく点を使うという慣例に従っていない。ユーザーは一目で、複数選択できる、あるいはまったく選択しなくてもよいものだと誤解するかもしれない
外側をクリックすると閉じるようにした機能の副作用である可能性が高い
ネガティブな側の “Papercuts” があるなら、ポジティブな側には最近 HN でも取り上げられた Juice がある
この記事は、私がなぜ UI プログラミングを嫌いなのかをよく示している
予測できず、些細なことでずれ得るものが、私の忍耐力を超えている。何かが失敗する方法を考えてテストを書くのはある程度楽しめるが、適当にクリックして壊れるかを見るのは散漫で腹立たしい
UI 実装が本質的にこれほど複雑なのか、それともまだ適切なプログラミングモデルを見つけられていないのか気になる。ときどき、最初から意図したとおりに見えて動作してほしいと望むのは unreasonable なのだろうか、と思う
UI を磨き込むのはコンポーネントを最初に作るときだけでよい。時にはコンポーネントを別の方法で組み合わせたり、一回限りの実装が必要になったりすることはある
正直、自分が何をしているか分かっていれば、それほど時間はかからない。優れたデザインエンジニアはこうした役割の専門家だ
自由度が多すぎるし、フォームのような基本要素はデフォルトだけでもうまく動作すべきだ
コードを通じて UI をうまく表現する方法はすでにある。問題はビジネス側のゼロサムゲーム。クロスプラットフォーム UI は、最も見た目の悪い UI スタックである HTML/CSS/JS でやらなければ、コストが高すぎる
しかし Web プラットフォームは、文書にはそこそこ良くても、アプリには抽象化レベルが合っていない。そのため Web UI は毎年、新しく漏れのある抽象化として再発明されている
追いつくだけでも仕事が多すぎる
他の領域でも似ている。リクエストを送ったりクエリにパラメータを入れたりする簡単な方法がなければ、人々は注意しようとしても自然な圧力により、あらゆる半端なやり方を発明してしまう
Web プラットフォームはグラフィックス面では最先端だが、UI としては本当にひどい。なのに誰もそれを認めて変えようとしない。人々は前者だけを信じ、ブラウザのレガシーと複雑さが変化を妨げる。ライブラリとして作ると「標準」ではないので誰も気にしない
一方で、ある UI はラジオボタンに四角いボックスを使うこともある
強調されたボタンがあるのに、Enter キーで有効化されないこともある
また、互いに異なる記号（省略記号、ハンバーガー、ケバブ）の後ろにメニューが3つずつ隠れていることもある
品質のばらつきが大きい。UI を磨き込む人たちは本当にありがたい存在だ
Apple でさえこうしている :(
なぜ入力要素をラベルの中に入れる方式が人気がないのか理解できない
こうすれば問題は完全になくなるし、
forに使う一意なidを作る必要もないただし、いまだに新しい有効な標準パターンを解釈できない支援技術がいくつかあると知られているため、青銅器時代の標準を守るのがベストプラクティスになっている [1]
他のフレームワークも似たようなものだと思う。その2つの入力フィールドを
label要素で囲むと、もはや有効なHTMLではないラジオボタンでは問題にならないが、何人かはこれを経験した後、「念のため」にそうしているのだと思う。JavaScriptの行末にセミコロンを付けるのと似ている。ほとんど必要ないが、正確にいつ必要なのかわからないので、どこにでも付けるというわけだ
チェックボックス／ラジオボタンの一般的なユースケースでは、構文もずっとすっきりする
入力要素をラベルで囲み、テキストにスタイルを当てたいならテキストを
spanに入れればよい。labelをdisplay:flexにして、テキストの位置もそれで処理できるバグバッシュではこの方式を使っているが、テストケースの組み合わせを多次元のデカルト積行列で作った人より、はるかに多くのチケットが出てくる
出発点としてそうしたテストケースを知っておくのはよいが、小さな問題を見つけるにはランダムテストが計画されたテストをすぐに追い越す
計画されたテストはたいてい正常系や想定されたエラーにとどまる。こうした磨き込みのやり方は、隅のバグをずっと早く見つける
いつも問題や小さな改善点を見つける。計画されたテストでは実際にはあまり出てこなかっただろうものだ
個人サイト（https://dustinbrett.com）をもうすぐ4年ほど磨き続けているが、永遠に続けられそうな気がしている
幸い、作業することを楽しめている
全部だったことを願う :-)
「Webページ上のデスクトップOS」を見ると、たいてい半分だけ作ったような感じで、正直あまりにもありふれてきたと感じるが、これは逆にとても堅牢でよく磨き込まれている
本当によく作られていて、刺激になる。すべてをどう実装したのか考えるのもかなり楽しい
スマートフォンでウィンドウベースのOSを使いたいという欲求だった
足りないものを一つ挙げるなら、explorerでmouse4/mouse5を使えない点だ。「磨き込み」は本当に永遠に続けられる