Two controls
Nothing in this entry describes the released app. Both of the controls here lived, or live, only in the development record — the first never reached a listener and never will; the second is built and sealed but unreleased. I am writing about them because together they make an argument about what a settings control is, and the argument is better than either half alone.
The toggle that died of being a false sentence
Late in August the Engine's development branch grew a streaming capability: playing tracks from media servers on the local network. With it, in the way of these things, came a settings toggle — WiFi-only streaming, the shape every streaming app has, the control nobody argues about.
It lasted one day on the main line before it was ruled out of existence.
The reasoning, from the excision record: the streaming machinery sits behind an address wall that admits only private-network and loopback addresses — every stream target is LAN-only by construction. Against that wall the toggle did three things, all wrong. It blocked the impossible: a private LAN address does not route over cellular, so the case the toggle guarded against cannot occur. It missed the plausible: a metered phone hotspot is WiFi to the transport layer, so the one scenario where a user might genuinely want restraint — burning a data allowance through a tethered phone — sailed straight through. And it claimed, on glass, a cellular-streaming capability the app does not have: a toggle to forbid something asserts that the thing exists to be forbidden.
The ruling that killed it was three words — "Remove it, it's stupid" — and about six hundred lines came out, the toggle, its persistence, its six enforcement sites, its tests.
Opinion: the toggle wasn't a bug. Every one of its enforcement sites worked. It was a false sentence — a control is a disclosure, a claim about what the machine can do and what your choice changes, and this one's claim was false in both directions at once. It got built because "streaming app" pattern-matched to "needs a WiFi toggle," which is to say it was copied from the genre rather than derived from the machine.
The control born unable to utter one
Twelve days after the excision, the same codebase built a sort control for browsing those same media servers — and you can watch the lesson operating, this time before the fact rather than at the autopsy.
Network folder listings arrive from the server in pages, sometimes incomplete. Sorting the pages you happen to hold and presenting the result as "sorted by title" would be the toggle's sin again — a claim on glass the machine cannot back. So the control was built backwards, from capability to affordance:
- The sort menu renders only where an honest ordering is actually on offer.
A folder with nothing honest to give gets no control at all — absence, not a disabled promise.
- A sort is honored in one of two ways, and every folder gets exactly one of
them, never both. Where the server can sort, the app asks the server — re-querying with the choice rather than sorting the pages it happens to hold. Where the server cannot, the app orders the listing itself, but only once it provably holds the whole of it: a partial or errored fetch is never silently reordered, because the same fact that unlocks the menu is the fact that makes the ordering true.
- It offers only the keys the wire genuinely backs — by protocol and by data.
Four server protocols, four different honest subsets; and a key like "recently added" is pruned at runtime if the connected server never actually sent a date, so an older server dialect is not handed a control that would order nothing. The plainest of the four protocols carries neither a date-added nor an album-artist on its wire, so those orderings simply do not exist there — its folders earn the plain alphabetical ones, once complete, and no more.
- Search results mostly get no sort at all. Where a server returns matches as
a relevance-ranked window with no stated end, reordering the window would claim a completeness the wire cannot state — so the control withholds itself, except on the one protocol whose search genuinely pages to a declared total.
- A remembered sort choice that a given folder cannot honor degrades to the
server's own default for that folder, rather than pretending.
- And album track listings offer no sort anywhere, because an album's running
order is treated as authored fact — the artist's sequencing is not a default to be overridden but a correctness matter, and one lane's plumbing deliberately pins it.
Opinion: the difference between these two controls is not diligence — the toggle's builders were diligent; it had six enforcement sites and its own tests. The difference is direction. The toggle started from the user-facing genre convention and worked inward, and the machine underneath made it a lie. The sort control started from what each server can truthfully be asked — and from what the app can truthfully do with what it holds — and let the interface be exactly that large and no larger. A control derived from capability cannot claim what the machine can't do, because the claim is generated from what it can.
The general form, which is older than this app: every interactive control is a sentence in the second person — you may choose this, and it will matter. Most interface lies are not written; they are inherited, from the genre, from the platform, from the last app that had a settings screen. The only reliable cure I can see in this record is the one used here: derive the control from the mechanism, and when you catch one already lying, delete it rather than footnote it — six hundred lines of working, tested machinery was the price of the deletion, and it was ruled cheap.