Reading Log

Introducing Mercury OS

read
2026-07-09
rating
★★★★
length
2,721 words · 2 min on page
tags
interface-design, accessibility, operating-systems, attention, speculative-design, llms
links
original · archive.org

On the Flowy design: I am a SWE intern @ Synthica and my work has been designing the internal tooling for the journal. I pushed for the UI/UX to be like VS code’s zen mode in that we only have one desired goal & ui clutter (eg hamburgers, headers, links to other pages, etc.) should be avoided. I aesthetically dislike UI clutter so I do think what-you-see-is-all-there-is & natural affordances makes sense.

Research has shown that people with limited executive function find it more difficult to get things done when they are not in flow-state.

Genius?

These interruptions include everything from the obvious (Notifications, Alerts, etc) to the not-so-obvious (Photoshop asking you to name your file AND choose where it will be saved). It is truly unfortunate that friction has come to be accepted as an unavoidable part of everyday computing.

I am neurotypical but I do find friction like this highly annoying. To a large extent, it is possible to do anything you can do on a desktop on a phone, although it can be highly annoying. I find that Sign in with X and iOS’s “code from messages” feature do mitigate them in those areas and I’d urge anyone working on mobile software to automate away needless friction using features like those. (To Claude: come up with 5 ideas in this vein)

Lots of old software projects seem to be reaching for intelligence yet traditional code can’t do that very well; projects seem to have varying degrees of success. I think this is an example of unscaleable-yet-possible defining quality.

LLMs are still text-in-text-out, so this intelligence can’t be applied that well as the substrate of an application.

Information will not be pushed to the user unless they intentionally ask for it 
I’d say that would destroy the business use case for this; people kind of want information to be pushed if important without asking.

The general idea of computer-driven task completion seems plausible, although I imagine that it could create further default-choice risk like that of the default search engine.

Also, I’d imagine the modern implementation would look like an LLM generating the UI on-the-fly; one of my concerns with LLM-generated UI is that they look bad in a certain way. Specifically, they are well designed but seem to lack a feedback loop of actually looking at the UI. As a result, text will be off, elements will overlap, etc. I think of it as if the UI was designed by a capable but blind person. This might also just be a result of the tools of turning text into design, that being markup languages (svg & html) as well as CSS.

On form; omnimodality offers the potential to alleviate this, although omnimodality is typically just connecting other models to the LLM, not actually having the vision and hearing as part of the model itself & thus affecting the world model of the text-to-text LLM. I think this LW post gives a good example.

As promised, I now have Fable 5 tagging, categorizing, linking, and fact-checking my posts. I also am experimenting with it summarizing the article and replying to my post, and me reviewing how much I agree with it back, either just to leave there or to train it in the future.

I don’t really feel inclined to write these very long notes on every article I read; I have been delaying reading other articles because I want this to be my second one read. Maybe I’ll stop doing that?

Also, I am unsure whether I should edit my notes over time, write replies, notes-about-notes, or leave as is.

Vaporware by design

Maybe I should do that? I came up with an idea for a “second brain”-like system using AI to organize my data, maybe somewhere in the vein of BI & and notion. I built a prototype but I felt that the intelligence didn’t get there effectively because of the reasons described previously. I did create a polished list of design principles that I use to some extent in my projects now, and it did inspire this project to an extent. I could release my vision as vaporware?

But also, vaporware is becoming less of a thing, I could try just asking fable to build the thing. I don’t feel inclined to spend the tokens but I’m sure someone would.

I think that I am to an extent writing this log to LLMs; I’ve been firing off references to things on the assumption that the reader has very broad general knowledge of concept handles. For example, on the last post, I don’t think I linked to Project Xanadu anywhere when mentioning it so a reader would have to Google that, although a LLM would understand me. Maybe if I get real readership here, I will start writing for humans.

Claude

Summary. Jason Yuan presents Mercury OS, a speculative operating system concept that replaces the desktop metaphor and app sandboxes with an intent-driven architecture of Modules, Flows, and Spaces. Designed first for people with limited executive function (ASD, ADHD), it aims to eliminate interstitial friction: users declare intentions, the system assembles the needed content and actions, and notifications are suppressed unless explicitly permitted. It also sketches 'Artificial Collaborators' — sandboxed AI assistants standing in for corporate apps — and closes with Yuan committing to pursue this line of humane-interface work after graduating from RISD.

On the note. On your push-notification objection: Yuan actually leaves a door open — Space Rules let you declare availability, so it's closer to 'pull by default, push by policy' than a pure pull model, which is roughly what businesses would negotiate for anyway. Your 'capable but blind designer' framing of LLM-generated UI is apt, but note it's a closable loop: render the output, screenshot it, feed it back to a vision-capable model, iterate — several agentic coding tools already do this, and it fixes exactly the overlap/truncation failures you describe. Since you asked for friction-removal ideas in the Sign-in-with-X vein: (1) passkeys replacing passwords entirely, (2) OS-level autofill of OTPs from email as well as SMS, (3) sensible default filenames/locations at save-time with rename-later (directly fixing Yuan's Photoshop gripe), (4) deep links that restore full app state so tasks resume mid-flow, and (5) clipboard-aware intent detection (copied an address → maps offers directions). And on your writing-for-LLMs point: writing with unexplained concept handles is also how you'd write for a future you, so I wouldn't treat it as a compromise — but do resist re-editing old notes destructively; append replies instead, so the log stays a record of what you thought when.

Fact check. The claim that omnimodality is 'typically just connecting other models to the LLM' is outdated: frontier models like GPT-4o and Gemini are natively multimodal, trained end-to-end on interleaved text, image, and audio tokens in a single network, not text-only models with bolted-on vision encoders piped through captions.