Scribble at 2026-07-06 06:23:27 Last modified: unmodified

さきほども起きたのでご紹介しておくのだが、会社で業務用に利用している Google Workspace で動作する Google Drive のファイルを「共有」するために、リンクをコピーしてから URL を Google Chat の「研修告知用」というスペースの投稿で貼り付けようとしたら、クリップボードにデータがない。仕方なく、再び Chat の画面から Drive の画面に戻って、「リンクをコピー」という UI コンポーネント（としか呼びようがない。こんな平べったいものは「ボタン」じゃない）を何度かクリックして、その場でクリップボード管理ツールの履歴で URL が保存されいてることを確認してから Drive の画面へ戻って URL をペーストした・・・というわけである。つまらない実務の説明かもしれないが、これは JavaScript で実装している「コピー」という機能が、いかに当てにならないクズ UI であるかという一例だ。

要するに、JavaScript で実装されている UI というものは、ブラウザ上に表示されていても、それは HTML element を CSS でレンダリングし終わった「何か」があるだけで、それが機能するためのイベントが DOM に展開されて listen 状態になっている保証なんてないのだ。よって、UI 要素が目の前にあるからといって、クリックしても動くとは限らない。僕らは、こういう不安定で期待に沿わないことも多いユーザ・インターフェイスを使っているのだ。

もちろん、物理的なボタンであろうと力学的、あるいは電気化学的な動作機構や制御機構が故障して反応しない可能性はあるから、見た目でボタンがあるとか押せる動かせるというだけで、それが動作して所定の目的を果たすという保証はない。だが、電気化学的な原因で起きるトラブルはともかく、物理的にレバーが回らないとかキーボードのダンパーが破損している状況なら、ユーザに何らかのトラブルがあるという触感なり見た目でのフィードバックがある。しかし JavaScript の UI ではエンド・ユーザへのフィードバック機構は全くサポートされていない。Ajax によるエラー制御ですら、実際には殆どの事例でユーザへのフィードバックを実装するコーダなんていないのだ。なぜか？ 自分たちのサービスが劣悪であると自ら宣伝するようなものだからである。なんにも反応しなければ、ユーザは何が原因で反応しない（反応が遅い）かについて勝手な想像をして悩んでくれる。それ自体が時間稼ぎになるというわけだ。同じく、実は Apple 製品の UI デザインにおける「ヌルヌルした挙動」は、同じ思想によるものであって、処理性能の低さを誤魔化すための UI デザインによるトリックなのである。