In my recent visits to German and Polish museums, I noticed a recurring theme: modular industrial dashboards, which I imagine have by now been all replaced by software.
I don’t know much about these – please write me if you do – but I wanted to share them anyway, perhaps for context, or amusement, or inspiration. They’re interesting design systems, and interesting interaction systems as well.
This was a very cool physical display for air traffic control, at the The Deutsches Museum in Münich:
At Fernmeldemuseum Stuttgart, these were used to monitor subway trains, or light rail. I do imagine these panels must have been interactive with all the buttons?
I like that they light up to show status:
One of the modules was a counter:
And I believe this was a way to annotate that something was… fixed, maybe? Or on its way to being fixed?
A railway museum in Nuremberg used what looks like the exact same system, and I spotted a few modules with their plates removed:
And, here’s a similar panel shown in a tram museum in Stuttgart, filled with an incredible typographical tension between DIN and the German equivalent of Dymo:
Warsaw’s train museum had a slightly different system, but similar in look and feel:
This big industrial switch toggled between day and night. I don’t know if it changed the operation of the system, or is just switched on some sort of a dark mode for the panel itself:
And this was at the DASA Museum in Dortmund, from a power plant control room:
This was by far the biggest one of the ones I’ve encountered…
…with the biggest variety of modules…
This was also the panel I showed some molly guards from before. But today I want to end at this great switch:
Don’t you just want to rotate it, no matter what it does?
I often link to John Gruber’s Daring Fireball posts with a nod, but this time around I want to offer an opposing point of view. About a month ago, Gruber linked to a Markdown editor written by Sean Malseed in 2026 for the early 1980s Macs, and commented:
I absolutely love that this exists. I don’t like the actual app at all. I guess “full screen” mode is the point of some “distraction free” editors, but I for one would never look twice at a Mac app that didn’t use windows. Full-screen mode just wasn’t a thing back then, except for games. ArtfulType is not a Mac-assed 1984 Mac app.
I posit: It doesn’t have to be. It’s not 1984, after all.
I actually really loved the creator of ArtfulType bringing back a few pieces from the future into the past: the fullscreen/distraction-free editing, the dark mode menu bar, the shy scrollbar. Those anachronisms felt exciting to me. They made me wonder: What if dark mode was invented decades earlier? What if Mac had a different windowing mechanism? What if we could do it all over again?
I recently linked to Sopwith, which felt interesting in the same way, and I thought I would expand on this and share a few favorite examples of similar projects that inspired me in recent years.
Playdate
Confession: I’m not a fan of Teenage Engineering. I find their products well-put mechanically, but lacking in thought and soul, a certain apotheosis of “capital D Design” that feels as incomplete as it is masturbatory. (Rabbit R1 was a perfect example, consumed by gimmicks and strange design decisions.)
Good news is that Playdate is not a Teenage Engineering project, and that it was actually initiated by the software company Panic, which gave it copious amounts of thoughtfulness and care. Playdate is a 2022 handheld game console, and a fun little device that’s intentionally anachronistic. Its design picks the best parts of each decade: the gadget excitement from the 1980s, the onscreen aesthetics of the 1990s, the social internet of the 2000s, the explosion of indie games from the 2010s, all wrapped in contemporary build quality.
Playdate is partly made out of metal and pleasant to hold and touch in a way no vintage gadgets ever were – this is where Teenage Engineering does deserve a credit – but sports an old-fashioned monochromatic display that seems to be harking back to the darkest years of the first Gameboy… which is very, very deliberate:
I love the black and white, 400 by 240 pixel Playdate screen. I kind of like don’t want to design in anything else anymore,” says [Panic designer] Neven [Mrgan]. “It is so freeing for me, personally, to not think about the color and not think too much about, like, even things like line weight and whatnot. ”
Playdate’s games are equally spread across time as if in a horrible time travel accident – some with simple mechanics utilizing the gimmick of a crank, others with much more modern or artful sensibilities. Many, confusingly, with both. Some also come packaged in a novel system of seasons, where the games drip onto your machine at a pre-determined rate, meant to mimic surprises and serendipities one could encounter in record and software stores of yore.
PICO-8
I’ve been profoundly inspired by this talk by Joseph White, explaining his “fantasy console” called PICO-8, introduced in 2015:
PICO-8 is Playdate abstracted away. It flips the world order on its head – emulators are known to emulate existing hardware, but what if they emulated imaginary ones? Why not imagine a gaming console that was never made?
The wild part of this approach is that it automatically gets rid of a lot of unnecessary nostalgia, focusing instead on crafting “hardware” and software precisely calibrated to achieve things White wanted them to achieve.
PICO-8 has a puny 128×128 resolution that makes Playdate feel like IMAX (although with very deliberate 16 colors), and many other constraints that would feel ridiculous even 30 years ago. They are, once again, brought back from the past intentionally – chiefly, to avoid “design fatigue.”
At the same time, PICO-8 doesn’t revel in the past – it also comes with built-in suite of tools, and support for modern keyboard and mouse for development. Its cartridges are not only a single file to allow easy distribution on the web or otherwise – they’re also literally baked into PNG files so the spreading can be even easier.
White’s software chimera works because he understands where nostalgia ends and the needs of modern development begin. PICO-8’s idiom, for example, is a custom subset of Lua, an easy-to-approach language likely familiar to many game programmers, whether they script emulators or use the free 2D engine LÖVE. Though PICO-8 initially ran BASIC to stay true to its ’80s pedigree, White switched because “Lua has a small footprint and is portable and quite fast. I think any language could have worked though, as long as it allowed the user to mess about in an unstructured way without worrying about programming style.” PICO-8 Lua feels snappy and sensible. There are just enough functions to get up and running quickly without the bulky overhead of complex libraries or object-oriented syntax. Need to draw a sprite? Provide an index and two coordinates. A circle? Coordinates, radius and color. It’s fast and friendly for programming beginners.
The conference talk above and the design of PICO-8 are dripping with intentionality; even the startup chime is meant to evoke a feeling. At some point White went as far as to consider whether his console would glitch nicely if its software was buggy, and then mentions “I designed a [more advanced] PICO-16 just to remind myself to not make that” – a really interesting technique to help him zero in on what he really wanted.
White also expressly states “I value design over content,” which is another thing his project has in common with Playdate.
PICO-8 saw all sorts of software developed for it since 2015 that you can all play online – from the absolute platforming classic Celeste, to a series of unofficial “demakes” like WarCraft III, complex games like SlipWays, or even tools like PicoCAD. The hardware is confusingly powerful enough for Poom (a clone of Doom) to exist, but then there’s also tons of delightful tweetcarts, cartridges whose code used to fit inside a single tweet.
Infinite Mac
PICO-8 started as an emulator for an imaginary thing. Infinite Mac, despite emulating really well-known Macs from the 1980s and 1990s, can also inspire in its imagination.
Made by Mihai Parparita in 2022, Infinite Mac is all about focusing on the right details. Emulators of vintage Macs existed before and, as a matter of fact, Infinite Mac uses those very emulators under the hood. But the glue that holds them together is Infinite Mac’s real and wonderful contribution.
If you’ve ever used an emulator, you know they are usually incredibly unpleasant to set up. You have to find a ROM that fell off of a back of a truck, set up the drives and the media inside, and fight with the poorly-designed settings and a UI that often feels like an afterthought, with the whole thing often feeling more rickety than the very 40-year-old machine it’s trying to approximate.
Infinite Mac awaits you in the browser, literally two clicks away counting this one (there is no step three!). It doesn’t show all the possible options, but curates the most useful machines instead.
The emulation is precise but Infinite Mac also – and this is my favourite thing – breaks the fourth wall in some truly useful ways. You can drag a file into the emulator and it just does the right thing with it. You also set up a magical folder that connects to the host machine both ways, in a way that was simply impossible to do back in the day.
There’s also a CD drawer underneath, and a wonderfully seamless integration with Macintosh Garden’s library of vintage software.
It’s the same story as with Playdate and PICO-8: a lot of intentionality and effort and cherrypicking so you get the best of an earlier experience without the worst of it. Pick a Mac, and use it without worry; Infinite Mac keeps the Macs both faster and more reliable than they used to be. (In a beautiful repudiation of modern software practices, I have heard of people who launch Infinite Mac to write in old word processors not just because they’re simpler, but also because they’re faster than the modern native apps.)
Parparita occasionally writes about the project on his blog; those entries are rather technical, but sometimes also highlight various design considerations (I particularly enjoyed the NeXTSTEP entry).
Epilogue
I was at the Vintage Computer Festival West recently, and for the first time I noticed how many young people were there. This got me excited. It’s one thing to revisit those old machines just to relive your own years of (likely imagined) glory, but yet another to see people see them as inspiration: to encounter computers that were simpler, unencumbered, unenshittified, and with software you could understand, remix, and own.
I hope some of those people find inspiration in the past without succumbing to it as a whole, pushing and pulling on it like the creators of Playdate, PICO-8, and Infinite Mac did.
I think that kind of push and pull is important, especially today. I don’t love using Google Sheets, but my favourite spreadsheet is not Excel 97, either. My favourite spreadsheet is some hypothetical anachronistic version of Excel 97 that also has modern high-dpi typography, and a ⌘K command palette, and today’s trackpad gestures, and support for AVIF and HEIC.
Of course, there is immense value in studying the past just so we know what was already made or just explored, what is worth being aware of, and what could deserve remixing. But it’s not great to get stuck in history.
When you venture out to do some time travelling, you get the booklet with all the rules: don’t interact with another version of you, don’t flirt with your mother, definitely steer away from any butterflies. I love that these projects, and others like them, ignore all those rules.
On her blog, Lea Verou makes a case that each user-facing website dark-mode toggle should only ever show two options, but in a smart way.
The challenge is that any dark mode toggle needs to actually accommodate three options: dark, light, and the default “whatever the system says” (which can be always dark, always light, or change with the time of day). Many toggles simply pass that complexity onto the user:
I want to get something out of the way: I don’t think Verou’s articleas an article is fully successful. I feel like it spends a great amount of words to explain something not entirely as complex, and even the interactive playgrounds felt slightly too rigid and altogether confusing. If you care about (interactive) explainers, it might be an interesting case study in and of itself.
But I am very much much on board with the proposal and the line of thinking it represents. Verou suggests a “smart” dual state toggle, which still allows the website to follow the system, but shoves the complexity of the “whatever the system says” branch into the crevices between visible UI. Here’s how I understand it:
The smart toggle only has two options: light and dark. Mechanically, clicking or tapping the toggle brings you to the opposite option. Simple.
If your new option is the opposite of system (e.g. you switch the page to dark mode if your system is in light mode), it will stay in that theme forever, no matter what the system does in the future.
If your new option is one that currently matches the system, it will then continue following the system in perpetuity (e.g. it’s back to the default behaviour).
This toggle will feel compromised, and you might immediately find some rare use case it doesn’t fully support – maybe attached to an imaginary user, or even an internal user giving you feedback in person. But Verou is absolutely correct in her insistence to fight through that:
Tri-state toggles are implementation-driven UI. One of the most common UX mistakes is designing UI around the underlying data model instead of user goals. Good interfaces abstract away the underlying model and expose a model that aligns with user goals (unless of course these happen to coincide, which is rare).
Now, it’s just a dark mode toggle. It might not seem like a difference between a smart dual state toggle and an explicit tri-state toggle is that much. But:
“Whatever the system says” is not just one extra option. It’s also one extra weird option. It doesn’t feel like the other two. It’s seemingly repetitive. It’s often unclear what it does before clicking. It’s not obvious where to put it in order. Verou doesn’t mention this in her post, but even just seeing the word System next to Light and Dark feels complicated. (Auto is slightly better.) The cognitive load here might be larger than it seems.
What is an interface if not a collection of a million challenges, each one seemingly insignificant on its own? Trivial things add up. One compromise here and one cheap decision there, and soon you’re talking real money.
Thinking deeply about something like this gives one practice for dealing with complexity elsewhere, and facing even more difficult challenges where the stakes are higher and the compromises larger.
A similar example might be that of PC keyboards in the late 1990s, which also exposed system complexity and pestered people with Power/Sleep/Wake keys:
Computers do not do that anymore, simply having a smarter singular power button, piped to a more sophisticated logic underneath.
Actors are overwhelmingly diurnal, overtime is expensive, and film emulsion struggles with limited light, so since the dawn of time Hollywood has been using a technique called “day for night” – shooting during daylight, and then darkening and blue-tinting in post to pretend it was night time all along:
Now that you know it, you might spot it in movies that use it poorly: the ones that darken everything too much, the ones where too bright of a sky gives it away, or the ones where the shadows appear lunatic in the wrong sense of the word.
In UX design, you can day-for-night your dark mode as well – long before proper dark mode was a gleam in someone’s bloodshot eye, operating systems allowed you to invert their screens – but the limitations of that approach are apparent very quickly:
Sure, black becomes white, white becomes black, and grays swap places. But in real life, shadows do not get brighter at night, and photos do not behave that way, either.
The “proper” answer is not to do anything automatically and to go all out with a perfectly hand-crafted dark mode that’s an equal partner to light mode: a distinct set of semantic colors, a new strategy for shadows and layering, and a second set of visual assets like icons and images.
Here’s a comparison of naïve inverting and a proper dark mode:
A lot of apps do that for colors and shadows, some even providing multiple dark mode flavors…
…but visual assets is where things get tricky. Yeah, vector graphics can use the same swappable color variables as CSS text and elements, although in practice it is quite a bit of work and from my experience SVG doesn’t make it very easy, either (here’s an example from my essay):
But when it comes to bitmaps, they are usually left alone. Overtime is still overtime, and producing each bitmap twice is a lot of effort.
Since swappable variables don’t exist in this context, the only automatic approach method left is inverting, but a) inverting an already- dark image can make things lighter,and b) inverting things like photos makes them look creepy and mixes up all the colors:
What explains the last part? This has to do with the fact that inversion happens in the RGB color space. R becomes 1–R, and the same for G and B.
Everyone who’s into gradients knows of a similar challenge that results in the gray dead zone effect. This is fixable if you convince a gradient to traverse through a different space instead, or coax it through the RGB space on a more… bespoke path (this is e.g. what Figma gradient plugins do).
Could we invert in HSL or OKLAB color space, then? Yes, we could. They both look similar – this is HSL:
You can see how the photos get inverted now, but the colors remain the same! Still a curiosity, perhaps, but the bottom of the above screen shows this technique feels really interesting for diagrams, screenshots, and things of similar nature. Here’s another bitmap that looks pretty great inverted this way:
Unfortunately, while there are techniques and plugins to do gradients in non-RGB color spaces, I am not seeing a lot of options for inversion customization anywhere. Neither the graphics apps I use, nor CSS offer anything here.
But there’s a trick: do a regular invert and then rotate the hue halfway through. Through the magic of math, this is the same as inverting just L in the HSL space, which means the colors are preserved. This is actually achievable in graphic programs…
…and, more importantly, available in CSS as a filter: instead of invert(1), use hue-rotate(180deg) invert(1).
So, if you have dark-on-light diagrams, bitmapped text, illustrations, or other similar things – or even vector graphics you cannot throw dark mode variables at – this day-for-night trick that can get you places very cheaply. (And for other bright bitmaps, just reduce the brightness by 25%.)
It’s the same as with Hollywood trickery: remember to add a bit more nuance in the right place, and you get something that feels bespoke for the price of only light – please excuse the pun – manufacture.
Before dark mode became mainstream in the late 2010s, there were two main customers of dark UI themes: programming and photo/video production. But, to the best of my knowledge, they arrived at that preference from two very different angles.
Programmers’ fondness for dark mode was a result of decades of bad display technologies. The early CRTs were so awful, the burn-in risks so real, and the pixels so fuzzy and headache-inducing, that you wanted to see as little screen light up as possible – hence, defaulting to black background for everything computers did.
These challenges were there all the way through the 1980s, really, teaching generations of coders that computers meant light letters on dark backgrounds. Games moved away from being “in space” or “at night” as quickly as they could, text editing and spreadsheets went for paper-like livery soon after that, but programming never meaningfully existed on paper, and so the skeuomorphic pull wasn’t really there.
(Have you ever heard of a term “reverse video”? What’s kind of confusing about it is that its meaning was reversed around that time.)
AV professionals took a different route. They already had CRT calibration, gray walls, and monitor hoods so that light from outside wouldn’t contaminate content colors – and when computer UI started appearing on those CRTs, it was likewise best to keep it as dark and as neutral as possible.
Today, things are more flexible. Many people prefer one theme over the other for any of many legitimate reasons, most leave dark theming synced to daylight, and display technology can handle all themes so well that it jumped ahead of our brains, which still have some interesting asymmetries in processing light shapes next to dark ones.
As users celebrated dark mode appearing in popular apps and services in the 2010s, some had to catch up the other way: Apple TV added light mode (for some reason) in 2017, and Affinity apps celebrated new light UI option just earlier this year.
Most programming text editors still default to dark, but allow you to switch; as a software category they were probably the first to fully embrace color theming.
But what led me to writing this post was a delightful discovery today of this setting:
Why, of all apps, would iOS Photos allow you to switch to dark mode, and only while editing to boot?
I think this might be because of the above tradition of pro AV apps, where we learned it’s good for visuals to be surrounded by black; a little nod to its earlier professional roots – similar, perhaps, to the story of the Clear button in calculators.
But I had two more thoughts. First, for all the reasons above, to me at least dark mode still has connotations of “professionalism” and toggling the option makes me feel I’m a bad-ass pro whenever I’m editing a photo. I wonder if others also feel that way, too.
Second, dark mode looksdifferent. Dark UI only when editing means it’s easier to spot whether I’m editing or just browsing, and be ever so slightly better oriented.
(In general, apps today are much more similar-looking, and I’m surprised neither iOS nor Android doesn’t allow you to switch the theme per app, just so it’s easier to know where you are as you move around quickly.)
This iPhone UI for dark/light theme is doing something clever:
Ostensibly, there are two modes here:
automatic, for when you want the theme to match the time of day
manual, for when you want to keep one of the themes forever
But check out what happens when I am in automatic mode, but toggle the theme by hand anyway:
More rigid or less thoughtful interfaces would either disable manual changes when you’re in automatic mode, or understand a manual theme switch to mean “I want to turn off automatic.”
But here, iOS is quietly putting me in a temporary hybrid mode: a manual theme override until the theme catches up with what automatic mode would do, at which point it snaps back (I’m resisting very hard calling this rubber banding) to automatic mode.
What I think is clever is that this isn’t presented as a third mode – which could be more confusing than helpful – but the design simply reuses the existing Options field to set the expectations.
One has to be careful designing in shades of gray; once you enter the space you really have to commit to it and see it through. My go-to analogy is symmetry vs. asymmetry. Symmetry in visual design is usually easier and safer. If you venture into asymmetry you have to make an effort to make it work. The highs of asymmetry will be higher than anything symmetry can provide, but getting to those highs can be arduous and sometimes might even be impossible.
I thought this particular example was really nicely done and the team found a great balance. (I think Apple’s previous shade of gray – “Disconnecting Nearby Wi-Fi Until Tomorrow” – ended up slightly less successful.)
As a Mac user I naturally focus on that platform, but Windows 11 has had its own share of problems – and that list has grown so vast it’s hard to know where to start.
So let’s pick it up at random, with a post by Thom Holwerda with a great title “You can actually stop Windows Explorer from flashbanging you in dark mode”:
One of the most annoying things I encountered while trying out Windows 11 a few months ago was the utterly broken dark mode; broken since its inception nine years ago, but finally getting some fixes. One of the smaller but downright disturbing issues with dark mode on Windows 11 is that when Explorer is in dark mode, it will flash bright white whenever you open a new window or a new tab. It’s like the operating system is throwing flashbangs at you every time you need to do some file management.
I find the videogame-inspired nickname darkly – I’m sorry! – funny, but the problem is real. It looks like this (video via windowscentral.com):
It’s not a problem unique to Windows 11 – just the other night I saw this on Wikipedia on my iPhone, exacerbated by the delayed reaction of Liquid Glass buttons spastically adapting to the changing background:
But there is something about this that feels a notch more important than other visual and layout issues.
I think this is because dark mode is a contract – we’ll lower the brightness, and we’ll let your eyes rest. There’s a physiological part to it: a sudden flash of light when your eyes are not expecting to it can be actually physically painful. I think it’s worth thinking about it and futureproofing and sanding dark-mode views especially at their edges: loading states, error messages, signing in and logging off areas. The “flashbang” analogy is very apt, and especially so on bigger screens.
