...HNの「unvote」や「undown」フィードバックは特に残念だね、共通の接頭辞があるから。何かにアップボートするたびに、間違ってクリックしないように「unvote」や「undown」を確認するんだ。

アイコンは小さくしすぎない限り、認識するのが簡単で早いと思う。特に、位置が変わらなければ、長期的にはアイコンの方が楽だろうけど、物事が変わったりボタンがたくさん必要な状況では、言葉の方が勝つかもね。

実際に認識できる絵があるアイコンについてはちょっと疑問だけど、最近のアイコンはスタイライズされすぎてて、ただの線が曲がったり壊れたりして、運が良ければたまに点が並んでるだけ。マウスオーバーでもテキスト説明がないと（カーソルがないタッチスクリーンでは…）発見はほぼ試行錯誤だし（権限が本当にダメージを与える可能性があるならロシアンルーレットみたいなもんだね）。プログラマーが何を伝えたかったのか、既存のサポート質問を探して頭をひねるしかないよ。

03/04/2026は3月4日？それとも4月3日？国際的なオーディエンスがいるなら、誰かを混乱させることになるよ。できればYYYY-MM-DD形式を求めてほしい。

生年月日を入力するために年のリストをスクロールするのが嫌だな。自分の死を直視させられる感じがして。

いやいや、40年分の月を遡って自分の誕生日を探すのって、人生の儚さや加速する感じを考えるいい機会になると思うよ。

これらの大半は、俺は200歳くらいだって言ってるよ。

ソフトウェアはもうツールじゃなくてメディアだね。メディアには変なインセンティブがたくさん組み込まれてるし。

モバイルエンジニアの俺が、ステークホルダーに「シャワー中に思いついたランダムなインターフェースアイデアを実装するだけじゃダメだよ。デザインの意見が必要なんだ」って言うと、みんなの無表情がすごい。 「なんでできないの？」って聞かれるけど、俺は一貫したUXと実際に使えるIAの重要性を理解してるから。開発者と同じように、（ちゃんとした）デザイナーも問題を解決するんだから、もっと早く自転車を求めるのはやめようよ。

サイボーグ的な自然選択が時間をかけてこれを解決するはずだけど、ソフトウェアシステムのランダム変異の頻度は生物システムよりもずっと高いんだ。これの平衡ダイナミクスをモデル化するのに興味があるな。

著者は「イディオムはシステムフレームワークの使用から来ている」と言ってるけど、アプリがウェブ上で一貫性がない理由についてはほとんど間違ってると思う。例えば、「この非均質性は2つの理由による」ってセクションの理由には驚かされた。まず、彼が言う「デスクトップ時代」って、実際にはデスクトップ時代じゃなくてWindows時代だったんだよ。Windowsがほとんどのデスクトップを支配してたし、WindowsとMacの間にもたくさんの不一致があった。だから、Win32 APIに関して言えば、開発者は基本的に一つのやり方しかなかった、もしくは少なくとも一番簡単なやり方だった。開発者は「デザインのイディオムに従っていた」わけじゃなくて、「Windowsで簡単にできることをやっていた」んだ。ウェブは最初はドキュメント共有システムとして始まり、徐々にアプリシステムに変わっていった。やり方の「一つのデフォルト」や「一番簡単な」方法なんてなかったし、その中でBootstrapにみんなが一斉に集まった時期もあったよね。つまり、君の言ってることには完全に同意するよ。「標準的なイディオム」をいくら持っていても、使いやすいデフォルトのフレームワークを提供している会社が一つもなければ、常にいろんなやり方が存在することになる。

Bootstrapは良かったね。

ウェブはインタラクティブなドキュメントのために設計されたもので、デスクトップアプリケーションのためじゃない。レイアウトエンジンは組版からインスパイアされていて、テキストにしか意味がないコンポーネントも多いし（、、、...）。動的データ（リストの仮想化）やカスタムコンポーネント（キャンバスやSVGはその点であまり良くない）にも対応してない。> 現代のデスクトッププラットフォーム向けの開発はひどいし、フレームワークなしのウェブもそこで使われてる。PMが自分の製品を「ブランディング」したがってるのと、開発者が短期的に自分のために最適化してるのが関係してると思う。ユーザーのためじゃなくてね。

ネイティブボタンの高さは変えられないんだよね。もちろん、できるんだけど、いろんな状況で分かりにくいし、簡単じゃないんだよね。

ウェブには何もない。自分で作らなきゃいけなくて、せいぜい半端なものになるよね。そして、現代のデスクトッププラットフォーム向けの開発がひどいから、フレームワークなしのウェブも使われてる。これが根本的な原因に感じる。もっと具体的に言うと、ウェブにはイディオムがあるけど、そのイディオムは1980年代に取り残されていて、ウェブはハイパーリンクと時々の画像、データテーブル、送信可能なフォームの集まりだと思ってる。これが「お気に入り」リストやウェブページ上の任意のテキストを選択できる機能の起源なんだ。ウェブアプリは、アプリケーションUIを完全にゼロから作らなきゃいけないだけじゃなくて、全く違うことをしたがるドキュメントUIの上にそれを乗せなきゃいけない。現代のブラウザはそのイディオムを抑え込んで「戦うのが楽になった」けど、取り除いたり改善したりはしてないんだよね。

それだけじゃないんだよね。自分の使ってるオペレーティングシステムの動きに慣れてくると、開発者としてはアプリもその環境に合わせて動いてほしいって思うんだ。ウェブではそれが崩れちゃったんだよね。ウェブページはちょっと違う「ボックス」環境だったから。そして、モバイルの登場で完全に崩壊した。デスクトップの慣習がタッチや小さい画面にはそのまま適用できなかったからね。（これも君の言ってたことに戻るけど）モバイルOSの開発者たちは、同じような慣習を導入するのをあまり真剣にやらなかったんだ。例えば、長押しはデスクトップの右クリックの代わりに使える一貫した表現になり得たのに、最初はそれが実装されず、後からも一貫して推進されなかった。シェアメニューや省略メニューと競合してしまったからね。

面白いね。エンターで送信するフィールドで改行を作るのはシフト＋エンターだと思ってたから。これがこの問題のバラバラな性質を示してるよね。

Slackでは、エンターを改行に戻すオプションがあるから（俺はそうしてる）、他のソフトはそんなに優しくないよね。Grafanaはシフト＋エンターで送信する新しい方法を導入したけど、いつも混乱しちゃう。

チャットインターフェース以外で、エンターがテキストを送信するのはいつなんだろう？

Slackだとさらに厄介になることがあるよ。Markdownフォーマットをオンにすると、Shift+Enterで改行できるんだけど、3つのバックティックで始まるマルチラインのコードブロックにいるときは、Enterで改行、Shift+Enterでメッセージ送信になるんだ。これがいいアイデアだと思った人の気持ちは分かるけど、実際は全然ダメだよね。

Teamsは両方やってるね。基本的にはEnterで送信、Shift+Enterで改行だけど、フォーマットツールを開くと切り替わる。少なくとも、どのキーコンボで改行になるかを示すメッセージはあるけど、たまに混乱することもある。

数十年前、ReturnとEnterはその理由で別々のキーだったんだ。Returnは改行を入れるため、Enterは入力を送信するため。今は一つのキーに減ったから、伝統的なGUIのルールでは、マルチラインやマルチパラグラフの入力ではEnterは他のコンテキストのように送信せず、改行（または段落の区切り）を入れるけど、Ctrl+Enterで送信するんだ。チャットアプリでは、単一段落の内容が一般的だから、これが逆転することが多い。良いアプリはこれを設定可能にしてるね。

マルチライン入力をサポートするものは、Enterで送信するんじゃなくてボタンを押して送信するべきだよ。そうすれば誰でもすぐに使えるし、何も学んだり覚えたりしなくて済む。次に、ユーザーがCtrl+Enterでより早く入力できることを学びやすくするために、ツールチップや隣接するテキストで宣伝すればいい。75%の人が早くできることを学んでも、100%の人が簡単に使える方がいいよね。

俺のイライラするポイントの一つは、ウェブフォームを送信するためにEnterを押しても、もう普遍的には機能しなくなってきてること。代わりにタブで送信ボタンに移動して、（ウェブページによっては）スペースかEnterを押さないといけない。先日、10年ぶりに新しくセットアップしたmacOSマシンでSafariを使ったんだけど、もちろんHNを見たくて、最終的にはコメントを書きたかったんだ。いろいろ書いて、筋肉の記憶でタブを押してEnterを押したら、コメントが「送信された」代わりに何が起こったかというと、macOSのSafariではタブがアドレスバーにジャンプするらしくて（???）、その後Enterを押すとページがリロードされて、書いたものが全部消えちゃった。正直、数分後にまた同じことをやっちゃったから、Safariでのブラウジングは諦めてFirefoxをダウンロードしたよ。