Scott Jenson's talk "Are we really going to use the same Desktop UX forever?" lit a fuse. The author picked it up and ran — not toward a product, but toward a question: why does the operating system still treat display changes as surprises, browser tabs as dumb rectangles, and files as things that live in folders? The answer, backed by decades of HCI papers the author actually read, is inertia masquerading as design. The core insight is borrowed from tmux, the terminal multiplexer beloved by power users: sessions persist, layouts detach and reattach, work is organized by task rather than by application. The author's move is to ask what happens if you promote that model from a developer tool to the entire desktop. Not as a literal tmux skin, but as a design philosophy where the OS understands that you have ten working spheres, you switch between them constantly, and the current window arrangement is a photograph of a task state — not a manual filing job. What makes this piece genuinely useful rather than another "reimagine the desktop" blog post is its deep engagement with the research literature. Henderson and Card's 1986 Rooms paper gets a proper reading — the insight that windows behave like memory pages, with 98% of time spent inside small sets and half the switching cost concentrated in the 2% of transitions. The 2004 "Stuff goes into the computer and doesn't come out" paper gets cited for the filesystem problem. WindowScape's photograph metaphor gets the best treatment: by dropping explicit grouping and letting users navigate snapshots of arrangements, it cracked the problem of windows belonging to multiple tasks simultaneously. The author identifies four structural problems cleanly. First: screen real estate changes constantly (laptop to dock to laptop, six times daily) and the OS treats each transition as an emergency. Second: people use windows in at least three distinct patterns (maximizers, near-maximizers, coordinators) and the OS optimizes for one. Third: browsers are virtualized operating systems running inside the host OS but treated as single applications. Fourth: the filesystem as organizing principle is dead — your notes live in Apple Notes, your messages in iMessage, your docs in Slack — but no replacement model exists. The piece is honest about its own limits in a way that earns trust. "I'm not a UI/UX designer. I don't know what I'm doing." But then it demonstrates something more valuable than design skill: it demonstrates the ability to read a research literature, extract the load-bearing ideas, and articulate what's missing. The Grudin 2001 finding about dual-monitor use (focal work on one, peripheral glances on the other) is twenty-five years old and still not reflected in any shipping OS. That's not a design problem. That's an incentive problem. The tiling window manager critique lands hard. These tools solved the overlapping-windows problem years ago, but they did it in a way that requires editing configuration files — which means they solved it for approximately nobody outside the developer community. The author frames this as the actual gap: not the absence of good ideas, but the absence of good ideas accessible to normal people. tmux is the proof that session persistence and task-oriented layouts work. The missing piece is the interface that doesn't require a manual. The piece cuts off before delivering a solution, which is either a flaw or the most honest move in the essay. The author is writing a prompt, not a spec. The value is in the problem statement and the literature synthesis, not in a mockup. If you want someone to build this, this is the brief.
