Unsung
An
interesting 10-minute video
from gruz about
Super Mario Bros. Remastered
, a modern Super Mario fan remake with surprising depth that puts Nintendo’s own efforts to shame:
What I liked about it is that it’s wrestling with the idea “How do you improve on something considered perfect?” and touches upon the important area we cover occasionally here on this blog: when is software
finished
There is also another interesting angle. Even though the game requires original game ROMs to work, it’s still in a very, very gray area:
[…] Once you strip it down, this thing is built around Nintendo’s world: the Super Mario Bros. name, the characters, the visual identity, the level concepts, the branding, the whole presentation. And the more ambitious it gets, the riskier it feels. Once a fan project starts offering not just a remake, but extra modes, editor tools, custom-level browsing, ratings, and a growing user-generated content scene, it stops looking like a small tribute and starts looking like something operating in Nintendo’s lane.
(I didn’t expect to see the original Super Mario game to come up so often on this blog – I just added
a tag for it
– especially since I don’t have any personal reverence for it. But it seems it’s Super Mario and Doom specifically that became timeless pieces of software that keep being resurrected, revisited, and remixed, over and over again.)
Apr 23, 2026
games
32
piracy
software
evolution
13
super
mario
bros
54
An interesting flavour of a
molly guard
that can only happen in onscreen interfaces is “occasionally moving things out of the way to mess with the user.”
The messing-with-the-user part is, ostensibly, for their benefit. Making something not appear in the usual position, or not behave the usual way, becomes a speed bump, cancels out motor memory, and forces a conscious reaction rather than flying through the interface on autopilot.
The simplest example is dialogs that ask about dangerous actions suspending the “default action happens when you press Enter” behaviour:
(There is a way to continue the dialog on the right using the keyboard alone – but it’s only via ⌘R and not the default, breezy Enter.)
Another version is swapping buttons or showing them in an otherwise unusual order:
But remember when I said “can only happen in onscreen interfaces?” Well. The apotheosis of this very idea, spotted in a New York alley, proves otherwise:
It’s a Hirsch ScramblePad, inconsistent very much by design, a login mechanism where every time the digits get put in a different place.
The idea is meant to help with two problems:
It makes it harder for someone standing behind to learn your code from just watching your movements, as it abstracts the movements to be one step away. (The strange visual filter is meant to make the viewing angle as narrow as possible, too.)
It prevents uneven wear and tear of the buttons, which people could use to guess your code:
I understand “ScramblePad” was the original product (
here’s the patent with some nice illustrations
), and the name got
genericized
since. Here’s competition, MIWA Random Tenkey – once probably so much more futuristic, today equally quaint:
One can occasionally see more modern versions today:
But back to our beloved screens, where some banking web apps copied the idea:
And even recently, Motorola touted it
as a feature on their phones
I’m not a security expert, so I won’t try to opine how effective those things are. I tried to research whether forcing a password out of motor memory – which these will accomplish – is ultimately better or worse, but a lot of the papers I found were inconclusive. (As always, some of the theoretically good ideas for security bounce off of human limitations and convenience: Forcing someone to remember a password might mean they will write it down somewhere, effectively making things worse.)
Apr 23, 2026
interface
design
62
security
I am a huge fan of all sorts of “recent” features in software; I think they’re extremely helpful in removing tedium, and thoroughly undervalued. A lot of our work
is
repetitive, even if it’s sad to admit.
shared one example previously
, and here’s five more.
1.
My bank’s website not only shows me the last payment I made, but also allows me to click to use the same number again:
2.
The app
Transit
has a nice list of recent destinations just below the main options:
3.
Google Maps promotes recently tapped-on items to be more visible than they would normally be:
4.
CleanShot X
offers something I have always wanted from built-in macOS screenshotting – being able to capture with one keystroke the same area as I delineated last time:
5.
Google Pixel allows you to swap the current wallpaper and three previously chosen wallpapers easily:
What unifies all of these is that “recent” doesn’t live in a submenu somewhere, treated as a second-tier pathway. No, in all of these “recent” is embedded in the fabric of normal interactions, side by side with forward-facing options. I believe this is necessary for any sort of feature like this to be truly successful.
That last Google Pixel example also shows that “recent” isn’t only for repeating something faster – here, it becomes more of a “soft setting,” without introducing a lot more complex UI and interactions that a “real” setting might require.
Apr 23, 2026
complexity
13
definitions
12
flow
24
interface
design
62
I can finally update my ancient
WarGames reference
– turns out the computers on the TV show The Pitt are also preprogrammed to show the right things on the screen regardless of what the actors are actually typing.
But you still need to flail your fingers in vaguely realistic ways, so the actors in this (spoiler-free)
share their strategies:
Apr 22, 2026
keyboard
23
I want to tell you about something that might seem oddly specific and perhaps too technical, but a) at the end of it you will have a useful phrase somewhere in your brain that will pay off one day, and b) I swear I will make it worth your while.
Have you ever seen this problem?
The screenshot on the left is fine. But there is something wrong with the one on the right. In light mode, the shadow is wispy and weird. In dark mode, things are even stranger, and the shadow is almost… a glow?
I stumbled upon this problem occasionally for
years
now – there are a few screenshots on the blog with this weird problem, even – but it was never feeling like a deal breaker. However, I finally sat down to figure it out today.
Turns out, there are two kinds of approaches to alpha channel/​transparency. The normal one we all know well is called “straight alpha.” But on the right, we were looking at “premultiplied alpha” – something entirely more complicated, where the background is baked into transparency for… reasons. Premultiplied alpha is conceptually – and often literally – dirtier, but it also has benefits: more flexibility, better filtering, sometimes better performance. As far as I understand, premultiplied alpha exists primarily in the world of video and vfx, but occasionally it rears its unconventionally attractive head in our boring static 2D world of screenshots, too.
In my case, I finally figured out this was happening whenever I’ve pasted the screenshot
from the clipboard
to Photoshop instead of Preview – for some reason, a screenshot then got an alpha channel premultiplied against white background. But I wouldn’t be surprised if it happens to some of you under other conditions, too.
So, “premultiplied alpha.” That’s the useful phrase. What was the other thing?
This is an absolutely hilarious
7-minute video by Captain Disillusion
that talks about various challenges with the alpha channel:
Captain Disillusion (or, Alan Melikdjanian) is one of my favourite YouTube educators. His work is mostly debunking fake videos – his most well-known one is
about the Cricet bracelet
, although my personal fav is
one about laminar flow
– and they’re just constantly interesting and
hilarious
at the same time.
Disillusion also occasionally does a more straightforward “let’s talk about some technical aspects of video production” episode which he bundles under a “CD/” umbrella. Here’s a handy list of all of them:
Intro to the whole series
Aspect ratio
Frame rate
Resolution
Interlacing
(and
addendum
Color
Alpha channel
Shutter speed
Blur
I am sharing this list because you should watch them all. Most are <10minutes, they are
consistently
entertaining, and even though none of them are about UX design, there is enough overlap between the two universes that you will come out of it all a lot smarter.
Pragmatically, in my case, I searched for [premultiplied alpha] + [Photoshop] and quickly learned of a new-to-me menu option: Layer > Matting > Remove White Matte. It turns premultiplied alpha back to straight alpha, and fixes the screenshot.
Non-pragmatically? If you want to
really understand
premultiplied alpha, the last thing I can do is suggest another great internet educator, Bartosz Ciechanowski, who has a
more comprehensive interactive web explainer
. There will be math. There will also be sliders. You decide.
Apr 22, 2026
graphics
humor
10
54
I moved Keyboard Maestro app to a different folder as it was running. I gather there must be some technical reason for the app to have to be
power cycled
, so I appreciated this warning, and the thoughtful bit of copywriting: “Continue” is caveated with “not recommended” so that you feel more comfortable choosing “Quit,” usually the less safe choice. I thought it was a good attempt to add the right scent to the strange options at a strange moment.
(This tradition has reportedly been started by a software company Rogue Amoeba,
which wrote about it in 2019
.)
Apr 21, 2026
errors
got
your
back
writing
I have been working on an essay about how to gently get started and have fun with keyboard customization. I am finding myself surrounded by programmable keypads…
…and I am going out of my way to try various new shortcuts and automations, big and small, just so I can write a helpful article.
In Photoshop, one of the classic dialogs I use a lot when scanning things is brightness + contrast:
It doesn’t come with a keyboard shortcut, so I mnemonically assigned ⌘B (for Brightness) to it. ⌘B is easier than using your mouse to select a menu option, but still tedious in the long run; every time I have to input brightness and contrast numbers, then click on Use Legacy which is not sticky,
then
realize that enabling Use Legacy inexplicably resets the values I just typed so I have to input them again…
…which really isn’t as much fun 20th time in a row, 20th year in a row.
So imagine my surprise when one day I invoked the dialog, and it came up looking this out of the box:
It somehow
remembered the previous settings
. How? Why? Was that a new thing? Was that a bug? Did the stars align or did they misalign? Figuring out how to make it do this every time would have save me so much trouble.
I dug deeper and figured it out. On the way to ⌘B, my fingers
grazed
the ⌥ key. This invoked a “use same settings as last time” option I never knew existed. This option would have been a lifesaver, has been there for god knows how long, and I just discovered it
by accident
. Moreover, it wasn’t just a feature of this dialog. One can hold ⌥ for many more Photoshop dialogs – a thoughtful system to make repeated tasks faster.
Damn.
This reminds me of something. I am curious if you’ve seen what I’ve witnessed probably ten times by now: once in a while my corner of the internet overflowing with awe when someone shares that on the iPhone, you can hold the spacebar and it functions as cursor control:
Inevitably, tons of people are always amazed and excited, proclaiming this is the best thing since sliced silicon wafers…
…and that always make me a little sad inside. Both this and my ⌥ story feel like failures of onboarding, of software growing with you and sharing its motor-memory nooks and power-usery crannies. If a helpful thing exists, but people don’t know about it, it feels worse than it not existing. Imagine all these interactions made more pleasant, all these hours saved, all these flow states undisturbed.
I want to spend more time on this blog highlighting onboarding and
conveyance
done well – I just shared a tiny example
a few days ago
– particularly since this feels to me like an area underinvested in. If you have a story of an app or a service doing this well, I’d love if you could share it with me so I can highlight it and we can learn from it.
Apr 21, 2026
keyboard
23
onboarding
good post by John Gruber on Daring Fireball
investigating why apps pester you with the annoying “enjoying this app?” windows and attendant semi-shady practices (choose 5 stars and you get sent to App Store, but choose anything less, and your review will get redirected to Mr.
Dev Null
).
The answer? They don’t really have a choice:
“[Steven Troughton-Smith:] Review prompts are the difference between a great app getting five positive reviews, and thousands of positive reviews. […]”
You have to play the game as the game stands, and Apple controls the game. And in the game as it stands, apps need 5-star reviews to gain traction in the App Store, perhaps especially so for apps in crowded categories. And for most apps, the only way to achieve that is through prompting. But the right thing to do, for the user experience in the app, is never to prompt for reviews.
I think it’s worth knowing about stuff like this for another reason. Absent understanding or institutional memory, any exception gets normalized and ceases being an exception. If specifically iOS apps have to do this for reasons explained in the post, this is still not an excuse for web apps or websites to indiscriminately
pester people with prompts like these
, too.
Apr 20, 2026
attention
fun blog post from Alice Pellerin
– if you can color code source code, why not try that for hex data?
This pairs nicely with a
previous post on Unsung
in that it too actively investigates what makes for useful, not just “pretty” color coding.
Apr 20, 2026
coding
colors
Among many genuinely useful deeplinks you can use to
control Raycast from afar
in a simple way, I just spotted an interesting one:
raycast://confetti
This is what it does:
Despite it being a confetti cannon and nothing more, I think it goes deeper than stuff like e.g. Asana’s “
celebration creatures
”, and it deserves recognition for three actually kinda serious reasons:
You can use it to quickly test whether you’re wiring deeplinks correctly. It’s clever the Raycast team put it at the beginning of
the doc page
; I think every API or a complex connection method should have a simple and delightful “success scenario” for two reasons: to celebrate you establishing that connection, and to have something so simple it cannot itself be misbehaving (this way you know that if you can’t get confetti to work, you for sure messed up something
elsewhere
).
Once you know how to invoke it from far away, it’s also great for testing
other things
. Sounds can be muted. In JavaScript,
console.log()
can be too buried if you don’t have a console open or visible, and
alert(“Test”)
is kind of depressingly old-school and steals focus. This HUD-like thing feels like a modern way of approaching this: You know you’ll notice it when it fires away, and it will leave no lasting damage. (Okay, fair, it does steal focus too, so that’d be one thing to improve.)
It has great production value. I hate perhaps all of Google’s search easter eggs because they’re built so extremely
cheaply
– try searching for “do a barrel roll” or “askew” (and no, I’m not going to dignify them with links because links are my love language). It’s rare and worth celebrating when something that could very well be an internal joke or a test feature for nerds is actually something you want to use because it’s so well-made. (See also:
Linear’s internal testing UI
.)
Apr 20, 2026
above
and
beyond
10
coding
easter
eggs
internal
ui
Did you catch one interesting bit
in the last post
? The undo shortcut in Paint and other apps in Windows 1.0 used to be Shift+Esc:
This reminded me that the classic Ctrl+Alt+Del shortcut was initially Ctrl+Alt+Esc. Except, people apparently invoked it a bit too often by accident, so it was split to require two hands for extra safety.
When you look at the keyboard for the original PC, it all makes sense. Esc is at the edge of the main typing block, and in line with all the modifier keys. It would make sense to build a system around this, and it’s interesting to imagine the Esc Kinematic Universe that never happened.
Don’t get me wrong: I think it’s good that it didn’t. ⌘Z or Ctrl+Z are much easier to get to than Shift+Esc, especially in concert with cut/copy/​paste next door –
that
system introduced by Apple Lisa and Mac teams deserves endless trophies and infinite accolades. (In case you are curious, Windows 1.0 used Delete for Cut, Insert for Paste, and… F2 for Copy.)
But it has always been peculiar to me that Esc isn’t seeing more use. I see Backspace tasked with all sorts of modifier key combinations in various apps, but Esc – equally available on the other side, and even easier to target on some keyboards – is often left alone.
Poetically, given the beginning of this story, it was Mac that grabbed ⌘⌥Esc for force quit:
There is a nice thoughtful design element in that window that’s worth calling out: the hint line the bottom.
Why, of all places, would this window go out of its way to announce its own shortcut after you already figured out how to open it? I think this might be for a similar reason airlines repeat the safety announcements before every takeoff. If your computer goes haywire, if one of your apps starts hogging resources, if the UI slows down so much any action takes forever, it might benefit you if somewhere in the back of your head exists one small bit of information: “ah yeah, I don’t know how I know this, but I think I’m supposed to press ⌘⌥Esc now.”
Apr 19, 2026
errors
history
31
keyboard
23
onboarding
Anyone using old computers for graphics remembers the strangeness of “flood fill”:
The 1950s and 1960s computers were so sluggish that their consoles with blinking lights were not just for show; the operations were slow enough that you could still follow the lights in real time.
This ceased to be true soon afterwards. The microcomputer revolution temporarily reset some computing progress, but by the 1980s and 1990s more and more things were happening too fast for us to keep up.
But here (this above is Paint in Windows 1.0, and you can
try for yourself in a browser
!) was one example where you could still
see
an algorithm working hard. It was mesmerizing and educational, and it was a rare example where perhaps you didn’t mind the computer taking its sweet time. Even messing up like I did above – maybe
especially
messing up – ended up fascinating to watch.
Wikipedia has
examples
of a few different flood fill algorithms, which are even more interesting:
A few years later, Minesweeper had a very memorable flood fill, too (also
available in a web emulator today
):
But by now Minesweeper retired from sweeping mines, and today computers are so fast that it’s hard for me to imagine any flood fill being anything else but flash flood…
…except this is what I just saw in
Pixelmator
on my Mac:
I don’t know if this is a nod toward a classic flood fill, or just a nice unrelated transition. But I found it genuinely delightful, and it’s fast enough that I would imagine it doesn’t bother pros who need to do it often.
Sometimes it’s nice to see a computer working when there’s a good reason; some apps like banking apps even insert artificial, visible delays after crucial operations, just so that the users feel comfortable knowing their important transaction went through.
But sometimes it’s nice to see a computer working for no reason at all.
Apr 18, 2026
above
and
beyond
10
graphics
loading
states
The classic – but still important – rule of web design says to avoid labeling links “click here.”
It’s one of the
oldest web design principles
. Tim Berners-Lee
wrote about it in 1992
; if you visit this link right now, it might be the oldest page you will have
ever
visited.
The gist of it is simple: the mechanics of following a link are not important, and should be replaced by something that can make the link stand on its own. This is important for screen readers, but also for basic scannability: a “click here” label has a lousy
scent
and requires you to take in the surroundings to understand what it really does. The rule is, in effect, a variant of “show, don’t tell.”
(In modern days, you can also add another transgression: on touch devices one cannot click, but only tap.)
There is a similar rule about button copy design. Button labels, too, should be self-sustainable. Below is a good example (just reading the button lets me understand what I’ll achieve by clicking it), juxtaposed with the bad one (“OK” is so generic you have to read the rest of the window).
Earlier this week, I was passing some train cars on my coffee walk, and saw this bit of UI:
Why are these okay, and “click here” is not? Here’s why, I think: Yes, the ultimate goal is to move a train car, or empty it, or send it on its way. But here, the mechanics matter, too. They’re dangerous. They require preparations. No one says “I’m going to open my laptop and start clicking on links,” but I imagine people say “we have to jack this car” or “we need to lift it.” Even “here” has depth: these are specific tool mounting points. Choosing the wrong “here” will have consequences.
But, going back to the web, avoiding “click here” in strings isn’t always easy. Imagine trying to put a link in the sentence “To change your avatar, visit the profile page.” I’m personally never sure how to linkify it well:
To
change your avatar
, visit the profile page.
To change your avatar,
visit the profile page
To change your avatar, visit the profile page.
Linking “change your avatar” seems correct since it points to the eventual outcome, but then it leaves the actual destination dangling and unlinked – like putting an accent on a wrong syllable. “Visit the profile page” is better than “click here,” but it’s still not scannable. Linking the entire sentence seems strange and complicated to me, and I also disagree with Tim Berners-Lee, who
on the page I liked to above
seems to suggest this should be…
To
change your avatar
, visit the
profile page
…just because this might make a user think there are
two
separate destinations and actions, and contribute a wrong mental model.
You could, of course, simplify this to “Change your avatar,” but while that would work in a UI string, it wouldn’t within a larger paragraph of text, or a blog post.
Apr 17, 2026
details
39
flow
24
popular
11
web
13
My original idea for Unsung was “a microblog with ~3 posts a week,” which seems like a distant memory.
Now that I published 250 posts
since early December
, what better way to celebrate than to ask for feedback?
Do you enjoy specific kinds of content, or missing some topics?
How could I make the visuals and interactions better?
Any fun little ideas or bugs or improvements I could make?
Any feedback about this blog’s information architecture (including the
just-added tags
), RSS, or the weekly email?
You can reach me
via email
on Mastodon
, or
on Bluesky
If the very idea stresses you out, I want to give you permission to send me just your bit of feedback without any greetings, or small talk, or “compliment sandwiching.”
Thank you in advance!
Apr 16, 2026
about
unsung
(This is one of the meta posts
about this very blog
. If that’s not interesting to you, skip to the next one!)
I thought I’d share a few of the small design details I am proud of for this small blog!
1.
After years of being annoyed at Slack for mishandling image sizes, it was important for me to show the screenshots (at least the desktop UI) at their 100% precise size, if possible. I think that helps to get a better sense of a scale and
feel
of things. This was
harder
than I expected (since I still want images not to grow too wide or too tall), but hopefully works well now.
2.
I wrote some extra code so that if an image has edge transparency or even soft shadows, it will be aligned accounting for all that. I think that feels elegant – especially on a blog that practices asymmetry probably to a fault.
3.
If the images or videos blend too much into the background, they get a lil border to separate them – but only in light or dark mode as needed. This is so that the whole page rhythm holds better together. (Manually assigned so far. Would be curious if one can make this automatic.)
4.
Speaking of dark mode, I almost figured out how to make videos with transparent pixels so that they look good in both dark and light mode. (Chrome only. Still working on it for Safari.)
I want autoplay videos (without sound!) so that it’s easier to see interaction design – basically, a modern version of what GIFs used to provide. This has been challenging and required adding some JavaScript, and is still not done! But it’s starting to feel nice.
6.
Given all the quotations I do, I added hanging quotes to text. Wildly, they are still
not really supported by CSS
(Safari is a sole exception), so that required some manual intervention.
7.
Short lists are (automatically) spaced differently than long lists. I’ve always wanted to try that.
8.
I’m having a blast with the pixel fonts I recreated from PC/GEOS. I keep adjusting the glyphs, adding kerning pairs, etc. It’s fun to keep improving a font as you’re improving its surroundings; I just redrew the @ glyph you can see above!
9.
It’s a bit old-fashioned, but I still like the idea of
visited links
being styled differently than
non-visited links
, to help you orient yourself. (Linking feels
very important to me
.)
Apr 16, 2026
about
unsung
details
39
(This is one of the meta posts
about this very blog
. If that’s not interesting to you, skip to the next one!)
At Unsung’s 250-postiversary, if I reflect on where this blog has been, and where it might be going, this is what comes to my mind. I didn’t start the project by writing all this down, but I held a lot of this in my head. This feels like a nice moment to capture all this more deliberately, and perhaps some of you might find it interesting.
Goals of Unsung:
Highlight hard, good, invisible design work that makes things better, but doesn’t often get spotlight.
Find deeper meaning in craft, past the pretentious platitudes and surface-level delight. (Details matter not just in some abstract “craftsmanship” sense.)
Help expand what craft means: highlight relations between things, show connections between history and present, talk about things that are hard to describe and impossible to measure.
Revel in being pragmatic. Share useful things, not just hollow inspiration.
Be fun to read.
DIRECTIVE 6: CLASSIFIED_
Higher-level principles for this blog:
Don’t ever share boring stuff, even if the concepts are good, or out of completeness. If you’re not enjoying reading or watching something, assume the audience won’t either. (You can occasionally salvage something boring by providing a non-boring commentary, but try to use this sparingly.)
When you share something, always try to add your perspective or connections. At the very least, excerpt the most useful thing. This blog is QT, not RT.
Find a good balance between positive and negative examples.
In general, offer variety. The weekly digest should have both depth and breadth. (For the last two points, I made
a little dashboard
to give me some insight, although the sentiment analysis there right now is pretty worthless.)
Be opinionated, but also humble and curious. You don’t know everything.
Be candid, but not cruel. Punch up, not down.
Avoid ridiculing, “walls of shame,” and so on. Even if the work you share is horrible, turn it into a lesson or two.
This is not about people, but about work – except in some occasions it
might be
about people, so be candid when that happens.
More links is better than fewer. Good linking rewards curiosity and is a form of curation (example
). However, the post should stand on its own even if one doesn’t follow any of the links.
Make an effort to showcase work by women, people of color, underrepresented minorities, and so on.
Visuals are engaging and helpful. Think about them, but do not add gratuitous, irrelevant photos just to
meet the quota
(example
).
The best way to teach something general is to show something specific.
Lower-level principles:
Credit people by full name.
For longer videos, offer their duration to make it easy for people to make decisions about when they want to watch them.
Avoid linking to X and Substack. (It really breaks my heart how much of the design community still supports particularly the former, given all the damage we know X inflicts on society.)
Don’t use this blog as an example (e.g. by screenshots of itself), as this is generally confusing.
Personal goals:
Practice writing things that do count in less than
thousands
of
words
Do things differently – this blog is authored in Apple Notes, for example, which is kinda weird to a person like me who always writes straight in HTML.
Have fun and learn working on this (completely custom) blog platform on the side.
Give back some of what I learned in my career over the years.
Practice stating my opinions and standing by them.
Learn new things (about what I’m writing and about publishing on the web); the only way to teach something is to understand it yourself first.
Apr 16, 2026
about
unsung
What
Version History
, a YouTube show from The Verge, does really well is revisiting older tech products from today’s perspective without allowing nostalgia to take over.
This episode
about the Western Electric 500 – the canonical American landline rotary phone – is worth watching by all UX designers. There is no software here, as the phone is entirely electromechanical. But there are a whole lot of details to admire and be inspired by: the shape of the handset, the interface to change the volume, the iconic ring, the balanced and improved rotary dial, the behaviour of the cable, even the weight and balance of the whole device.
It’s not only that phone calls should all sound as good as they did in the 1950s – in my experience FaceTime Audio comes close, sometimes, but it’s so unreliable – it’s that you should try to play with a Western Electric 500 because
you want your modern interface to feel like that
The hosts – David Pierce and Nilay Patel, helped by Tim Wu, author of the excellent
The Master Switch
– also weave into it an entirely different angle, of how that phone fit into (and reflected) a specific period of American tech history, and how it related to AT&T’s then monopoly, including the phone jack and
third-party access we just discussed re: John Deere
. Even the discussion whether this is or isn’t a “hall of fame” object is good fodder for thought.
The episode – and the
entire show
– is also just a really enjoyable watch. If you like this ep, it pairs nicely with
the one about the iPhone 4
, another phone that transcended its origins through good industrial design, exactly sixty years later.
Apr 15, 2026
ergonomics
history
31
real
world
22
54
The 2021 revision of the Mini Cooper ramped up its Britishness by introducing Union Jack flag-inspired turn signals. They looked okay when stationary:
But when actually indicating an intention to turn, people started realizing what happens when you have two types of mapping fight each other:
On one hand, the left-turn indicator was on the customary left side. On the other, the light looked like an arrow – and the arrow was pointing to the right.
I don’t know how many people were actually confused by it, but it made for a few spicy pieces with “stupidest turn signal ever” and “most annoying thing” in their titles. The company’s official response was:
Mini has chosen the Union Jack lights to highlight Mini’s British heritage, and has been using them for a while. With regard to the turn indicator light pattern, there should be no trouble at all for a driver to understand, when seeing the full rear of the car, which direction is being indicated.
Mini has not heard any concerns from customers regarding the rear turn indicators, and has in fact received positive feedback about the taillight design.
It didn’t help that
one of the worst cars
this side of the Cybertruck did something similar in the 1950s:
Drama aside, I did agree with
this commenter
(emphasis mine):
It doesn’t cause massive confusion, but taillights should cause
no
confusion for anyone.
I can think of one modern version of a similar issue. If you use the iPad in landscape mode, the volume buttons seem to go “the wrong way”:
Is this anything? Probably not. I imagine it’s better to be consistent and allow motor memory to develop between all the iPad orientations, and throw in the iPhones, too. But if you only ever use your iPad in landscape, this might feel, perhaps, like “the stupidest volume controls ever.”
Oh, and the subsequent Mini revamp in 2024 solved the issue by making the turn signals less like arrows:
Apr 15, 2026
details
39
popular
11
real
world
22
Wakamaifondue
is a web tool to inspect font contents, and it starts by you dropping a font file (.ttf, .otf, or .woff) into a browser.
It handles file dropping so thoughtfully, it’s worth pausing and recognizing it:
Here’s what’s great about it:
You can drop the file anywhere. There is no designated small drop area like in some other apps; every last pixel of the window is ready to receive your file, so you can drop without worrying.
You get a hover state confirming you are safe to drop.
You can drop the file on other screens, too!
Why is all this important? Because dropping a file into a browser is a notoriously frustrating experience. If the tab doesn’t claim the file, left to its own devices the browser will do anything from replacing the current tab with the contents of the file, through opening a new tab, to… starting to download the file you just dropped and ask you for its new location!
It is frustrating when a failure mode of an action is not just that action failing – already here, repeating a drag is more work than e.g. repeating a keystroke – but also you having to do extra clean-up steps.
Wakamaifondue gets this right, and allowing to drop a file on any screen in particular is very thoughtful. Your cursor holding a file indicates your intentions rather strongly – when you see a person wearing a wedding dress, you don’t think “I wonder what they’re up to today?” – so there should be no need to switch to a certain mode or to navigate to an “import screen” beforehand.
Apr 14, 2026
details
39
flow
24
interface
design
62
mouse
fun 16-minute video from outsidexbox
with 7 examples of videogame bugs where the game creators not only owned up to their mistakes, but creatively acknowledged or remixed those bugs in subsequent versions:
I didn’t know about most of these, so I did some googling and created a list for reference:
Mortal Kombat:
Johnny Cage two uppercuts fatality
Madden NLF ’15:
Christian Kirksey reduced to 1′2″ height
Final Fantasy 6:
Sabin suplexing a train
Tiger Woods PGA Tour ’08:
Tiger Woods walking on water
Hitman 2:
Heat-seeking briefcase
Street Fighter II:
Guile’s “handcuffs” glitch
Super Mario Maker:
Weird mushroom Mario
Off the top of my head, I cannot think of any non-videogame software that received a similar “bugs as lore” treatment from people responsible for the bug in the first place.
Microsoft made a
blue-screen-of-death screensaver
, but it was originally third-party, and kind of a prank? A mean-spirited one? I didn’t find this particularly good.
The likely second-most-famous error message, the
fail whale
, transcended Twitter and was even
referenced in other products
…but as far as I understand Twitter the company was itself embarrassed by it, and eventually switched the whale to a
caterpillar
(Those two examples aren’t really even bugs in the same category as those in the video, anyway.)
Apr 14, 2026
bugs
34
easter
eggs
games
32
54
Right next to the generic function to delete photos by going through them one by one, my camera has a specific version – Delete All With This Date:
Below the actions to close the tab, and close all
other
tabs, Chrome has a specific version called Close Tabs To The Right:
In After Effects, next to typical save options, there is this – Increment And Save – which saves a file and changes the number at the end to be one notch higher (Project 2 → Project 3, and so on):
I’m mildly fascinated by these strangely specific accelerators.
The one in the camera is genuinely useful. Photo projects are often day-long affairs where you download the photos at the end of workday, but might still keep them on the card just in case. Allowing to quickly delete a day’s worth of photos makes a lot of sense, saving you from having to go through them one by one in an interface not suited for that kind of operation.
Chrome’s “Close Tabs to the Right” takes a bit of figuring out, but I believe it’s meant to make it easy to clean up after a fruitful research session where you kept ⌘-clicking and opening tabs to learn more, and those tabs now fulfilled their purpose. (Curiously, Firefox also has “Close Tabs To Left” which I don’t understand.)
After Effects’s “Increment and Save” is… I don’t know. Maybe it’s cheap? Maybe it’s honest? A proper version history would be nicer, but that’s a tall order. This is simple and, most importantly, reliable. I still often do the “poor man’s version control” elsewhere…
…so this works for me.
It’s always interesting to me to think whether these kinds of oddly-specific examples are nice gestures toward the user, or treating symptoms in lieu of fixing actual problems. Either way, I don’t think an interface can survive too many of these, as their obscurity and weirdness add up and can contaminate the entire UI.
Would love if you sent me more of these kinds of commands from the apps you use!
Apr 13, 2026
complexity
13
details
39
flow
24
interface
design
62
A fun 24-minute
video from Technology Connections about designed sounds in real life
: elevator dings, airplane chimes, railway crossing dings, and so on.
While I am sympathetic to the notion that sound pollution is a thing we need to be concerned with, the choice between silence and sound pollution is a false choice. There’s a lot of those happening these days, probably because we’re so stuck in binary thinking. But as airplanes show us, we can design sounds which aren’t obtrusive, but which are helpful. And when you get yourself out of binary thinking, you can do things like make your most obnoxious apps be silent while your important ones make themselves known, and in ways which are meaningful to you and pleasant to everyone else.
It is an interesting parallel to the post about
syntax highlighting
from a while back, and
one of the posts about cartography design
I shared recently; they all explore how you can create a richer space capable of conveying more information without overwhelming people, by being intentional about the design.
Apr 13, 2026
attention
complexity
13
real
world
22
sound
design
54
One of the casualties of Apple’s otherwise brilliantly executed transition to retina pixels has been the mouse pointer, which remains aligned to what “traditional pixels” used to be, rather than the retina/​physical/smaller pixels.
Turn on the
zoom gesture
from a few weeks ago, and you can see the challenge. The gridlines are ½ logical pixel and 1 physical pixel wide:
This limitation is inherited by most tools: Photoshop, Affinity, xScope, even the built-in Digital Color Meter. It’s not the end of the world, of course, but it can be maddening if you are trying to sample a color from a “half pixel” and the cursor stubbornly skips it no matter how delicately you move. Here it is in Figma:
Of the few tools I tested, only Pixelmator allows to sample at the correct, precise level:
I was curious how would a truly precise cursor feel in general – would there be any disadvantages? – so
I built a little simulator
that allows a regular arrow cursor to be aligned to “half pixels” or “retina pixels.”
In the process, I discovered that both Chrome and Firefox already receive sub-traditional-pixel measurements for mousing events, so this was even easier to build than I expected. Now, precise targeting in Chrome and Firefox becomes possible:
I don’t personally see any big difference in terms of either upsides or downsides, and I’m curious if you do. iPadOS and its Safari already seem to support the precise mouse pointer, too. That makes me curious: why isn’t it available in macOS? I imagine you could even turn it on by default for apps – or, if you want to be more conservative, make it opt-in.
Pixelmator also shows that the apps can do it without waiting for macOS as the data is already there; they would just need to render the cursor on their own with more precision.
Apr 12, 2026
apple
24
details
39
flow
24
mouse
Cory Doctorow, in 2022, wrote an essay about how John Deere – a farm tractor manufacturer –
restrict repairs by owners or third-parties
Deere is one of many companies that practice “VIN-locking,” a practice that comes from the automotive industry (“VIN” stands for “vehicle identification number,” the unique serial number that every automotive manufacturer stamps onto the engine block and, these days, encodes in the car’s onboard computers).
VIN locks began in car-engines. Auto manufacturers started to put cheap microcontrollers into engine components and subcomponents. A mechanic could swap in a new part, but the engine wouldn’t recognize it — and the car wouldn’t drive — until an authorized technician entered an unlock code into a special tool connected to the car’s internal network.
Big Car sold this as a safety measure, to prevent unscrupulous mechanics from installing inferior refurbished or third-party parts in unsuspecting drivers’ cars. But the real goal was eliminating the independent car repair sector, and the third-party parts industry, allowing car manufacturers to monopolize the repair and parts revenues, charging whatever the traffic would bear (literally).
The same tactic was used by John Deere, forcing farmers to
hack the tractors they purchased
just so they could repair them.
In a decision that bolsters
right-to-repair movement
, John Deere and farmers reached a settlement that has the company pay $99 million to repay prior inflated repair costs, and requires it to share software required for maintenance and repair with farmers.
Just because I was curious and you might be also, here’s an example of a modern tractor interface:
The story reminded me of
an ongoing battle in Poland
where a train manufacturer Newag used VIN locking and coupled it with GPS hardcoding in an even more brazen attempt to prevent third-party repair: if a train spent too much time at a location of another train repair company, it’d simply stop running – not by some hardware fault, but by a simple
if
condition in code.
“This is quite a peculiar part of the story—when SPS was unable to start the trains and almost gave up on their servicing, someone from the workshop typed “polscy hakerzy” (“Polish hackers”) into Google,” the team from Dragon Sector, made up of Jakub Stępniewicz, Sergiusz Bazański, and Michał Kowalczyk, told me in an email. “Dragon Sector popped up and soon after we received an email asking for help.”
The (
white-hat
) hackers helped unbrick the train, but since European law is stricter on DRM, the case gets murkier. The article above is from 2023, and contains this quote:
Newag said that they will sue us, but we doubt they will - their defense line is really poor and they would have no chance defending it, they probably just want to sound scary in the media.
However, in 2025, the manufacturer proceed to
sue the hacker group and the train repair company
. As far as I can tell, the case is still in courts.
The three hackers explained their work
in this 45-minute conference talk
. It’s honestly not the most polished presentation, but it goes into a lot of engrossing details and if the intersection of hacking and trains hardware interests you, check it out! I had fun looking double checking this presented code by punching in the lat/long coordinates into Google Maps and verifying they’re exactly the locations of competitive repair shops:
Apr 12, 2026
conference
talk
maintenance
13
piracy
real
world
22
Found in an archive of font design (for Olivetti typewriters) and smiled:
Handoff problems were there before us and will remain after we’re gone.
This, too:
Apr 11, 2026
history
31
process
typography
14
From 2010 to 2021, Justin O’Beirne had been
writing about online cartography
, specifically in Google Maps and Apple Maps.
While both of these services changed a lot since the essays, they are still worth reading. They might be the closest to modern reviews of software as I can think of, and the way the essays are done also teaches us storytelling lessons – from nice visualizations and comparisons, to rich footnotes. There is also a great balance of high-level overview, and then jumping into specifics that reinforce it.
Here’s one example of cool tooling O’Beirne used to make his points more sticky:
I wrote a script that takes monthly screenshots of Google and Apple Maps. And thirteen months later, we now have a year’s worth of images:
The result is informative and mesmerizing:
Among the essays, I’d particularly recommend these:
The back-and-forth of
Google Maps’s Moat
and
New Apple Maps
: Reverse engineering areas of interest, thinking of how the slow changes in visuals lead up to strategy, good visual comparison of competition, and small fascinating anecdotes of places like Parkfield, California. (And a great example of the old adage: don’t get into the business of predicting the future as this will age your writing the most.)
A Year Of Google Maps & Apple Maps
: Evolution and redesign as ways to “increase capacity.”
Google Maps & Label Readability
: A fascinating discovery of “city donuts.”
What Happens to Google Maps?
How cross-device compatibility can mess up maps.
There are also
book recommendations
and a
memorable user story
Apr 11, 2026
above
and
beyond
10
colors
complexity
13
details
39
toolmaking
typography
14
web
13
Why is there a short wait if you press a button on your headphone remote or your AirPods to pause the music? Because the interface has to let a bit of time pass to figure out if you’re going to press the button again, making it a double press (advance to next track) instead of a single press.
This kind of disambiguation delay is everywhere for simple gestures.
Why is there a short wait if you press a button twice in that situation? The double press processing
also
has to be delayed, because there is a chance it might become a triple press (go to previous track).
Why is there a short wait if you press a button to go to the next track on your car’s steering wheel? It’s a delay of a different kind, but the same principle: the function cannot kick in on press down, because press down and hold mean “fast forward.” So, software has to wait for button up event to go to the next track (which feels a bit slower than button down), or for enough time to pass so we’re certain it’s a button-down hold rather than a slow press. Here, both interactions experience a penalty for coexisting.
The most infamous of those disambiguation delays exists in mobile browsers. Since every double tap can zoom into the page ever since that
famous 2007 iPhone presentation
, every single tap on a link or elsewhere has to be delayed by about 300ms. This has been a source of contention since it does make the web feel a bit slower, and today browsers
suspend double tapping
on sites designed for mobile, trading zooming affordances for higher interaction speed – after all, you can still zoom in by pinching. But if you always wondered why older websites tend to be a bit sluggish to interact with, now you know.
Different tradeoffs are possible. In the Finder, clicking on icons isn’t slowed down even though double clicking exists, because selecting an icon is compatible with opening it! So in effect it’s not a choice between a faster A and a slower B – it’s A or A+B.
Even in the iPhone presentation above, you can see the interface
highlights
the link on double tap, to at least make it feel snappier, at the expense of the highlight being “wrong” and potentially distracting – or even confusing – when you end up double tapping. (You can imagine smartphones pausing on the first remote/​headset button press, too. It feels like it would be compatible with advancing to the next track, but I think it might also feel too “choppy,” too chaotic, in practice.)
Lastly, why is there a short wait if you press a button on your hotel TV to increase the volume? Oh, I think that one is just sluggish for no good reason.
Apr 11, 2026
details
39
finder
interface
design
62
performance
A few years ago, some sort of a bug at my work caused all of the timestamps appear as “54 years ago,” a seemingly arbitrary date. It took me a bit to realize: “Wait, you know what year was 54 years ago? 1970!” “Why is 1970 important?” asked another designer. I explained that by convention, Linux time
counts up from Jan 1, 1970
– and so if the time “value” is zero or unavailable, as it was because of the bug, it would be rendered not as an error, but as that specific day long ago.
Computing is filled with all sorts of arbitrary numbers like these. The most famous one was Y2K (99 + 1 = 00 if you only allocate two digits),
Pac-Man’s kill screen
was number 256, people still bring up the infamous and likely non-existent “
640 kilobytes should be enough for everybody
” quote, and the Deep Impact space probe
died a lonely and undignified death
after its timers overflowed the two pairs of bytes given to them.
Here’s a new magic number to remember: macOS Tahoe has, for a while at least,
a kill screen of its own
– after 49 days, 17 hours, 2 minutes, and 47 seconds (or, 4,294,967,295 milliseconds), one of its time counters overflows and no new network connections can be made, rendering the machine rather useless. The only solution is a reboot. Talk about a
dead
line!
(Well, new-ish. In perhaps a
bit of karmic payback
Windows 95 and 98 once had a similar problem
with the exact same threshold of 49.7 days.)
Wikipedia has a nice list of other
time storage bugs
. The next big one? The problem of the
year 2038
. The technical fix, as always, is to give the numbers a bit more room to breathe. This is, in a way, kicking the can down the road, but that might be okay since the road is rather long:
Modern systems and software updates address this problem by using signed 64-bit integers, which will take 292 billion years to overflow—approximately 21 times the estimated age of the universe.
However, as always, the technical side
won’t be the hard part
Apr 10, 2026
bugs
34
I’ve loved
Chris Staecker’s videos
about calculating devices and machinery for years now, and I finally have a reason to link to one here. This is a fascinating
12-minute review of The Kensington Adding Machine from 1993
It’s a fun (as always) watch, but as a UX designer, it’s also interesting to try to figure out what are the underpinnings of the things Staecker lists as strange from today’s perspective.
I believe that “CE/T” (clearing and totaling) coexisting on one key is a nod to professional accounting use of adding machines where you wouldn’t want to accidentally enter something into the record
twice
– so totaling also automatically resets the value and prevents you from making a mistake.
I also believe the strange [+=] rule is only because the keypad has to look forward at the same time it is looking back: it needs to serve as a universal computer keypad where [+] and [=] are separate key, but it also needs to pretend to be an adding machine where one key served both purposes.
(You can spot that the back of the box just allows you to swap the [+] key to be something else.)
Overall, the video is a fascinating tale of an “
in-betweener
” product that was stuck not just in the middle of a transition from physical devices into apps, but also at the intersection of calculators and adding machines (once two very different lines of products), themselves trying to learn from each other. It also serves as a great reminder that
skeuomorphism
is not just about visuals and sounds, but also behaviours: tearing off the tape, details of specific keys, nuances of rounding.
It’s not a thing of the past, either. In my
post about determinism
I linked to Apple’s recent travails with the deterministic Clear button (part
one
two
, and
three
). A few years ago, Apple also changed the built-in iPhone calculator from its “desktop calculator” roots to a more modern model where you get to input the entire equation before you see the result. But that change had bigger consequences; for example the [=] key could no longer repeat an addition. People complained, and Apple added it back – but the change feels incompatible with the new system and potentially confusing:
Elsewhere, the entire iPhone is an in-betweener, as the keypad coming from calculators is incompatible with the keypad coming from phones.
At this point it seems the calculator keypad will win, but transition has been over a century in the making. Staecker’s video is a good reminder how important, but also hard it is when you try to make these transitions happen faster.
Apr 9, 2026
change
management
flow
24
history
31
real
world
22
skeuomorphism
54
Paul Ford in 2014
As far as I can tell, no truly huge world-shifting software product has ever existed in only one version (even
Flappy Bird
had updates). Just about every global software product of longevity grows, changes, adapts, and reacts to other software over time.
So I set myself the task of picking five great works of software. The criteria were simple: How long had it been around? Did people directly interact with it every day? Did people use it to do something meaningful?
I came up with:
the office suite Microsoft Office,
the image editor Photoshop,
the videogame Pac-Man,
the operating system Unix,
and the text editor Emacs.
Ford’s criteria felt more interesting than those of the other similar lists:
I propose a different kind of software canon: Not about specific moments in time, or about a specific product, but rather about works of technology that transcend the upgrade cycle, adapting to changing rhythms and new ideas, often over decades.
This – about Unix – also caught my attention:
There’s a sad tendency in most manuals and programming guides to congratulate people simply for thinking. Not here; you’re expected to think. That can be very exciting when you’re used to being patronized, and it’s one of the best things about Unix.
Apr 9, 2026
history
31
software
evolution
13
One of the readers (thank you, Peter!) reminded me that there is a version of a
blink comparator
that all of us are exposed to perhaps every day: many photo editing apps – Apple Photos, Darkroom, Aphera, I imagine others – allow you to quickly compare the photo as-shot and with your edits. Sometimes it’s a tap, sometimes an onscreen button, and in the case of Lightroom it is a backslash key. Here’s that feature on a color graded photo with some dust removed:
But these blink comparators are smart. If you e.g. rotate the photo, the comparison will be with the original
also rotated
so the pixels still map to each other 1:1 – even if you rotated the photo as the last step in your editing process:
I think this is a brilliant example of understanding the spirit of a feature rather than its letter. A naïve blink comparator would show an unrotated photo, but in this way it would cease being a blink comparator.
Apr 8, 2026
details
39
interface
design
62
principles
13
The 2016 launch of No Man’s Sky and the 2020 launch of Cyberpunk 2077 were catastrophes. No Man’s Sky fell so incredibly short of the
promises
the founder shared over the years – from smaller ones like rivers on the surface of planets, to huge ones like
seeing other players
– that some people felt it must have been a scam all along.
The other game was a simpler case study: Cyberpunk was buggy as hell. Not just the abysmal performance, but also the overall quality. People called it “the Hindenburg of videogames” and made
YouTube compilations
and
listicles
of its often hilarious bugs: cars exploding for no reason with perfect comedic timing, intimate body parts protruding through the clothes, and the infamous T poses.
In an unprecedented move, Microsoft slapped a big warning atop Cyberpunk’s app store listing, and Sony pulled it from their store altogether.
But it is 2026 now, and both games redeemed themselves. For years after the launch, the No Man’s Sky team
worked hard on adding promised features
Over a decade on from its initial reveal, No Man’s Sky both manages to remain the same game it was at launch while also bringing almost every single missing feature (and dozens of new surprise ones) into the title – implementing them intelligently and with great consideration for how it will affect the core of the game. They achieved their redemption years ago, yet continue diligently with massive update after massive update.
No other title has done what Hello Games have managed to achieve. And the best part? Every single update, patch and addition to the game was and is 100% free, with no falsified hype or build-up to each update.
Cyberpunk 2077 had a redemptive arc of its own, too, highlighted and
contextualized in this 17-minute video from gameranx
. Today, both games are rated “very positive” on Steam, and are actually still gaining daily players.
So, wonderful comeback stories, right? Depends on how you look at it. It’s great that both these games ended up being good products, but perhaps not as great that it was all happening in the open.
The videogame industry tried to get creative about it and established an idea of “early access”: being able to purchase an incomplete game earlier, and watch it get better while the publisher receives funding to keep going. But for every Minecraft there is
Godus
, and for every Kerbal Space Program there is
The Day Before
. Plus, neither No Man’s Sky nor Cyberpunk launched in early access with attendant caveats and discounts. (By the way,
Wikipedia’s entry for early access
is worth checking out – it’s so eloquent I’m surprised not to see any warning boxes.)
There seems to be ongoing and perhaps rising frustration with companies releasing software products too early and fixing them in flight, if at all. Already in 1996, Geoff Duncan
wrote about his annoyances with that
What Beta Means Now: […] In many cases – particularly with Mac Internet software – “beta” doesn’t mean anything close to what it used to. We’ve seen programs in public beta that not only contain innumerable known bugs the developers are aware of and plan to fix, but also accumulate major new features through subsequent releases. Similarly, we’ve seen products that change fundamental system and technology requirements during beta – details which should have been etched in stone long before. Beta often means what “alpha” or even “development build” used to mean.
Subsequently, Google and other web-first companies diluted the meaning of beta labels even more.
The trend of premature launches extended to devices, too. About two years ago, AI assistant gizmos from Humane and Rabbit were pilloried by audiences for launching in an effectively unfinished form. Both devices failed in the market; MKBHD’s video reviews of
Humane AI Pin
and
Rabbit R1
remain both entertaining and informative watches.
AI complicates this even further in many ways. I enjoyed
Pavel Samsonov’s recent post on his blog Product Picnic
analyzing another disastrous launch: Grammarly’s writing advice feature that replicated well-known authors
who never agreed for their likenesses to be used this way
Reading between the lines, Mehotra’s interview paints a picture that I think many tech workers will find familiar: features are conceived, coded, and shipped as quickly as possible. He is happy to admit that the feature was a mistake… in retrospect. But in the moment it actually mattered, critical thinking was swept away by the false urgency of pushing things out.
It is worth reading in full and following the links, too; I watched the
mentioned (tense) interview
, and was similarly frustrated with the CEO’s lack of accountability or even a hint of an explanation of why the feature was launched to begin with. Key line from Samsonov’s post:
If you don’t know what are you trying to learn when you ship a prototype, do not ship a prototype.
This becomes even more important as the difference between a prototype and a final product is now thinner than a retina pixel. Both No Man’s Sky and Cyberpunk had, at least, well thought through foundations.
I understand that for some people gen AI software building tools is a discovery – perhaps for the first time – of a genuine
joy of creation.
But there’s also the other, newish side, a sort of “cult of velocity” where people show screens filled with agents coding things as if the world needed every possible app right this second.
Velocity and urgency can be important, but it’s hard to be careful and thoughtful when you’re going really fast; unsurprisingly, some don’t know what to do with that newfound AI-powered speed or realize the importance of thinking about crucial aspects other than time to market. (When digital cameras came around, the barrier to entry for photography was drastically lowered – it was possible to take a lot of photos without worrying about cost or quality. Tons of people took tons of objectively subpar photos; some were the end goal, some were a stepping stone toward more photographic mastery. However, I am not sure I remember people on either side ever bragging “I took over 1,200 photos today!”)
All this could be contrasted with movement of slow software (the name is part of a bigger
slow movement
although has unfortunate connotations in tech – it’s slow as in “speech,” not slow as in “beer”). Jared White in 2023
defined it as
Sustainable software. Architecting and writing code in ways which are easily understandable and maintainable over time, requiring few dependencies and a rate of change that is healthy for the underlying ecosystem.
Thoughtful software. Working through feature development and making decisions based on what will benefit the userbase over the long term, placing mental and social health as priority over immediate gains or selfish interests.
Careful software. Seeking to understand the ways software might be used for harm, or itself be harmful by taking attention away from more important concerns in the broader culture.
Humanist software. Recognizing that most software—at least in application development—is primarily written for humans to understand and reason about with ease across a wide array of skill levels, and that relying on complex code generators or “generative AI” tooling to resolve complexity instead of simply building simpler human-scale tools is an industry dead-end.
Open software. Looking to established collaborative software movements like open source and the standards bodies responsible for open protocols to inspire how we build and maintain software (regardless of licensing).
I don’t really have a conclusion for this meandering post, as I am not sure a snappy conclusion is possible. Perhaps some of the links above can provide inspiration or food for thought about urgency, reputation, and doing things in the open.
Some patterns I’m noticing are:
Velocity is never an end goal.
Velocity is only one of many ingredients of software building.
It is necessary to think of people who will experience your work-in-progress as it is, not as it might one day be.
Apr 6, 2026
ai
bugs
34
games
32
software
evolution
13
Just like
the video I shared last week
, this
20-minute video by Mariana Colín at The Morbid Zoo
is sharper than most, and also extremely entertaining:
Colín is not “in tech,” and the video is of “the king is naked” variety which is very, very refreshing.
Among many good observations, this caught my attention as relating to this blog’s topic:
It’s a little weird to have this almost adversarial relationship with your customer base. They’re not trying to solve a problem customers have. They’re trying to convince people that the product on offer is something more than it clearly is.
What VR is, is a fun parlor trick. What they want VR to be is literal reality.
It does indeed feel Meta’s version of VR/metaverse has always been cargo-culting real world in a particularly awkward fashion, which Colín analyzes deeper.
Too many quotable laugh-out-loud moments, so maybe just this one more:
Down here in the real world, there are really only two things a media technology can be. It can be a solution to a specific discrete informational problem, or it can be an artistic medium. These two things are not mutually exclusive. There is crossover here – like, radio was a military tool before radio plays were ever a thing.
But by the former, I mean you’re literally just making information go faster. You’re reducing the amount of noise between a message and its receiver. Any kind of metaverse is going to be really, really bad at this because you don’t need to look at a weird Pixar version of your coworker in order for them to convey what a deadline is.
Apr 6, 2026
research
software
evolution
13
54
In late 2023, designer Anthony Hobday published a small list of
20 interface quality of life improvements
, and recently Hobday and Katie Langerman chatted about it
on an episode of their podcast Complementary
It’s a fun listen (perhaps if you skip a bit of a bummer 9-minute beginning), covering four listed things in more details:
generous mouse paths (especially in menus)
coyote time for modifier keys
optical alignments
tooltip timing details
There were a few interesting things that caught my attention:
Figma does have “coyote time” in the very interaction the hosts are talking about, perhaps showcasing that the details
of the details
can make or break them.
“Should modifier keys be reversible” and “should modifier keys be consistent with one another” are interesting challenges; some more recent graphic tools have changed the long-standing behaviour here, malking modifier keys more “sticky.”
Wholeheartedly agree with how frustrating it feels that the menu interactions are not yet baked into browsers as primitives. “The fact that the companies keep having to implement it themselves manually is maddening.” It is.
Good observation that some people associate animations with “feeling premium” (see also: the quote I put in the title).
Apr 6, 2026
details
39
interface
design
62
podcast
You might have seen this, one of the strangest and most primitive experiences in macOS, where you’re asked to press keys next to left Shift and right Shift, whatever they might be.
Perhaps I can explain.
There are three main international keyboard layout variants in common use: American (ANSI, with a horizontal Enter), European (ISO, with a vertical Enter), and Japanese (JIS, with a square-ish Enter).
The shape of Enter and the shuffling of the surrounding keys is not the only difference. It’s also that the European layout has historically always had one more key – shoved in between Shift and Z – and the Japanese layout a few more.
But the main challenge is that a keyboard doesn’t have a way to tell the host computer what are its exact keys and where they’re located.
So, pressing the thing next to the left Shift can help Apple understand whether the keyboard is American or Japanese (always Z) or European (something else, but never Z). And pressing the thing next to the right Shift differentiates JIS (where it’s the _ key) from another keyboard (always /).
What I called “primitive” just above is actually clever in its approach. The legend of the key next to left Shift varies per locale (
you can compare here
), so the system can’t just tell you to press the < > key – and besides, asking the user to find a key that might not exist is a lot more stressful. And, identifying the keyboard by choosing a layout visually wouldn’t work either, since there are a million of layout variations – imagine having a split or a compact keyboard!
But it still is primitive, because it will still open up even if the keyboard you connect isn’t really a typing keyboard…
…or even if it doesn’t have any keys at all. (Some peripherals like credit card readers and two-factor dongles identify as keyboards as they transfer information by sending keystrokes.)
But: Why does it matter? What happens if you select the wrong layout or ignore the dialog?
If you mix up America and Europe, the difference should be largely cosmetic. After all, you still have to choose the keyboard
language
. People in, say, Germany will likely choose the appropriate locale, and the keys will do the right thing. However, also selecting the correct
physical
layout will properly display it in a few places, which can be helpful:
Japanese keyboards are more interesting, because they still have an English “mode” and the legends on a lot of the keys in that mode are different than on those on American and European keyboards – yet, the keys when pressed appear exactly the same (have the same “scan codes”) to the connected computer:
So knowing whether the keyboard is “US in the US” or “US in Japan” is important not just to place keys in the right position visually in a few places in macOS, but also for those keys to output what they actually show:
By the way, Apple’s own keyboards do not pop up this dialog. This is because while a keyboard can not do much when connected, it can at least send a vendor and model identification numbers, and Apple knows which of its keyboards sport what physical layout.
Why doesn’t macOS do that for third-party keyboards? They might, for some well-behaving ones; I don’t actually know. Unfortunately, the vendor/​model identification is a wild west and a lot of the keyboards I have identify simply as “unknown,” so building up an all-encompassing keyboard layout database is not really possible.
Either way, I mostly wanted to share why the dialog exists. Mind you, I don’t
love
it in that its language could be better and at one point it breaks a cardinal rule of reorienting options, which makes it hard to remember “oh yeah, it was the first scary setting that worked before.”
But overall, I thought it is a clever solution to a surprisingly hard problem. Sometimes primitive is better than nothing.
Apr 5, 2026
keyboard
23
mac
os
24
21-minute video from Karl Jobst
about a 2025 videogame cheating scandal:
In short: One of the professional teams in the FPS game
Squad
built a sophisticated set of scripts that made it easier to use the game for esports tournaments by adding additional UI, useful stats, a floating camera, an extra over-the-shoulder view, and so on. The community embraced the scripts as they genuinely made the spectating much better.
Months later, it turned out that the creators not only hardcoded easier rules for their own team, but even added a pretty comprehensive set of cheating keyboard shortcuts.
The useful esports spectating scripts were, in effect, a trojan horse. A fascinating story, plus an interesting case of psychology of cheating.
Apr 5, 2026
games
32
54
Two great posts about interaction latency on the hardware and software side. First is
from Ink & Switch
There is a deep stack of technology that makes a modern computer interface respond to a user’s requests. Even something as simple as pressing a key on a keyboard and having the corresponding character appear in a text input box traverses a lengthy, complex gauntlet of steps, from the scan rate of the keyboard, through the OS and framework processing layers, through the graphics card rendering and display refresh rate.
There is reason for this complexity, and yet we feel sad that computer users trying to be productive with these devices are so often left waiting, watching spinners, or even just with the slight but still perceptible sense that their devices simply can’t keep up with them.
We believe fast software empowers users and makes them more productive. We know today’s software often lets users down by being slow, and we want to do better. We hope this material is helpful for you as you work on your own software.
I loved the slow-motion videos comparing what is normally impossible to notice:
Dan Luu has a complementary post digging a bit more into
computer hardware latency from the 1970s to now
I’ve had this nagging feeling that the computers I use today feel slower than the computers I used as a kid. As a rule, I don’t trust this kind of feeling because human perception has been shown to be unreliable in empirical studies, so I carried around a high-speed camera and measured the response latency of devices I’ve run into in the past few months.
I feel both of these essays are fantastic, and important to develop some sense of what are
specific
numeric thresholds separating fast and slow, also in the context of being able to have an informed conversation with a front-end engineer. (Luu subsequently links to even more articles in the “
Other posts on latency measurement
” section, if you are curious.)
Otherwise, from my observation, the two most quoted laws of user-facing latency are still Jakob Nielsen’s response time limits, and the Doherty Threshold. But the
Jakob Nielsen 100/1000/10000ms rule
is from 1993 and as far as I understand is concerned primarily with UX flows: reactions to clicking a button, responses to typing a command, and so on. And the
Doherty Threshold
is even older. Both are simply not enough, especially not for things related to typing, multitouch, or mousing, where for a great experience you have to go way below 100ms, occasionally even down to
single-digit milliseconds
(My internal yardstick is “10 for touch, 30 for mousing, 50 for typing.” Milliseconds, of course.)
At the end of his essay, Luu writes:
It’s not clear what force could cause a significant improvement in the default experience most users see.
Perhaps one challenge is that these posts are dense and informative, but only appeal to people who care? Maybe latency eradication needs a PR strategy, with a few memorable rules and – perhaps arbitrary, but well-informed – numbers that come with some great names attached? I know in the context of web loading some of the metric names like FCP (First Contentful Paint) broke through at least to some extent, but those still feel more on the nerdy side. Even
Nielsen’s otherwise fun 2019 video about response time limits
didn’t stick the landing – why focus on slowing down an arbitrary label appearing above the glass when the
ping sound
was right there for the taking?!
I can’t help but dream of interaction speed’s “enshittification” moment.
Apr 4, 2026
keyboard
23
mouse
performance
touch
11
In the
previous post
, I wrote:
I understand that the best way to compare two things visually is to switch between them promptly in situ; our visual system is really good at spotting even small changes when aided this way.
I thought it would be fun to talk about it briefly, because it gives me a chance to show you a really fun device:
This is a
blink comparator
, an apparatus built for astronomers to easily flip between two images of the night sky, taken at the exact same position some time apart.
It makes it easy to spot a moving asteroid, like in this set of two photos:
Blink comparator was used in 1930
to spot Pluto
(Pluto is the blinking dot a bit to the top and to the right from to the center – that dot moves to the left in the other frame. The fact that it moved at all made it an object of interest, but it didn’t traverse the sky like an asteroid or space debris would.)
This is why the “spot 10 differences” puzzles are always shown side by side…
…otherwise everything would be much, much easier to spot:
Today, this kind of stuff doesn’t require complex devices, but it’s useful to know the principle.
If you’re comparing a reference design with its implementation, instead of measuring things on both sides it can help to align them in two windows, and then switch between them using ⌘Tab.
If you’re working on an interface for users to see differences between two images – don’t (just) show them side by side, but also allow your users to flip between them this way. And, resist the very natural urge to add any transitions that would seem to be nicer and friendlier; it is sharply switching between images that is the most effective.
Apr 3, 2026
hardware
history
31
principles
13
real
world
22
I was impressed with this clever internal interface at Linear, shown
inside this larger blog post
The dev toolbar exists directly inside the app and allows us to easily toggle feature flags on and off. When something didn’t look right in the refreshed UI, it took us just one click to compare it with the previous version. That made it easier to determine whether the refresh had broken something or whether it had behaved that way before. Having the updates live behind feature flags also meant that instead of developing the redesign in isolation and shipping all the changes at once, we could integrate incremental changes to the platform.
I also cut it out here so it’s easier to see:
Here’s what I like about it:
It’s a separate UI surface: Rather than being awkwardly integrated alongside production UI and adding jank to it, it is a clearly delineated toolbar you know users won’t ever see, allowing the rest of the interface to always feel like production.
The feature flag toggling is easy: You don’t have to go anywhere else and possibly log in to toggle a flag, and you don’t have to wait for it to take effect. This will mean more people than just the core team members will be using it.
Toggling this particular feature flag is as easy as clicking on a tile: I don’t know if anyone can promote others flags their care about to be easily toggle’able tiles, but I can imagine this really beneficial, too.
The feature flag toggling is instantaneous without any visual jank: I understand that the best way to compare two things visually is to switch between them promptly in situ; our visual system is really good at spotting even small changes when aided this way.
Each one of the above bullet points is individually a small point of friction and easy to renege on, especially when it comes to internal-only interfaces. However, a combination of all of them results in great compounded interest, and I bet makes this interface effective – in addition to just feeling like fun to use.
Appreciate Linear sharing this internal detail; if you are using an interesting internal tool or UI that you are allowed to share, please consider it and let me know!
Apr 3, 2026
above
and
beyond
10
bugs
34
internal
ui
process
This 25-minute segment on MKBHD’s Waveform podcast (
video
or
audio
, segment starts at 40:21) is from November 2024, and is a nice counterpart to the post about
favourite well-made apps and sites
The original theme is “what is an app that you use all the time, and like to use, but is actually a bad app?” but it quickly moves to a more general conversation about good and bad mobile apps.
It’s always interesting to me to see what themes emerge and what other people think is important. Here’s the list where I linked to relevant apps as long as I could find them:
Bad apps:
Google Messages
– dinged for unreliable spam and lack of organization/​filtering
Notion
(on mobile) – hard to orient yourself and some direct manipulation is wonky
many smart home accessory apps – bad and redundant with Google Home, but have to keep for emergencies
Netgear Orbi
(network router) – specific functionality and bad password recovery
Hatch
(white noise machine for babies) – simple things are hard to discover
Nest app
/Nest Yale Smart Lock – bad integration
Goodreads
– stale
Good apps:
ButterflyMX
(smart building lock app) – reliable
UDisc
(score keeper for disc golf) – good functionality, great in a free version
New York City ferry
New York City ticket payment
– reliable and has many payment options
Greenwich, CT
and
San Francisco parking apps
– live activities
The StoryGraph
– cool graphs and stats about your book reading patterns
Apr 2, 2026
above
and
beyond
10
podcast
touch
11
54
A few years ago, I suggested adding a new interaction to Figma. If your text cursor was on a misspelled word (anywhere inside, or the edges), you could press Tab to quickly accept the suggested correction, without even seeing it:
Independently, Google Docs approached it from a slightly different angle, but landing on a similar interaction – in their version there’s a small visual callout, although you can still press Tab (and then Enter) to accept the suggestion:
I know the Tab key has a lot of jobs – from indenting bullet points to jumping through GUI elements – but in this context this new addition doesn’t seem to be in conflict.
(Should I write a long photoessay about the Tab key, similar to the ones I wrote for
Return/​Enter
and
Fn
keys?)
Since we added it, I’ve really loved how it
feels.
From various typeaheads and autocompletes elsewhere, Tab has a strong “forward movement” energy so it makes conceptual sense, and it’s just really fun to go around and quickly fix your writing this way.
I think a lot about how to make keyboard interactions feel superpower-y: a good keyboard shortcut on a large key, a tight interaction, a blink-of-an-eye velocity – something that’s eminently designed to lodge itself in your motor memory as quickly as possible, as it builds on top of prior motor memory. I’m biased, of course, but I like the “no scope” Figma version more, and it has that feeling to me.
Apr 2, 2026
details
39
flow
24
interface
design
62
keyboard
23
text
editing
Apr 1, 2026
easter
eggs
humor
10
Go to Settings > Accessibility > Zoom, and then turn on “Use scroll gesture with modifier keys to zoom.”
Then, at any moment, you can hold Control and swipe with two fingers (or use a scroll wheel) up or down to zoom the entire screen.
I’d also recommend turning off “Smooth images” under “Advanced…” so you see individual pixels better:
Over the years, I found this feature very useful to inspect various misalignments, to check visual details, and occasionally simply to read text that’s too small.
Compared to other ways of zooming, this one has three benefits:
it’s extremely motor-memory friendly and so my fingers do it without me even thinking
it’s a system-wide thing, so it will work everywhere
it’s safe, because it’s something that I call a
peek gesture
Peek gestures are fast, but the main benefit is that they’re safe. In some apps, pressing ⌘+ a few times and then ⌘– the matching amount of times doesn’t guarantee you will end up back in the same situation. The window size might change, the scroll position might move, the cursor might end up in a different place. In contrast, the Ctrl gesture is 100%
deterministic
and reversible; it will always work the same and never mess anything up.
I treasure peek gestures in general. Here are a few other useful (and/or inspiring?) ones:
previewing things in Finder by pressing (or, for power users,
holding
) the spacebar
using ⌘⇧4 with the intention not to take a screenshot, but just to (roughly) measure a distance between two objects, and then pressing Esc to abort
in tools like Figma and Sketch, using Ctrl+C just to quickly verify the color, and pressing Esc to cancel (rather than clicking to put the color into the clipboard or apply it elsewhere)
I also previously mentioned
Chrome typeahead
and
macOS menus
that had a similar property
Mar 31, 2026
definitions
12
mac
os
24
tips
★★★☆☆
The new book by Stewart Brand
is tackling a subject that’s important to me. The introduction struck a chord:
The apparent paradox is profound: Maintenance is absolutely necessary
and
maintenance is optional. It is easy to put off, yet it has to be done. Defer now, regret later. Neglect kills.
What to do? Here’s a suggestion: Soften the paradox, and the misbehavior it encourages, by expanding the term “maintenance” beyond referring only to
preventive
maintenance to stave off the trauma of repair—brushing the damn teeth, etc. Let “maintenance” mean the whole grand process of keeping a thing going.
Ultimately, alas, the book doesn’t really expand on this suggestion. While the volume feels rich and dense in some ways – illustrations, extra commentary, highlights – its surface area ultimately appears to be rather shallow. Ironically, given the subject matter, it feels like Brand fell prey to a bunch of “sexy” stories, some of them only tangentially related to maintenance.
I will just say it: I wish the author was more woke. The book is very male-coded. The main chosen areas of investigation are: motorcycles! tanks! guns! wars! There are moments towards the end where Elon Musk and Bill Gates are talked about as if it was still 15 years ago and we haven’t actually learned anything since. (No word of Cybertruck, either.)
We know maintenance tends to be unrewarded and forgotten come promotion time. We know that tedious tasks are often assigned to women and people of color while white men go around doing “genius things.” It’s hard to imagine women not being present in a book about maintenance, and yet – and I wish I was joking – the only woman of any significance in the entire book is… The Statue Of Liberty.
That aside, before opening the book, I hoped it would provide me some vocabulary and evolved thinking about maintenance that I could put to use, and there are some moments where it almost approaches what I wanted from it. Here’s a passage:
Powell credits the Israeli military with a mindset that naturally viewed damaged tanks as
soon-to-be-repaired tanks
, rather than the irredeemable flotsam of battle. The fact that [Israeli] commanders thought in these terms gave purpose and direction to the maintenance-related technical and tactical skill their crews possessed.
This is fascinating. Tell me how? Tell me what was needed to make it happen? But, unfortunately, outside of some basic tenets of “give the rank and file more freedom to do things” and “embrace improvisation,” the book doesn’t seem to offer more.
Elsewhere, there is this quote:
In almost every plant I worked at, QA was seen as a hindrance to hitting productivity metrics. We never got credit for a well-maintained manufacturing capability, but QA almost always got blamed when things went wrong.
…which, again, felt like a fascinating thread to pull on. But instead of digging deeper, this is left hanging without investigation.
The book doesn’t really have a proper ending with synthesis of what came before, and generally meanders a lot – to a point that the table of contents has more “digressions” than actual subjects. It also feels occasionally rambling and occasionally showing off (name-dropping people like Kevin Kelly and Freeman Dyson, or quotes from “beta-tester” readers that mostly serve to paint Brand in a positive light), which takes away from otherwise brisk writing and at times truly excellent storytelling. (The first chapter in particular is fantastic.)
If you want an easy-to-read, breezy, well-typeset book filled with historical anecdotes, and the above caveats do not bother you, this might be a fun read! But I expected more from it.
The one place where the book shines is pointing people toward other books – there are pages that feel more like literature review (done really well!), and the end matter has bibliography and recommended reading with notes. So in that way, while disappointing in and of itself, it could also become an interesting starting off point for more research.
Mar 31, 2026
book
book
review
maintenance
13
review
This is a
thoughtful post from Florian Schulz
about designing a typeahead experience.
I liked the details both within the implementation – for example, making sure the kerning is preserved! – but also in the presentation. I particularly enjoyed Schulz making the component demo itself, rather than using prerecorded videos. (I was delighted to discover that even the first large “picture” of the component is actually interactive!)
A small comment to this bit:
Unfortunately, not all browsers expose the selection or accent color of an operating system. For example, if a user would set the accent color in macOS to pink, the special CSS keyword color “Highlight” will still result in a light blue color in Safari. In other browsers like Chrome, the color will match the user preference. But since this is an attack vector for user tracking / fingerprinting, Apple made the right choice to hide the user preference from developers.
From my understanding, this is not necessarily correct. For example, in theory, the purple visited link color can be used for
fingerprinting
, by building a profile of whether or not I visited one of the hundreds of popular websites, quietly in the background.
The way browsers solve this is to never expose the color programmatically back to JavaScript – if your code asks for a link color, it will be blue regardless of whether the link was visited or not. It seems to me that the
Highlight
color could be used the same way here. Given that CSS now supports things like
color-mix(in srgb, Highlight 20%, white)
, it would even allow a designer to riff on the color without ever knowing what it is.
Mar 30, 2026
details
39
frontend
keyboard
23
Multibowl
is one of my favourite emulation projects because it’s a rare example of using emulators creatively, rather than for nostalgia or research.
It’s a 2016 game by Bennett Foddy and AP Thompson that reimagines older existing games as smaller pieces of a new, Super Mario Party-like experience. Two players randomly join one of 300 games – sometimes in medias res – with a small explicit goal that can be accomplished in about ~30 seconds, after which a point is awarded, another game is loaded, and so on.
All of this is done through actual emulation and fast switching of games’s original code:
Regarding the game choices, at the outset, I wanted to curate a list of moments of gameplay that would be meaningful if played for just a short period of time. Sometimes it’s obvious – you can take a moment from a fighting game where both players are low on health, or play a sports game from the start until the first point is scored. So that’s where I started. Over time, I figured out that you could make exciting moments in games that are not otherwise interesting for a competitive duel. For example, in
Dodonpachi
(a bullet hell game) we take away the player’s guns and challenge them to stay alive in a huge hail of bullets.
For games that were designed as cooperative experiences, I eventually gravitated toward the structure ‘score more points but do not die’, which forces the players to calibrate how much risk they take relative to the other player.
This excerpt is from a
2017 interview
of Foddy by Seb Chan from ACMI. There are many interesting moments in that interview, such as the issue of curation:
Multibowl is not a very precise historical curation like you might make for a museum exhibition, where you can only show a couple of dozen things at most. It’s a huge driftnet of games. There is no quality or historical significance standard, and no attempt to balance out the games in terms of nationality or gender. The only curatorial instinct that it follows is to find the most diverse set of game ideas. With each piece distilled down to a randomly-selected 30-second slice, there’s room for an infinite number of them.
In fact, contrary to a museum curation, the point of Multibowl is to have too many games for a single player to see. It’s best when it feels too big to grasp. I think, now that there are 300 games in there, it’s starting to feel that way.
Unfortunately, it is not possible to actually play Multibowl outside of special events, given copyright issues. In addition to general emulation copyright murkiness, Foddy adds, “I don’t think the actual bits of actual games have ever been used as the fabric of a larger game before.”
However, a really fun introduction to Multibowl is
another art project
from a now-defunct comedy duo Auralnauts, who actually played Multibowl pretending to be Kylo Ren and Bane, to hilarious results:
Mar 30, 2026
art
emulation
games
32
humor
10
54
The story about the original Macintosh’s built-in font set being named after “world-class cities” is well known and
documented by Susan Kare on the Folklore site
The first Macintosh font was designed to be a bold system font with no jagged diagonals, and was originally called “Elefont”. There were going to be lots of fonts, so we were looking for a set of attractive, related names. Andy Hertzfeld and I had met in high school in suburban Philadelphia, so we started naming the other fonts after stops on the Paoli Local commuter train: Overbrook, Merion, Ardmore, and Rosemont. (Ransom was the only one that broke that convention; it was a font of mismatched letters intended to evoke messages from kidnapers made from cut-out letters).
One day Steve Jobs stopped by the software group, as he often did at the end of the day. He frowned as he looked at the font names on a menu. “What are those names?”, he asked, and we explained about the Paoli Local.
“Well”, he said, “cities are OK, but not little cities that nobody’s ever heard of. They ought to be WORLD CLASS cities!”
So that is how Chicago (Elefont), New York, Geneva, London, San Francisco (Ransom), Toronto, and Venice […] got their names.
If you check out the actual
Philly stops
and witness all their provinciality, you can understand what Jobs was after:
Go to
first Macintosh via Infinite Mac
, open Infinite HD and MacWrite within, and you can examine the nine eventual fonts in their pixellated, cosmopolitan glory:
The list goes in this order: New York, Geneva, Toronto, Monaco, Chicago, Venice, London, Athens, San Francisco.
But: How about some hard evidence for the original anecdote? Turns out, the
March 1984 issue of Popular Computing
used pre-release Mac software and printed a screenshot of the names rejected by Jobs:
Since on the facing page we see the output in the same order, coming up with the correct mapping is not hard:
Cursive → Venice
Old English → London
City → Athens
Ransom → San Francisco
Overbrook → Toronto
System → Chicago
Rosemont → New York
Ardmore → Geneva
Merion → Monaco
One has to admire the final order of the Mac fonts that went from dependable and utilitarian at the top, to progressively more weird; this earlier list is all over the place.
In later releases of Mac OS, three other world-city fonts – Boston, Los Angeles, and Cairo – joined the party, so let’s show them here for completeness’s sake:
(Cairo is the classic icon font and in a way a predecessor of modern emoji, with inside jokes like
Clarus The Dogcow
.)
But that’s not the end of the story of the original Mac fonts. Let’s get back to 1983. On yet
another page of the magazine
, we see this list from MacPaint:
You can tell this screenshot is even older than the previous one, because it is itself set in an earlier version of Chicago, with a single-storey lowercase “a,” and many letterforms being works in progress. (I talked about the history of Chicago in my
2024 talk about pixel fonts
.)
And it is old enough that this isn’t just interim names for surviving fonts – it’s actually quite a few old fonts that didn’t make it to the release day.
Unfortunately, this particular version of Macintosh software remains unknown, but one similar pre-release version of the first Mac software
leaked
, and so we can take a look at some of these fonts, too:
(You can download a lot of these fonts thanks
to the hard work of John Duncan
. They are still bitmap fonts and might not work in all the places in modern macOS, but they seem to work in TextEdit at least.)
Here’s what I learned from looking at this list:
You can definitely see how unpolished some of these fonts are in terms of spacing, letterforms, and available sizes – kudos to the team for holding a high quality bar even though there was little precedent for proportional fonts on home computers at that time.
Even the fonts that shipped – London (née Old English), Venice (née Cursive), and Chicago (née System) – have had their letterforms tweaked and improved.
Chicago is not named Elefont, but simply System. Had the System name persisted,
this Medium snafu from 2015
would have been even more hilarious.
The name of the monospaced Elite font is likely inspired by one of the
two classic sizes of typewriter fonts
: pica (larger) and elite (smaller).
Cream came all the way from Xerox’s
Smalltalk
and was the
original system font
for Macintosh-in-progress, before Susan Kare created Elefont/​Chicago.
PaintFont was a symbol/​icon font, but distinct from Cairo and emoji in that it seems it was meant to be used only by the app to draw its interface. (Today,
SF Symbols
serve a similar purpose.)
Apple originally planned to use Times Roman and Helvetica, but this hasn’t happened presumably because of licensing issues. Only years later, the proper Times and Helvetica fonts were introduced. Here’s a comparison:
But the most interesting thing I haven’t noticed before are two fonts called “
Marie Osmond
” and “Patti.”
I am reaching outside of my well of knowledge here, but from context clues I’ll assume the latter means
Patti LaBelle
. And so, pulling on that thread, it’s kind of cool to imagine an alternate universe where the original Mac fonts are neither suburban Philly stations, nor well known cities, but something like this:
Mar 29, 2026
history
31
mac
os
24
typography
14
In the Fallout 3: Broken Steel addition, the team wanted to introduce a moving subway train under Washington, D.C.:
However, the engine did not have any moving vehicles. Instead of adding a new kind of primitive into the game engine, the creators… made the player character itself become the subway car when
in motion
This was done by removing freedom of movement from the player, forcing the character to slide on the floor, and equipping him with… a “metro hat.”
The visuals of people hacking this to use it outside of the subway area are really funny:
Technically, it was not a hat, but
a right-arm armor
, as you can see from the right hand missing in the above picture.
The FPS genre is filled with all sorts of hacks for hand-held weapons, to compensate for the challenges of depicting things accurately not feeling as great…
…but I have never heard of someone “wearing a train.”
(The title comes from
this post
.)
Mar 29, 2026
games
32
hacks
A thoughtful
26-minute talk by Imani Joy
, the solitary full-time designer on Mastodon, reflecting on her nine months there:
It’s an interesting peek behind the curtain at designing for this particular space, and the many unenviable constraints: lack of data, care for privacy, tension between Mastodon’s power-user early adopters (“they are values-driven, they want control, they’ll tolerate a lot of the clunkiness of the Fediverse”) and “mainstream audience [that] expects polish.”
At some point, design needs to be authoritative, but how do you combine that with wanting the process to be as inclusive as possible? The product itself is a federation of various servers that can exert their own control – so how do you bring it all together under one neat umbrella for the user? (Also a challenge for Android in comparison with iOS.) The mainstream design has certain fashion-y tendencies. How to make sure you don’t lose yourself while chasing them, but also not to stay ossified out of fear of making changes? (Wikipedia, Internet Archive, and other similar places look and behave a certain way, after all, and it’s not usually because of lack of talent to “modernize” them.)
The most interesting thing to me was this:
It’s easy to talk in terms of who to optimize for. Things get harder when you start to articulate who you won’t optimize for, what trade-offs you must make in pursuit of your goal, and who you’re going to risk letting down along the way. What the team needed from me more than anything was not the probabilities, not the usability findings, not the story of who we’re making happy. They needed to hear who will choose to disappoint and why. And I told them that building the best experience on Mastodon means that we’ll solve for the extremes, but we won’t center them. And sure, we do risk frustrating some power users who want absolute control over their profiles, but that risk is necessary to optimize the experience also for browsing users.
When we were working at Figma in 2019 shipping an update to text line height algorithms (moving them from the way print does things to
the way web does things
), I started an internal document called “The new line height and its discontents,” where myself and the team deliberately wrote out who will be most annoyed about the changes, and why. We listed our arguments, workarounds, even “deal sweeteners” (“but look at this
other
thing that will get better as a result!”), but we also tried very hard to be candid with ourselves. Some people were not going to be happy no matter what we do or say. Do we know precisely who these people are and are we okay with that? I’d recommend that approach for any change-management project, rather than keeping fingers crossed or
toxic positivity
Joy so far worked on quote posts and new profiles, and I appreciated her ending the talk on a note of recognition for these kinds of projects in these kinds of settings:
I know that we’re building something that will continue to be imperfect, but it doesn’t have to be perfect to make a positive difference in the world.
Mar 28, 2026
change
management
conference
talk
54
Column view
cut its teeth on NeXT computers…
…and blossomed on early versions of Mac OS X…
…but where I thought it really shone was the first iPods:
This was perhaps the most fun you could ever have navigating a hierarchy of things; it made sense what left/​right/up/down meant in this universe, to a point you could easily build a mental model of what goes where, even if your viewport was
smaller than ever
It was also a close-to-ideal union of software and hardware, admirable in its simplicity and attention to detail. This is where Apple practiced momentum curves, haptics (via a tiny speaker, doing haptic-like clicks), and handling touch programmatically (only the first iPod had a physically rotating wheel, later replaced by stationary touch-sensitive surfaces) – all necessary to make iPhone’s eventual multi-touch so successful. And, iPhone
embraced column views wholesale
, for everything from the Music app (obvi), through Notes, to Settings.
Well, sometimes you don’t appreciate something until it’s taken away. Here are settings in the iOS version of Google Maps:
I am not sure why the designers chose to deviate from the standard, replacing a clear Y/X relationship with a more confusing Y/Z-that-looks-very-much-like-Y. They kept the chevrons hinting at the original orientation – and they probably had to, as vertical chevrons have a different connotation, but perhaps this was the warning sign right here not to change things.
I think the principle is, in general: if you’re reinventing something well-established, both of your reasoning
and
your execution have to be really, really solid. I don’t think this has happened here. (Other Google apps seem to use standard column view model.)
Mar 28, 2026
apple
24
details
39
finder
google
interface
design
62
mac
os
24
next