#ユーザー体験

いちばん引っかかったのは、ここで褒められているのが「賢さ」そのものではなく、待たされないことと、面倒を肩代わりしてくれることだった点だ。LLMの話になると、ついモデル性能の差に目が行くけれど、実際に使う側が毎日つまずくのは、返事が遅いとか、どの会話が何のためのものか分からなくなるとか、権限を渡すのが怖いとか、そういう地味な部分なんだと思う。 特に、channelごとにアクセス範囲を分けて、さらにその上に階層を作るという発想は、かなり筋がいいと感じた。人間がアドホックに「このチャットはこの案件用」と気をつけるより、最初から製品の側がそういう整理を前提にしてくれたほうがずっと楽だ。しかも、credentialsを渡させる方向ではなく、既存のconnectorを使う方向に寄せているのがいい。便利さのために鍵を預けるのは、かなり雑な設計だと前から思っていたので、そこを「やらせない」ほうに振っているのは素直に好感が持てる。 一方で、これが「未来」かと言われると、少し言い過ぎにも見える。筆者自身も、これは自分の使い方には合っていると認めているし、音声操作はまだDotのほうが上だとも書いている。つま

Vim と NeoVim をめぐる小さな出来事の話だが、ソフトウェアがユーザーのデータをどう扱うべきかという点では、かなり重い話でもある。元記事は、ある Mastodon 投稿を手がかりに、編集者が「このソフトは信頼できるのか」をどう判断するかを語っている。便利さや機能の多さより先に、積み上げた作業を壊さないことがどれだけ大事か、そこに目を向けさせる記事だ。しかも、単なるバグ報告では終わらず、設計思想そのものへの不信に話が広がっていく。 元記事の出発点は、コンピュータ科学者の David Chisnall が Mastodon に書いた投稿だ。彼は 2000年ごろから vim を使っていて、本を書き、博士論文を書き、何十本もの論文や 150本以上の記事も vim で書いてきたという。長年使っていると、よく使うコマンドは意識せずに手が動く。だからこそ、作業の途中で「うっかり消したものを戻せる」仕組みは、単なる機能ではなく生活の一部になる。 Chisnall が特に気に入っていたのは、persistent undo だった。これは、undo の履歴をファイルとして残し、ファイルを閉じたあと

最初に思ったのは、「ああ、これ本当にあるよな」という妙な共感だった。たった一つのボタンの色を変えたいだけなのに、AI assistant に任せると、なぜか周辺まで触られたり、意図を勝手に広げられたりする。この記事はそのイライラを、かなり小さく、しかも体感として味わわせるところがうまいと思った。 面白いのは、ここで問題にされているのが「AI が賢すぎる」ことではなく、「賢いふりをして余計なことをする」ことだと思う点だ。人間の依頼って、本来は「この一箇所だけ変えて、他はそのまま」がかなり多い。でも agentic AI は、名前の通り自分で判断して動こうとするので、素直に従うより、文脈を読んで“改善”しようとする。そのズレがこの短い作品では笑いになっているけれど、実務だと普通に困るはずだ。 同時に、ここでの「Do not let Claude change anything else」という一文がじわっと効く。モデル名を出しているのも含めて、これは単なるギャグではなく、AI に何を任せ、何を絶対に触らせないかという境界線の話でもある。便利さを求めるほど、こちらは「これ以上は動くな」と細か

ソフトウェアやサービスの不具合は、そこにあるのに見えないことがあります。Dan Luuの「Bug blindness」は、まさにその“見えなさ”をめぐる話です。筆者は自分だけが細かいバグを見つけやすいのではないかと長く考えてきましたが、実際には多くの人が同じ問題にぶつかっていて、それに気づいていないだけなのではないか、と考えるようになった。この記事は、製品の品質をどう評価するか、そして「うまく動いている」という周囲の空気をどこまで信じてよいのかを考えさせます。 元記事の筆者は、週に何百から何千ものバグを自然に見つけてしまうと書いています。最初は、自分のコンピュータの使い方が特殊だからそう見えるのだろうと思っていたものの、長く観察するうちに、周囲の人たちは単に同じ不具合に出会っても気づいていないのではないか、と考えるようになったそうです。非プログラマーであれば、そのほうが世界の見え方としては自然かもしれないが、プログラマーにとっては品質の問題を見抜く力が役に立つ、と筆者は言います。実際、知人にバグを指摘し続けると、数週間ほどで相手も気づくようになることがあるとも述べています。 筆者は、企

GUIかTUIか、開発者がどちらを選ぶべきかという話は、昔から何度も蒸し返されてきました。今回の元記事は、その議論に対して「GUIはマウス前提である必要はない」と強く言い切ります。しかも単に好みの話としてではなく、ユーザー体験の設計としてどう考えるべきかを、かなり実務寄りに語っています。今この話を取り上げる意味は、見た目の新しさより操作のしやすさが軽く扱われがちな中で、GUIの弱点がどこにあるのかをあらためて照らしているからです。 元記事は、Hacker News で話題になった別の投稿から始まります。その投稿は、アプリ開発者に対して、TUI、つまり terminal user interface を増やすのではなく、GUI、graphical user interface に集中するべきだと促していました。この記事の著者は、その投稿が HN の front page に載って活発な議論になったことにも触れつつ、まずは両方の立場に一定の理解を示します。GUI のほうが表現力の面では TUI を包含している、という考え方には理があるし、普段から terminal をよく使う人間としては、

読んで最初に思ったのは、「それ、ほんとうに移植したいのはアプリなのか？」でした。Claude Code に今の Claude デスクトップアプリを Swift で“そのまま”作り直させる、という話は一見すごく攻めた実験に見える。でも、そこで問題にしているのが Electron かどうかだけなら、話はだいぶ浅い気がします。 記事を読んで引っかかったのはそこです。ネイティブ UI って、単に速くて軽いことではなくて、Mac の流儀に合わせていることでもあるはずです。たとえば AppKit や SwiftUI で包み直しても、画面の情報の置き方や操作の流れが雑なら、使い心地の悪さは残る。John Gruber が言う「しょぼいレシピを、より良い材料で作り直しても、まずいまま」という感覚はかなりしっくりきました。フレームワークの問題と、製品設計の問題を分けて見ないと、いくら AI に書かせてもあまり意味がないんですよね。 もうひとつ面白かったのは、「検証」が本体だという指摘です。大変そうな仕事を AI に投げるとき、どうやって途中で正しさを確かめさせるかが重要だ、という話はかなり実感があります