- 機能が増えた現代のインターフェースが操作要素を画面の外へ隠すようになり、ユーザーは見える手がかりを認識するのではなく、使い方を覚えなければならない knowledge in the head の状態へ戻りつつある
- ドロップダウンメニューは可能な操作を探索できるようにして knowledge in the world を提供していたが、スマートフォン・自動車・家電は、スワイプ、長押し、ボタンの組み合わせのような見えない操作に依存することが多い
- iPhoneの懐中電灯・通知・Apple Pay、自動車のキーフォブ、CarPlayのApple Maps、電子ドアロック、アプリの通知音、Rの空白画面は、隠されたコントロールが実際の使いやすさをどのように低下させるかを示している
- この問題は初心者だけのものではなく、統計ソフトウェアのように専門ユーザーが使うツールでも、メニュー中心のシステムからコマンドライン中心のツールへ移行するとアクセシビリティが低下し得る
- 設計者は美的な単純化や画面スペースの節約だけを理由にコントロールを隠すべきではなく、自動化が難しい機能では 発見可能性 と、常に見える操作要素を優先すべきである
見えるコントロールと覚えなければならないコントロール
- Douglas Engelbartは1960年代初頭、コンピューターインターフェースにおける knowledge in the world と knowledge in the head の概念を提示し、Donald Normanがそれを The Psychology of Everyday Things で体系化して広く知らしめた
- knowledge in the world とは、必要なコントロールが見えており、ユーザーが記憶ではなく認識によって識別し操作できる状態である
- 現代のグラフィカルインターフェースにおけるドロップダウンメニューは、コマンドや位置を覚えなくても、メニュー構造を探索して目的の操作を見つけられるようにする
- knowledge in the head とは、特定の装置を使うために、コマンドや操作方法をユーザーが記憶しなければならない状態である
- DOSベースのシステムでファイル一覧を見るには
DIR コマンドを知っている必要があり、別のシステムではコマンドが異なる場合もあった
- このようなシステムは必要な知識のほぼすべてを頭の中に持っていなければならないため、隠されたコントロールの極端な形に近い
ドロップダウンメニューが変えたアクセシビリティ
- HCIの専門家たちは、過度な knowledge in the head の要求が非専門ユーザーのシステム利用を妨げることをすぐに認識した
- ドロップダウンメニューは知識を画面上に配置し、ユーザーが可能な操作を確認してから必要な機能を選べるようにした
- この変化により、細かなコマンド訓練なしでも多様なコンピューター作業を効果的かつ効率的に実行できるようになり、コンピューターの普及を加速する一因となった
スマートフォンと自動車でよみがえった隠れた操作
- この40年ほどでコンピューターの形態は大きく変わり、デスクトップは今でも1980年代型の見えるコントロールモデルに従う場合が多い一方、スマートフォンは再び 記憶に基づく操作 を要求している
- iPhoneの懐中電灯は、コントロールパネルを開くために左下から上へスワイプする必要があるが、インターフェース自体にはその操作が可能であることを示す表示がない
- 通知を見るには上部の隅から下へスワイプする必要がある
- Apple Payはラベルのない多機能ボタンを2回押さなければならない
- 単純な作業でも、隠されたコントロールの数が増えると難しくなる
- 自動車のロック解除の事例では、キーフォブのボタンとドアハンドルのボタンが機能しないとき、すべての解決策が隠されていた
- フォブの中に隠された物理キーがあることを知っていなければならない
- 自動車のドアハンドルの一部を分解すると鍵穴が現れることも知っていなければならない
- 車両は no remote unlock モードに入っており、ウインカーの特定の点滅パターンだけが手がかりとして提供されていた
- 解決するには、キーフォブの難解なボタン入力順序で車両を正しいモードに戻す必要があった
- 問題を知らせる隠されたコードと、機械的・コンピューター的な解決策がいずれも見えなかったため、約30分間車に入れなかった
車内グラフィカルインターフェースと時間ベースのコントロール
- CarPlayのApple Mapsは、地図をできるだけ大きく表示しようとする設計のため、検索とズームのコントロールを標準画面から隠している
- 目的地を入力したり地図を拡大したりするには画面左下をタッチする必要があり、そのとき検索とズームのアイコンが表示される
- 時間ベースのコントロールも一般的な 隠された操作 の形である
- コンピューターの電源ボタンはラベルがあっても、単に押すだけでは望む動作が起きない場合があり、一定時間長押しする必要がある
- 事前の訓練や知識がなければ、操作方法そのものが隠されている
- 電子ドアロックは、隠されたコントロールと時間ベースのコントロールが組み合わさった事例である
- 解錠は大きな中央ボタンが指を置くというアフォーダンスを提供している
- 施錠は
# キーが隠されたコントロールであり、単に押すのではなく5秒間押し続けることで有効になる
- 長い時間条件と隠されたコントロールが重なると、システムをよく知るユーザーでなければ施錠が難しい
ユーザーの命令を迂回する隠された制御
- ステレオの音量を0に下げると、ユーザーは再び上げるまで音は出ないだろうと期待する
- iPhoneでは、音量を完全に下げたりサイレントスイッチをオンにしたりしても、アプリが隠された制御を通じて音を出せる
- 例えば、インターネット接続の猫用トイレが真夜中に掃除完了を知らせたり、Instagramが午前3時30分に子どもが動画を投稿したと通知したりする場合がある
- このような動作は、ユーザーが出した単純な 沈黙の命令 をアプリが迂回する形で現れる
専門ユーザーでも避けにくい空白画面
- 隠されたインターフェースの問題は初心者だけに影響するものではない
- 統計解析ソフトウェアでは、多くの専門研究者がSPSSのようなメニュー中心のシステムから、Rのようなラインエディタープログラムへ移行しなければならない状況がある
- 基本形の R はDOSウィンドウのように空白画面の圧迫感が大きいインターフェースであり、最も単純な作業にも統計知識以外の相当な利用知識を要求する
隠されたコントロールが増えた理由
- Donald Normanは35年ほど前、可視性、のちに 発見可能性 と呼ばれるようになった原則を、基本的な設計原則の1つとして提示した
- ユーザーはコントロールとメニューを体系的に探索し、システムに何ができるかを判断できるべきである
- 現代の機器にはあまりに多くの機能が入るようになり、すべてのコントロールを画面上に見える形で配置するスペースが不足している
- システムの複雑さや、ユーザーが知らない、あるいは誤解している相互依存性も、コントロールが隠されているように感じさせる
- あるモードではコントロールが見え、別のモードでは見えない場合がある
- ユーザーがこの依存関係を理解していなければ、コントロールが隠されているように感じる
- 既存のコントロールに複数の機能を重ねたり、画面上の表示のない位置をタップさせたりする方式は、見えて持続的なボタンを設計するより簡単である
- コンピューターの電源ボタンには偶発的なシャットダウンを防ぐ目的があり得るが、適切にラベル付けされた回転式コントロールなら、機能と使いやすさを保ちながら隠された操作を減らせる
見えるコントロールを維持した設計事例
- General Motorsの地図インターフェースはApple Mapsと異なり、必要なコントロールをメインのナビゲーション画面に 見える形で常時 配置している
- 検索とズームのコントロールを隠さず、地図の機能性と使いやすさを損なわない
- 初心者により滑らかで簡単な体験を提供する
- Buick LaCrosseの地図ズームは物理ノブで実装されており、時計回りで拡大、反時計回りで縮小する単純な操作を提供している
- ミッションクリティカルなシステムの大半は、隠されたコントロールではなく、見えて持続的で、システム状態を示すコントロールに依存している
- 設計者は、高度に訓練されたオペレーターであっても、特定の行動を実行したりアクセスしたりする方法を記憶せず、すばやく操作する必要があることを認識している
消えるコンピューティングと隠されたコントロールの違い
- Mark Weiserは1991年、コンピューティングが背景へ消え、人間とほとんど相互作用せずに作業を実行する disappearing computing を提示した
- Donald Normanは The Invisible Computer で、技術は見えず隠されているべきだと述べた
- 自動車のエンジンコンピューターは環境変数と運転条件を継続的に測定してエンジンパラメーターを自動調整し、ユーザーがオプション画面を見なくても期待した結果を提供する
- しかし、意図的にユーザー操作を隠すことは、NormanとWeiserが述べた方向とは異なる
- 必要な瞬間にコントロールが現れるか、機能を自動で実行できるならコントロールがそもそも現れない方式であるべきだ
- エンジンコンピューターは、車がよく走ってほしいというユーザーの意図が比較的明確である
- スマートフォンの懐中電灯のように、ユーザーがいつ必要とするかを自動的に判断しにくい機能は、コントロールが見えるか、強いアフォーダンスを持つべきである
設計者が再確認すべき原則
- 商用インターフェースの設計者は、隠されたコントロールの使用を再検討し、機器の機能に十分 knowledge in the world だけでアクセスできるようにすべきである
- コントロールの発見可能性は、今なお重要なインターフェース設計原則である
- 新しいインターフェースで隠されたコントロールが増えている現象は、機能が見えないためにコンピューター利用がより難しかった時代へ戻る退行に近い
1件のコメント
Hacker News のコメント
ほとんど米国上院議員に立候補できる年齢に近い Toyota に乗っているが、車内のすべての操作部は常に見えていて、ラベルが明確で、指先でも区別できる。
バッテリー交換のような日常的なメンテナンスのせいで操作が妨げられることもない。
これほど簡単に再現できる設計は、最低限の工学的能力に近いものなのに、自動車メーカーはこの水準すら満たせないことが多く、合理的に見れば自分たちの仕事ができていないということになる。
「すべての操作部が見える」のではなく、運転中に必ず必要な操作部が見えていてアクセス可能であるべきだ。
座席の高さ調整レバーやボンネットを開けるラッチのような重要度の低い操作部は、隠れていてもアクセスさえできればよく、インターフェースを効率的にするためには微妙で主観的な選択が非常に多い。
こうした設計プロセスは決して些細でも単純でもなく、それを軽く扱う態度そのものが、自動車メーカーがこうした配慮を無視するようになった原因の一つだと思う。
今では小さなボタンやノブを大量に製造して組み立てるより、タッチスクリーンを1枚作るほうが簡単で安い。
自分の車のひどいタッチスクリーン UI と別れることになっても、まったく惜しくないと思う。
以前の電子レンジは両親が留学に行くときに買ってくれたもので、20年以上使い、40代になるまで動いていたが、ダイヤルが緩くなり外観も古びたので買い替えた。
新しく買ったものは今どきの方式でボタンが大量についているが、正直どんな機能なのかも分からず、出力の強さ1つと時間、せいぜい解凍機能くらいで十分だ。
工学、品質、使いやすさ全般についてのもっと広い話だったが、父の見方では、会社は最初はエンジニアによって運営され、数十年後には管理職が、その次にはマーケティングが運営するようになったという。
次が何かは分からないが、誰もがあらゆる段階で AI に尋ねるようになり、意思決定が偶然 AI によって行われる「何もない」状態かもしれず、今のマーケティング主導の世界よりはましかもしれない。
アプリや OS がユーザーインターフェースのアフォーダンスを隠すのは偶然ではないと思う。
ユーザーを縛りつけるためのアンチパターンであり、ソフトウェアが成長の飽和点に達して、新規ユーザーの流入より既存ユーザーの離脱防止が重要になったときによく現れる。
私たちが使うソフトウェアの大半を、Google、Apple、Microsoft、Meta のようなまさにその立場にある企業が作っていることも偶然ではない。
インターフェースを隠すとユーザーが離れにくくなるというのは直感に反するかもしれないが、デバイスを「使う」対象ではなく「知っている」対象に変えるため効果がある。
予測できない方法で端からスワイプしなければ必須の作業にならないことを覚えてしまうと、新しい携帯電話に移ってそれをまた学び直さなければならないという考え自体が怖くなる。
Google、Apple、Microsoft、Meta の製品については「複雑で肥大化したインターフェース」という不満もよくあり、空の VS Code 画面を見せて、インターフェースがほとんどない Vim 設定より複雑だと不満を言う人たちもいる。
フラットデザインとミニマリズムはしばらく流行していたし、/r/unixporn や Linux ディストリビューションをカスタマイズする人たちも、ミニマリズムのためにアプリの操作部を隠すことが多い。
最近 GNOME を使ったことがあれば分かるだろうが、操作部の大半が隠された最小限のインターフェースは、ある種の人たちが好む特定の美意識でもある。
「ノイズ」を隠して、必要なときに探せばよいと感じる人も多く、必ずしもマニュアルを掘り返さなければならないわけでもない。
ユーザーにそのインターフェースを試す気を失わせることがある。
Apple のインターフェースはすべてがそのボタン1つから始まるような感じで苛立たしく、設定にどう入るのかもよく忘れるので、Android のほうが自然に感じる。
Android はロックインの役割を果たしたが、Apple は自ら損をした格好だ。
Firefox のいら立たしい再設計や GNOME などがこれに当たる。
画面スペースを別の用途に使うためにインターフェース要素を隠すのは理解できる
でも、要素を隠しておきながらそのスペースを空けたままにしているインターフェースもあって、その理由は分からない
例えば IntelliJ では、プロジェクトツリー上部のアイコン群がそうで、現在アクティブなエディタタブのファイルへプロジェクトツリーの選択を移動する小さなターゲットアイコンがある
画面上の秘密の位置を知っていて、空白部分へマウスを移動させないと、魔法のようには現れない
なぜわざわざこんなものを実装するのか、その根拠が気になる
視界に刺激が多すぎると注意力が攻撃され、集中が途切れると感じるため、現在の注目対象でないものは消えるか、少なくとも目立たなくなってほしいと思う
逆に航空機のパイロットのような人たちは、すべてのインジケーターがすぐ見え、すべての操作部が手の届くところにあるのを好み、焦点を簡単に切り替えられる
デフォルトの IDE 設定は異なる好みの間でバランスを取らなければならないので、必然的に妥協になるし、一部のツールは「おやすみモード」や「エキスパートモード」のように、詳細度をあらかじめ構成したスイッチを提供している
設定の奥深くに戻すオプションはあるが、これがデフォルトだというのは本当に理解しがたい
携帯電話、タブレット、ノート PC、デスクトップの画面は、これまでになく大きくなっている
1984年の初代 Macintosh は 9 インチの白黒低解像度画面で、当時はグラフィカルインターフェースがなじみのないものだったという理由もあっただろうが、Apple は極めて限られた画面、演算、メモリ資源を犠牲にしてでも、明確さ、可視性、発見可能性を選んだ
画面が大きくなってからは、こうしたスペースのコストはほとんど無視できるレベルになった
「ユーザーインターフェース」ではなく「ユーザーエクスペリエンス」と呼ぶようになってから、道具としての役割よりもユーザーの感情状態を気にするようになり、機能より形が先に立つようになった
今では「持ち方が間違っている」とまで心配しなければならないが、実際には機械は人間に仕えるためにあるのであって、その逆ではない
少し前、車に閉じ込められたが、キーフォブのボタンが作動しなかった
ただ鍵を使えばいいではないかと言えるかもしれないが、まずキーフォブの中に隠された鍵があることを知らなければならず、車のドアには鍵穴が見えないので、ハンドルの一部を外さないと鍵穴が現れることも知らなければならない
重要な自動車の操作部を隠すのは敵対的な工学であり、現代の自動車体験全般の中でもそれほど珍しいことではない
マニュアルはラジオ局の変え方だけを教えるものではなく、安全情報や問題が起きたときにどうすべきかも載っている
バッテリーが上がっても車を開けられるという事実すら知らない運転者が、安全最大積載量のようなことを考慮するとは信じがたい
駐車場を出て30分離れたホテルに着いてからリモコンが壊れていることに気づき、すべての荷物は車内に閉じ込められていた
物理キーは必ずあるはずだとは分かっていたが、鍵穴を見つけられたのは、前の借り主が同じ鍵穴を探そうとしてドアハンドルをひどく引っかいていたからだった
物理キーのない車を受け取ってすぐ最初に思った疑問は「バックアップの選択肢は何で、どう動くのか」だった
自分が所有する物についての基本知識は難しくない
「デザイナー」という名のアーティストたちが UI の決定を掌握すると、こういうことが起きる
彼らは発見可能性を犠牲にしてでも「すっきり」見せたがり、アフォーダンスが人に学習させることを忘れている
飛行機のコックピットのように、専門知識が必要で操作部が多くても、すべてにラベルが付いている例とは対照的だ
必要な大きさの2倍はあり、ひとまとめにされているので、どのインスタンスが何なのかを見るにはマウスを乗せなければならず、実際に目的のウィンドウへ切り替えるにはさらにクリックしなければならない
サムネイルだけで見分けなければならないが、すべてのターミナルウィンドウは同じに見える
Windows NT から Vista までの方式、つまり Web ブラウザのタブのようにアイコンとラベルを一緒に表示する方式こそ、コンテキスト切り替えのためのデスクトップ UX の頂点であり、GNOME はそのようなタスクバーすらまともにレンダリングできない
特定の状況に慣れた専門家は視覚的密度への許容度がはるかに高いが、彼らにとってそれは密集しているのではなく、意味のある情報だからだ
しかし、たいていの人はほとんどのスマホアプリをそこまで慣れた状態で使ってはいない
モバイル設計では、多くの機能を提供しつつも、ユーザーが快適さの適正ライン付近にとどまれるよう段階的に開示する必要があり、そのため何かを隠し、何かをより深い階層で見せるという妥協が必要になる
モバイルと OS の設計がアフォーダンスを減らしすぎたことには同意するが、専門ツールでないなら飛行機のコックピットは良い指針ではない
スマホは 747 ではないし、パイロットでない一般人が飛行機のコックピットに入れば、無数の操作部に圧倒されて何が何だか分からない
インターフェースデザイナーたちは自分たちが何をしているのか分かっており、何が直感的で何がそうでないかを知っていて、複雑な機能集合を比較的単純な形に収める方法を芸術の域まで磨いてきた
デザインの訓練も受けていない人たちが「いわゆるデザイナー」よりもうまくできると考えるのは、成熟した研究分野に対する傲慢さと無礼に近く、実際に人々はほとんど訓練なしでもスマホをかなり上手に使っている
それ自体が現代の奇跡だ
少し話はそれますが、iPhoneがホームボタンをなくしたあとにAndroidへ移った理由の一つがこの流れです
家族の高齢ユーザーに操作を説明するのが明らかに難しくなり、「Force Touch」をようやく覚えたと思ったら、それもなくなってしまいました
新しいPixelを受け取ると、まず最初に3ボタン ナビゲーションを有効にしますが、最近はこれもUIの観点ではだんだん隅に追いやられています
アプリが下部ナビゲーションバーを前提にしていて、3ボタン ナビゲーションのより大きな余白を考慮しないため、コンテンツやテキストがその裏に隠れてしまうこともあります
例えばMS Wordで読み取り専用ファイルを開くと、保存オプションが見えません
なぜ編集はできるのに保存はできないのか分かりにくいのです
ずっと良いユーザー体験は、保存オプションを隠さず有効にしておき、ユーザーが保存しようとしたときに「このファイルはこの理由で保存できません」と知らせ、解決方法を提示することです
操作が隠れているか、直感的でないか、そもそも欠けています
いまではPixelのカメラがiPhoneのカメラを上回り、Samsungも同程度の水準なので、Appleエコシステムへ行く理由は本当にないと思います
どこにいても、大きくて明確なボタンを一つ押せば、慣れたホーム画面に戻れるからです
ただ全体としては、その誘惑にかなりよく抵抗していると思いますし、ホームボタンの廃止がUI要素を隠したものだという主張には同意しません
これは「押す」から「スワイプ」へ操作が変わったのであって、UI要素はボタンではなく画面の端そのものだと考えます
直感的か、より良いかは議論できますが、アイコンをダブルクリックしてアプリを起動したり、右クリックでコンテキストメニューを開いたりするのと似ています
どちらも視覚的な手がかりはありませんが、主要機能として常に使われ、慣れれば摩擦は生じません
Appleが新しい直感をあまりに自由に押し付けると言うことはできますし、Safariのアドレスバーをドラッグするような例には同意しますが、ホームボタンは例外だと思います
iOSには画面上に小さなドラッグ可能な円を表示するアクセシビリティ機能もあり、押すとテキストラベル付きのホームボタンと複数の便利なショートカット機能を表示できます
実際、ハードウェアのホームボタンがあった時代にも、そのボタンを摩耗させたくなくてこの円を有効にしていた人たちを知っています
それも解決策です
私たちには、キーボードショートカットとコンテキストメニューは、明確なボタンやメニューとして発見可能なコマンドのショートカット手段であるべきだというUI設計ルールがあります
そのため、私たちのアプリは古くさく見えるかもしれません
以前、画面の四隅はマウスを精密に制御しなくても素早く到達できるため、最も価値のある画面領域だと教わりました
なのでWindows 11でMicrosoftがデフォルトのスタートメニュー位置を中央へ移したのは、ユーザー敵対的だと思います
モバイルファーストのためとも考えにくく、マウス移動が当てはまらない「タッチファースト」ではあるかもしれません
おそらく設計チームが自分たちで使っている環境なので慣れていたのでしょうし、合理的なUX上の理由はありません
macOSでも、その方式はインターフェイスに害を与えます
さらに、すべてのメニュー項目には、それを実行するキーボードショートカットも一緒に表示されるべきです
ボタンにマウスを乗せたときに表示されるすべてのツールチップも、その機能を実行するショートカットを表示すべきです
初心者ユーザーが他の場所で調べなくても、自分に必要なショートカットに気づける最良の方法です
マウスを遠くまで動かしたうえで最大化するには精密操作が必要で、プログラムを大きく見ようとして失敗すると、破壊的に何も残らなくなります
フィッツの法則を見れば分かります: https://en.wikipedia.org/wiki/Fitts%27s_law
私のメタバースクライアントは、通常はすっきりした3D世界の画面を表示し、カーソルを画面の上または下へ持っていくとメニューバーと操作部が現れます
カーソルが操作部の上にある間は表示され続け、数秒後に消えます
あえて説明しなくても、ユーザーはマウスを動かしているうちに端に触れるため、自然に操作部を見つけます
現代のオペレーティングシステムが、デスクトップでもモバイルでもファイルシステムのパスを隠し続けているのには本当に腹が立つ
昔のOSXにはFinderでアドレスバーを表示する設定があったが、デフォルトではなく、最近はサードパーティ拡張なしでは不可能に見えるので、結局ターミナルを使うことになる
後でファイルを移動したり転送したりする必要があるときに、場所を見つけられなくするなんて筋が通らない
問題は、そうしたテストを行う人たちが、意図しているかどうかにかかわらず、間違った指標、つまり「初見の人がこの作業をどれだけ速く簡単に理解できるか」に最適化している点にある
マクロに見れば誤った最適化であり、短期的なコンバージョン率は上げられても、長期的にはユーザビリティ、機能性、発見可能性を損ない、そのアプリを愛して口コミで広めてくれる高度でロイヤルなユーザーを怒らせる
大きな社会的視点なしに実験室やフォーカスグループでA/Bテストやユーザビリティテストを行うと、即時的な短期KPIを上げる指標に集中し、その結果、客観的にはより悪いUX設計をエビデンスベース、データドリブンだと宣伝することになる
この20年間でソフトウェアのユーザビリティを台無しにしてきたし、本当に思慮深いUXにほとんど触れないまま育つ次の世代にも大きな害を与えていると思う
ファイルそのものより、そのファイルが入っているディレクトリを共有するほうが有用なことが多い
MS Officeにはその情報を得る方法があるにはあるが、探さなければならない
Finder → 表示メニュー → パスバーを表示
defaults write com.apple.Finder _FXShowPosixPathInTitle -bool trueUI設計が間違った方向に進んでいる兆候として、最近よく見かける**「食べ物は冷蔵庫にあります」アンチパターン**がある
ある機能をオンにするボタンを直接提供する代わりに、見当違いの場所にあるUIテキストが、別の機能を有効にするにはどの手順を踏めばよいかを教える方式だ
もう一つのバリエーションは、ボタンやメニュー項目が実際の動作をする代わりに、別のボタンへフォーカスを移したり別の場所のメニューを開いたりして、ユーザーにまたそれをクリックさせるものだ
Microsoft製品、特にVS Codeでますます多く見かける
Game Helpin' Squad: World Quester 2
https://www.youtube.com/watch?v=0Gy9hJauXns
Cursorで「Cursor => Settings => Cursor Settings」を選ぶたびに、笑いながらWorld Quester 2を思い出す
World Quester 2が大好きなので、その最も革新的な機能である「Space Inventory」をMicropolis（SimCity）のWASM版に実装した
https://micropolisweb.com/
警告：スペースバーを押してはいけない!!!! 誤って押したなら絶対にもう一度押してはいけない!!!! さらにまた押してもいけない!!!!
SimCity Micropolis Tile Sets Space Inventory Cellular Automata To Jerry Martin's Chill Resolve:
https://www.youtube.com/watch?v=319i7slXcbI
少し脇道で、年寄りの負け戦のように見えるが、どうかスクロールバーを隠さないでほしい
記事は興味深かったが、完全には同意できない部分もあった
車の地図の拡大・縮小用の物理ノブのように、ものによってはコストや現実的な制約がある
最近、新しくインストールしたアプリでトグルを押したところ、ラベルと反対の動作をした
ラベルは現在の状態を意味していると思ったが、実際にはトグルすると変わる先の状態を意味していて、変更後には明確になったものの、最も役に立たない実装に見えた
そこでも同じように曖昧だ
チェックボックスや押下状態のボタンのほうがはるかに明確だが、残念ながら「現代性」の祭壇に捧げられてしまった
切符を即時に検札済みにする機能で、間違えると費用が発生しかねなかった
スクロールバーも、狙うのにFPSの腕前が必要になるほど細くしないでほしい
Firefoxが特にそうで、標準CSSが許している問題なのかもしれない
縦スクロールはできるが、横スクロールはもう片方の手でShiftを押すよりスクロールバーのほうが便利だ
「TURN ON」なら完全に明確だし、状態を示したいなら「IS ON」もはっきりしている
「INCREASE」のように動詞が表示されていても紛らわしい少数のケースはあるだろうが、ボタンが動詞を表示しているのか名詞を表示しているのか不明瞭なUIを想像するには、かなり努力が必要だ
https://superuser.com/a/1720363
Firefoxを使っているか？