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.)

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.

A 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.

A 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.

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.)

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.”

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.

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.

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!

(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.)

5
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.)

(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 1, 2, 3). 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 1, 2, 3).
• 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.

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.

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:

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.

A 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.)

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!

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.

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.

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:

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:

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.

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.

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 deadline!

(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.

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.

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.

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.

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.

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.

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).

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.

A 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.

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.

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.

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!

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

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.

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

★★★☆☆

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.

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.

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:

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:

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.)

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.

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.)

An excellent 17-minute video from The Art Of Storytelling that analyzes the now-infamous 2021 Mark Zuckerberg Metaverse introduction video:

What I liked about it is that the author goes beyond cheap shots and deeper into both storytelling aspects (drawing from his experience)…

Now, as you can tell, the big problem with the design and execution of this video is that the producers failed to recognize the importance of point of view in telling this story. Now, perspective is already very important in any film, but it’s doubly important in a film for which one’s point of view in reality is also the subject. But this failure is present even in some of the more mundane parts of the film like the interviews that Mark does with various meta staff members. Now, as it’s plain to see, these are not real interviews. They’re fully scripted and staged – again, a classic mistake in corporate film. You can even tell that they’re not looking at each other. They’re clearly reading from a teleprompter. Yikes.

Of course, the entire premise of an interview is that two people are speaking candidly. So watching an obviously fake interview can be deeply unsettling as the speakers try to act out natural conversation and inevitably fail. This is why so many people in this video, including Mark, seem to not know what to do with their hands while speaking. It’s because they’ve been told to act naturally in a social situation that does not normally exist.

…and the meaning of these kinds of propaganda-esque announcements:

They are joined by some friends who are calling from Soho to tell them about some cool augmented reality street art that they’ve just discovered. […] And with a wave of his hand, Mark teleports the artwork into his spaceship so that he can appreciate it for himself, thus extracting this street art from any sense of place and context, which is the point of street art. I know this might sound like a nitpick, but I think it’s just worth lingering on the fact that, you know, in this high concept tech demo about how this technology will empower people to appreciate art in new ways. Nobody paused to ask what the social and cultural function of street art actually is.

The entire introduction video comes across as thoughtless and careless – “It’s not a product launch or even a demo. It’s just a cartoon about the world Mark Zuckerberg is telling you that you will one day live in.” – and some of the observations here will be relevant to other things, even in other mediums: UI redesign minisites, the font announcements articles, rebrand unveils, and so on.

I would love similar analyses of Apple’s stuff – not just the most obvious parallel which would be the 1987 Knowledge Navigator vision video, but some of the more recent scripted virtual keynotes, too.

Connecting to public wi-fi networks with their captive portals is always a bit of a wonky proposition, and nothing makes public wi-fi wonkier than using it on a plane.

I believe that the resurgence of https made things harder – if the captive portal doesn’t kick in, no secure traffic can happen – and over time I just started remembering that “captive.apple.com” is a reliable HTTP-only destination to visit.

But I noticed this week that United’s onboard wi-fi network is called “Unitedwifi.com” as a reminder where to go once you are connected, to avoid that problem. I thought this was a nice touch.

Not long ago, a blog I otherwise like a lot included this passage:

Designers have been saying this for years. Cameras don’t take pictures, photographers do. Tools don’t make you a better designer. Now the PM world is arriving at the same conclusion.

I am not linking to the post because I hear this argument from time to time, and I want to comment on the general notion.

I think I understand the sentiment behind it: You’re not a designer because you know all the Figma shortcuts. You’re not a perfect typewriter away from The Next Great American Novel. Mastery of a tool is not mastery of the subject matter. And there is definitely a certain amount of performative pretense of an insta photo of a meticulously arranged desk with a bougie keyboard, going at length about the only correct set of presets and plugins, or an idea that “if only you do this one creative habit, a firehose of creativity will follow.”

But I also disagree. Good tools do make you a better designer.

A good tool can make you go faster and, as a result, let you spend more time doing revs and trying new things. A good tool can make you go slower when needed, practicing a connection with the material underneath.

A good tool will prevent you from shooting yourself in a foot, will teach you new things about what you’re doing – and perhaps even about yourself.

A good tool will value your growth, make you reflect on your growing body of work, and push you to try harder.

A good tool can inspire you. A great tool can make you fall in love. A bad tool can make you walk away, and a horrible tool will make you never want to come back.

A good tool will make you seek out more good tools.

Sure, people wrote books on a BlackBerry. Would you want to? Sure, the best camera is the one you have on you. But wouldn’t you prefer that camera to also be the best camera for whatever it is that makes you tick – a great sensor or glass, an amazing build quality, a friendly user interface, a logo that makes you want to step up, or some particular quirk or sentiment that you can’t even explain, but matters a whole lot to you?

I’m told I should be annoyed if someone’s first reaction to seeing a nice photo I made is “what kind of camera do you use?”, as it diminishes my accomplishments as a photographer. But: I chose the camera, and bolted on the appropriate lens, and realized over the years the aperture priority mode and very precise focus area is what makes my brain happy. I went through other cameras before, and learned I didn’t like them and I liked this one. At some point in my life I even ventured out into the frightening underworld of the settings menu, opened a new browser window, and decided “I will now try to understand all of these terms.” It took years, but I did.

The reason I enjoy scanning and processing old documents is because I invested in my tools. I have a little keypad, a bunch of hard-earned Photoshop actions, and some bespoke Keyboard Maestro combos that boss Photoshop around. This little tool universe doesn’t just make me more efficient, but it also makes me have fun.

I’d go even further. The mastery of the subject matter and the mastery of the tool are both important – but they also have to be joined by fluency with tool choices, and deep understanding of the relationships you have with your tools.

No single writing advice book will give you a perfect recipe, but read ten of them and scan twenty more, and you might compile the right mixtape of practical tidbits for your brain, and inspiration for your soul. Likewise, you have to try out a bunch of tools – some bad ones, a few great ones – to understand what you need. Not just for efficiency, but also for enjoyment, and ambition, and flexibility or maybe rigidity, and this sort of unmeasurable feeling of a tool getting you, or a tool made by someone like you.

Maybe it’s the 1960s typewriter you need, or a newfangled e-ink-based writing implement, or maybe you just have to open TextEdit and close everything else. I’m not going to tell you the novel comes out then. But the novel might never come out if you don’t figure out what tool can help get it out of you.

You also have to recognize the telltale signs when you outgrow the tool, or when the tool starts disappointing you. Over the years, I learned that I hate InDesign, but that I hate LaTeX even more. I switched from Apple Notes to SimpleNote in 2012, went back to Notes in 2017, and just this year moved over to Bear. I once cargo-culted Scrivener for writing and ran away screaming, but I also once cargo-culted DevonThink and still use it today, in awe of its clunkiness and old-fashionedness that match my own.

AI tools are still tools. And generative AI will allow you to build more tools for the solitary audience of just you – but, like elsewhere, it will require some understanding what makes for a good tool and what makes for a good tool for you.

Craig Mod wrote recently about using AI to build his own custom tools:

My situation is pretty unique. I’m dealing with multiple bank accounts in multiple countries. Constantly juggling currencies. Money moves between accounts locally and internationally. I freelance as a writer for clients around the world. I do media work — TV and radio. I make money from book sales paid by Random House via my New York agent, and I make money from book sales sold directly from my Shopify store. […] Simply put: It’s a big mess, and no off-the-shelf accounting software does what I need. So after years of pain, I finally sat down last week and started to build my own.

But I bet Mod knew what tool he needed to build based on his experience with tools that didn’t work for him – and software and design in general.

Elsewhere, Sam Henri Gold in a widely-shared essay that is worth a read, about MacBook Neo and the beginning of the tool journey:

He is going to go through System Settings, panel by panel, and adjust everything he can adjust just to see how he likes it. He is going to make a folder called “Projects” with nothing in it. He is going to download Blender because someone on Reddit said it was free, and then stare at the interface for forty-five minutes. He is going to open GarageBand and make something that is not a song. He is going to take screenshots of fonts he likes and put them in a folder called “cool fonts” and not know why. Then he is going to have Blender and GarageBand and Safari and Xcode all open at once, not because he’s working in all of them but because he doesn’t know you’re not supposed to do that, and the machine is going to get hot and slow and he is going to learn what the spinning beachball cursor means. None of this will look, from the outside, like the beginning of anything. But one of those things is going to stick longer than the others. He won’t know which one until later. He’ll just know he keeps opening it.

I am bothered by black-and-white, LinkedIn-ready statements. “Tools don’t make you a better designer” feels like another version of the abused and misunderstood “less is more.”

My camera taught me to be a better photographer. DevonThink told me how to better organize my thoughts. Norton Utilities showed me how to have fun when doing serious things, and Autodesk Animator how to be serious about having fun.

I’m a toolmaker, so perhaps I arrive at this biased. I endured some crappy tools, wrote some okay ones, benefitted from some great ones. I don’t think I would have become a designer without them.

Software engineering has long had a concept of “premature optimization” – overbuilding things too early in anticipation of future that might or might not come.

I feel design has a version of that, too. Here’s viewer menu hierarchy in Google Drive:

One should always feel very uneasy about a menu with just one item, like Insert here. Even within the View menu, one could imagine streamlining all the commands to be in one main menu, rather than two tiny submenus (coupled with pretty excessive width that makes for an interaction that feels like walking a tightrope).

These are the menus for a PNG image. It’s entirely possible other file types offer more options and this menu structure earns its keep then, paying off in consistency over a long run – but I tried a few file formats, and the menus all looked similarly sparse.

As a counterpoint, here’s an example I just spotted in the context/​right-click menu in Apple’s Notes:

When you have one device, the three options get appended to the ground floor of the menu. But if you have more than one, they all get ejected into a submenu.

I like this soft consistency of introducing hierarchy only when it’s needed – or in reverse, flattening/​streamlining it as necessary.

I have mixed feelings about this one particular use, however. This menu is already very long (and seemingly abandoned – look at table and checklist and link options), so in this case perhaps a consistent submenu would be overall better. Also, the “Insert from iPhone and iPad” label is long and makes the entire menu slightly wider.

But as a pattern, it’s worth considering. (Just for completeness’s sake, you could also half-streamline by adding a submenu for the iPhone and another one for the iPad. But in this particular case, it’d also likely be a bad idea.)

I occasionally move older writing that still feels interesting to my new site, and today I republished the 2015 story about a strange bug that brought back an old pixel font from beyond the grave:

Some of the technical details inside are obsolete, but the story might still be fun. (Plus, it seems like at every job I have, I eventually stumble upon a bug that brings back something from the annals of history. Here’s one from 2019.)