TmuxをOSにする

最近、Scott Jenson氏の「Are we really going to use the same Desktop UX forever?」という講演を見ました。彼は素晴らしい話し手で、非常に明瞭かつ簡潔です。もし機会があれば3時間以上でも喜んで聞けるようなスピーカーです。ウィンドウ管理に関する講演でこれほど褒められるのは珍しいことです。講演の全体的なポイントは、「AppleとMicrosoftはデスクトップOSの分野でこれ以上革新しないだろうから、未来のデスクトップがどう見えるべきかを決めるのは私たち次第だ」というものでした。私は、実際の状況はもっとニュアンスがあると考えています。彼らはアイデアを試していますが、非常に保守的なのです。Jenson氏が指摘するように、私たちが「コンピューターの仕組み」と見なしているものの多くは、何年も前に存在しなくなったハードウェアのための回避策でした。では、なぜ私たちはまだそれらのトレードオフを受け入れているのでしょうか。 はっきりさせておきますが、私はUI/UXデザイナーではありません。自分が何をしているのか分かっていませんし、これを作るスキルもありません。これは主に思考実験として、そして願わくば他の人にもこの同じ問題について考えてもらうためのきっかけとして作成しています。しかし、私は他人の悪い選択に苦しんできた経験があり、それがこの分野で要求される資格のほとんどであることが判明しました。TL;DR: 私が欲しいのは「tmuxがOSになる」ということです。ただし、普通の人が使えるtmuxです。私はtmuxを常に使っており、それは素晴らしいですが、スクロール可能でセッションが永続し、デタッチ可能でタスク指向のシステムの素晴らしい体験を一般の人々に届ける方法はあるのでしょうか。 2026年のウィンドウ管理におけるハイレベルな問題は何でしょうか。 この問題を以下のコンポーネントに分解できると思います。 私の画面領域は常に変化しており、以前よりもずっと広くなっています。私は1日に約6回、ラップトップ画面からデスクトップモニターへ、そして再びラップトップ画面へと移動します。大きなモニターや複数のモニターを使用している場合、重なり合うウィンドウは、すでに十分なスペースがあるため意味をなしません。まず、1つの大きなモニターは、2つの小さなモニターとは全く異なる体験です。私は2つのモニターを1つの大きな unbroken screen として使用するのではなく、一方を「重要度の低い静的なコンテンツ」（ToDoリストや仕事のチャットツールなど）用にし、もう一方の「プライマリ」モニターでターミナル/tmux/ブラウザを使用するというように使い分けています。しかし、ウィンドウはどちらかのモニターに「属して」います。Grudinは2001年に、人々が2つ目のモニターをまさにそのように使用していることを発見しました。つまり、片方で集中的な作業を行い、もう片方で注意を払うのです。25年前です。OSはまだ、どちらのモニターがどちらの役割を果たしているのかを認識していません。そして、ラップトップをドックから取り出すと、すべてが1つの画面に収まり、作業を続けるために十分な画面領域を確保するために手動でウィンドウをドラッグしてリサイズします。これが実際にどれだけの時間を無駄にしているかは分かりませんが、無駄にしているように感じます。OSはディスプレイの変更を、1日に6回起こる予定されたイベントとしてではなく、予期せぬ出来事として扱います。 人々はウィンドウを全く異なる方法で使用します。私たちは3つの異なるグループの人々のために設計しようとしていますが、ほとんどの現代のOSは最初のユースケースのみを最適化しています。 一部のユーザーはウィンドウを最大化します。各ウィンドウが画面のほとんどを占め、Command + TabやDockなどを使って大きなウィンドウ間を切り替えます。より広い画面領域の価値は、主にこの1つの大きなウィンドウをさらに大きくできることです。一部のユーザーはニアマキシマイザーです。1つのウィンドウが画面のほとんどを占めますが、ステータスやチャットなどの情報をちらっと見るための、より小さなウィンドウを1つ以上持っています。最後に、画面上のすべてのウィンドウを注意深く調整するユーザーがいます。ほとんどすべての人が「プライベートウィンドウ」と「パブリックウィンドウ」を持っています。パブリックウィンドウは整列させて永続させることに問題はありませんが、他の人から特定の情報を隠したい場合は、それを別のウィンドウに隠します。私が文句を言っている人々は、私が四半期ごとの数字を提示する相手でもあります。ラップトップをディスプレイに接続すると、私の画面全体が見えるようになることを、私は決して覚えていません。これは私だけのプライベート対パブリックの問題だと思っていました。しかし、これは2004年に「Revisiting Display Space Management: Understanding Current Practice to Inform Next-generation Design」で測定されています。同じ3つのタイプ、同じパブリック/プライベートの分割、20年前です。これらが全く新しいアイデアではないことが分かります。リンク。 ブラウザはミニオペレーティングシステムです。2026年、ほとんどのソフトウェアはブラウザタブで実行されるということに、誰もが静かに同意しています。これらのWebアプリケーションは、歴史的にローカルアプリケーションが担ってきた幅広いユースケースをカバーします。私のデスクトップOSはブラウザを通常のアプリケーションとして扱いますが、実際にはホストOS内で実行される仮想化されたOSに近いものです。 ブラウザ内のタブとブラウザのウィンドウは、他のアプリケーションと同じレベルの複雑さを含んでいます。タブは、従来のアプリケーションとともに、作業ストリームに関連付けられています。私はTerraformのドキュメントを参照しながら、ターミナルでVimを使ってTerraformを書いています。しかし、タブと作業の関係は曖昧です。同じドキュメントタブは、コードを書いているときと、チケットの更新を書いているときの両方で使われます。タブが一度に2つのタスクに属することを許可されるべきか、あるいはもっと簡単なことが行われているのか、という点がまさに私が研究から外れるところです。WindowScapeに会ってから、この点に戻りましょう。 「ファイルシステム」という概念は、ますます弱い概念になっています。Apple Notesの私のノートは、私のファイルシステムではなく、Apple Notesに属しています。私のテキストは、私のDocumentsフォルダではなく、iMessageのデータベースにあります。TeamsやSlackのコンテンツは、手動で「取り出す」までそれらのアプリケーション内に存在し、取り出す際にはコピーを作成しています。FirefoxはPDFを喜んで表示してくれますが、macOSにそれを要求するアクションを取らない限り、PDFはmacOS上に存在しません。 多くのエンジニアはそれを読んで、「すべてのアプリケーションにすべてのファイルのために同じストレージシステムを使わせることはできないだろう、君は狂っているのか！？」と思うでしょう。私はそれを提案しているわけではありません。実際、弱いファイルシステムは利点になるかもしれません。2004年のCHI論文に、「Stuff goes into the computer and doesn't come out.」という、私が作り話をしているわけではありませんが、そのようなタイトルの論文があります。それは2004年のことで、私たちは全く解決策のない全く同じ問題を抱えています。リンク。 これがウィンドウの問題である理由は次のとおりです。Windows 95とSystem 7（私の記憶が遡れる限り、ほぼ同じくらい古い）以来、コンピューターはチェーンのように機能してきました。何かがファイルを書き込み、ユーザーがそれにアプリを開き、アプリがそれを書き戻し、ファイルが誰かに送られ、繰り返されます。そのチェーンのすべてのリンクは、ファイルがOSから見える場所に存在することを前提としていました。そのすべてのリンクは、現代のOSではすべて壊れています。 人々は何を試したのでしょうか。 この問題に気づいたのは私が最初ではありません。一部は解決されましたが、私が望む方向とは異なる方向で解決されました。一部は解決されましたが、一般の人々のために解決されたわけではありません。 私は、他の人が常に引用しているドキュメントから始めました。Henderson, D. Austin and Stuart K. Card. “Rooms: the use of multiple virtual workspaces to reduce space contention in a window-based graphical user interface.” ACM Transactions on Graphics (TOG) 5 (1986): 211 - 243. 興味深いことに、80年代でさえ、現在のウィンドウ管理システムがそれほど良くないというかなり明確な理解がありました。彼らが議論していたデザインは、現在の状況と比較してかなり先進的なものでした。HendersonとCardは、オペレーティングシステムの専門家がメモリを測定する方法でウィンドウの使用量を測定しました。画面はRAMです。閉じられたウィンドウはディスクにスワップアウトされたページです。そしてウィンドウは、ランダムに触れられるわけではありません。ユーザーは少数のウィンドウ（2つから10個）の中に留まり、そのセットがタスクです。プログラムは時間の約98%をこれらのセットの1つの中で過ごし、実行コストの約半分はそれらの間を切り替えるのに費やされる2%の時間に発生します。Roomsの設計全体は、要求される前に次のセットをプリロードすることでした。彼らはこれを「ユーザーの知識フォールト」を減らすことと説明しました。これは、