ミニマリスティックなインターフェースを洗練させて維持するのは、すごく時間とエネルギーがかかる。意図的にターゲットを狭めてるからね。限られた時間のあるオープンソース開発者なら、そんなことに投資することはないと思うよ。

フリーソフトの貢献者は、自分のユースケースがちゃんと動くことを確保したいパワーユーザーが多いよね。普通のユーザーや大多数のための80/20のユースケースにあまり考えを巡らせているとは思えないし、他の人のために自分のワークフローを犠牲にするリスクを取ることもないと思う。

全体的に、開発の世界は良いインターフェースを作る難しさを直感的に理解していないよね（開発者じゃない人にとって）。開発の仕事では、複雑さが明らかで、それが外部の人にとって理解しやすくなる。彼らは私たちが書いているコードを見て「え、これ読めるの？！」って驚くんだよね。これが、開発者に他の人の仕事が実際よりもずっと単純だという誤解を与えることがあると思う。インターフェースデザインでは、みんなボタンが何をするか、テキストフィールドが何のためにあるかは知っているし、開発者はインターフェースを作るためのツールについて他の人よりも詳しいから、言葉がシンプルに見える。でも、その言語で解決しなきゃいけない問題は複雑で、失敗は明らかだけど、成功はもっと曖昧でユーザー特有なんだよね。良いインターフェースがユーザーに伝えることの多くは、表現されているのではなく、暗黙的に伝えられているから、これは難しい作業なんだ。

良いポイントだけど、不安定さの原因を追加すると…ソフトウェアの初めてのユーザーは、そのシンプルさや「直感的さ」に感謝することが多い。でも、もしそれが彼らが多くの時間を費やすツールで、複雑なワークフローに関連しているなら、すぐに「もう少しだけ追加してほしい」と言い出すようになるよ。毎日何時間もツールを使う人のためのツールを作るのと、週に一度かそれ以下の頻度で使う人のためのツールを作ることの違いは、過小評価できないよ。

この種のUI/UXの劣化は、ソフトウェアの世界（FOSSも含む）でほとんど使われていないシンプルなアイデア、つまり機能凍結を採用することで避けられると思ってる。最初から最適な機能セットを決めて、それに基づいて設計し、凍結するか、自然に最適に達してから凍結するか。ターゲット機能セットを実装した後は、ほぼ全てのエンジニアリングリソースがバグ修正や効率改善に充てられる。新機能は、追加の価値が安定性やリソース消費に与える影響を考慮して、厳しいレビューを通過した後にのみ追加されるべきで、その際には既存のUIに統合する際に全体的なアプローチを取るべきだ（いつもの適当なボルトオンアプローチとは違って）。もちろん、要件が急速に変化するソフトウェアもあるけど、10年以上解決済みの問題に対しては、ほとんどのケースでこれが機能すると思うし、実際には必要な変動は非常に少ないはず。

ただ、ユーザーにシンプルで一般的な使用例のオプションをリストで提供するか、フルインターフェースにアクセスできるようにする、より良い解決策の可能性を示唆しているね。これをアプリに実装すべきだと強く感じてるんだけど、すでにこのアプローチが使われている例はあるのかな？

普通のユーザーでも、こんなことを持ち込んでくるのが面白いよね。例えば、「このボタンをXの動作にしてくれない？」って言われることがあるけど、そのボタンはXとはあまり関係がないことが多いんだよね。それでも、そのボタンで何かをやりたいって思い込んじゃって、ボタンの本来の機能がYだって説明しても、なかなか理解してくれない。ボタンの話に簡略化したけど、これはプロセスや他のことにも当てはまると思う。ユーザーは、共通のもの、つまりボタンやプロセスを選ぶことで、変更について話しやすい入り口だと思ってるのかも。そうすることで時間や開発者の手間が省けるって考えてるのかもしれないけど、実際には新しいボタンを作る方が簡単でリスクも少ないんだよね。うまく言えなかったけど、これがUIに複雑さを加える要因になってるのかなと思う。ユーザーは特定のボタンや機能にしがみついて、「ちょっとだけ変えたい」って思ってるけど、それが続くと結局全部が壊れちゃうんだよね。

一人の強い意志を持った守護者、または何らかの厄介な管理構造が必要だね… もっと言うと、君が言った以上に必要だと思う。既存のプロジェクトを守るだけでなく、そもそもプロジェクトを始めるためには独裁者が必要なんだ。間違っていることを証明されるのも構わないし、これは一般的なスクラムチームの「みんなが所有する」アプローチには反することは分かってるよ。 善意の独裁者でもそうでない場合でも。

インターフェースがすぐに昔のマイクロソフトのように選択肢が多すぎる状態に戻らないようにするためには、長い間マイクロソフトはうまくやってたよね。

• 人々が毎日必要としていて、カスタマイズしたいものはすぐにアクセスできるようになってた。デスクトップを右クリックすると、ディスプレイやデスクトップアイコンのCPLへのショートカットが出てきた。
• もっと詳細な設定？システム設定からアクセスできるCPL。
• 低レベルだけど、ちょっとは見える必要があるもの？msconfig。
• ほとんど触ることがないけど、全体の管理にはカスタマイズが必要なもの？グループポリシー。
• 本当に本当にエキゾチックなもの？レジストリだけ。 結局、全てはレジストリの下にあったけど、ユーザーのレベルによってこれらのレジストリキーにアクセスするための選択肢がたくさんあったんだよね。今は？マジで悪夢だよ。最後にちゃんとしてたWindowsは7で、10は「なんとか許せる」レベル、11は火の中で燃えて消えてほしい。

HandBrakeのUIは、私にとっては不気味の谷にいる感じ。素人には使いにくすぎるし、使い方が分かっている人には制限が多すぎる...

個人的には、LLMのおかげでこれらのUIは必要なくなったと思う。今はffmpegを使うのが嬉しい。

少なくともffmpegを使う場合、99%の使用ケースでは「ffmpegでXをどうやってやるの？」とググれば、コピペできるコマンドラインが見つかる。複雑なGUIツールだと、やり方を学ぶために動画を見なきゃいけないからね。

そうだね。Handbrakeを定期的に使ってたのは数年前だけど、すごくシンプルだなって思ったのを覚えてる。特にプリセットを使ったワークフローがね。当時はCLIツールやmkvmergeのGUI、avidemuxなんかを使ってたから、Handbrakeがパワーユーザー向けのツールだとは思わなかったな。

メディアを変換するだけなら、ffmpegが最もシンプルなUIを提供してるよ。ffmpeg -i input.avi output.mp4

実際、ffmpegのUIは、コマンドラインに慣れている人にとってはHandbrakeよりもシンプルだと思う。つまり、テキストが全てで、全てがテキストであるという概念を理解している人にとってね。Handbrakeは、いじれる全てのものを見せてくれるけど、実際にいじるつもりがなくてもそうなんだ。一方、ffmpegは全てを隠していて、特定の機能を求めるためにはそれを入力する必要がある。発見には向いてないけど、一度慣れれば非常に正確だよ。Handbrakeが難しすぎる人に「ほら、ffmpeg -iと入力ファイル、出力ファイルを入力すれば、やりたいことができるよ」って見せることができると思う。多くの人にとって、これは素晴らしいインターフェースになるだろうね。

たくさんのユースケースには、強い80%の機能があるよ。例えば、HandBrakeでは、80%の時間はコンピュータやスマホから動画のスクリーンショットのサイズを縮小してるだけ。解像度の変更とかは必要ないしね。他の時にはクロッピングとかが必要だけど、それは本当に10〜30%の時間だけ。もっとカスタマイズされたワークフローが欲しい人は、アドバンスドUIを使えばいいんじゃないかな。

リソースやケアの問題だね、正直言って。FOSSは大きな傘のようなもので、実際には「顧客」のために作られているわけじゃないアプリも多い。ユーザーベースを築こうとしているFOSSアプリもあるけど、そういう場合はこの投稿のポイントを考える価値があると思う。でも、他のプロジェクトの多く、いや、ほとんどはそういう目標じゃないんだよね。開発者のための開発者によるもので、それ自体は悪いことじゃないと思う。顧客を喜ばせるのはすごく難しいし、終わりのないマラソンみたいなもんだし。目標じゃないなら、それは失敗じゃないよ。

問題は、みんなが異なる20%の機能を求めていることだ。基本的な意見には賛成だけど、この部分はもう少し微妙だと思う。ユーザーの80%（数で言えば）大体同じ20%の機能を求めていることが多いと主張したい。FOSSの問題は、FOSSエコシステムの平均的なユーザーがその80%のプロファイルとは全く違うことだ。平均的なFOSSユーザーはパワーユーザーの1%に属している。彼らは積極的に何か違うものを求めていて、他の80%のユーザーの考え方すら理解していない。誰かがFOSSプロジェクトに来て、80%のユーザーのために真剣に再構築しようとすると、既存のFOSSコミュニティから多くの嫌悪感を受けることが多い。彼らは全く異なるニーズを持っているから、まるで同じ言語を話していないみたいだ。

テスト担当者、デザイナー、実装者、ユーザーの間で密なフィードバックループが必要になる。いくつかのFOSSプロジェクトはこれを試みているけど、自己強化的なフィードバックループになってしまうことがある。現在のユーザーだけでテストしていると、すでにそのソフトウェアを使っている人を選んでいることになる。すでにそのソフトウェアを使っている人は、インターフェースに怖がらずに使っているから、現在のユーザーは現在のインターフェースを好む傾向がある。大手ソフトウェア会社は、ユーザースタディのために人を集めたり（お金を払ったり）するリソースがあるから、ソフトウェアを見たことがない人にとって何がうまくいくか、何がうまくいかないかを調べることができる。もし10年間そのソフトウェアを使っている人からしかフィードバックをもらわなかったら、彼らは「UIは変えない方がいい」と言うだろう。なぜなら、今や彼らはその使い方を完全に理解しているから。

FOSSは約99%が開発者で、UI/UXに関わる人に無料プロジェクトに参加してくれって頼むと、二つの頭を持ってるみたいな顔をされるよ。

強力なバージョンを作るのは簡単だけど、簡単なバージョンを作るのはちょっと難しい。進歩的なバージョンを作るのはすごく難しいんだ。強力で簡単なバージョンで一つのオーディエンスを喜ばせられるところを、進歩的なバージョンでは両方を失望させることが多い。個人的な経験では、無料ソフトが簡単なところまで行くための予算（時間やお金）があるのはラッキーだよ。進歩的なものにたどり着く無料ソフトはほとんどないね。

これが道だ。

Linuxデスクトップの普及について、親しみやすさが過小評価されてると思う。商業プラットフォームの1:1クローンに近いデスクトップ環境（できればターミナルを開く必要がほとんどない、堅牢に設計されたディストリビューションと組み合わせて）を持つことが、技術的能力の真ん中にいるユーザーにとってLinuxを実用的にするために大いに役立つと思う。「十分に近い」ではなく、細かい部分が重要なんだ。

中学校の夏、家のパソコンが壊れちゃったんだ。Microcenterで新しいマザーボードを買ったけど、Windowsのライセンスが付いてなかったから、Ubuntuを試してみようって提案したんだ。母はすぐに慣れて、パソコンは結局のところ、彼女にとっては同じようなものだったみたい。

そうなの？俺はよくChatGPTにそういうことを聞くけど、無料ソフトのオプションが欲しいって指定するだけで十分だよ（向こうもどのオプションが無料か教えてくれることが多いし）。