The best thing the crypto industry coined might have been the expression “rug pull,” but I’m not happy about that. To me, it perfectly describes how it feels when an app or a website randomly changes your scroll position for no rhyme or reason.

You’ve seen it so many times before:

• you start reading a webpage, but it throws you back to the top when JavaScript finishes loading
• you start reading a webpage, and ads or other stuff appear and shove you around up and down
• you press a back button and that goes to the previous page… but to its top, rather than where you actually were
• you zoom in or out, the position isn’t recalculated properly, and suddenly you see a different part of the page and lose your orientation

To me, the scroll position is as sacred as the mouse pointer position, given the two are related whether Scroll Lock is around or not: one is you, the other is the world around you.

But there are moments when software scrolling with the user or even for the user is appropriate, and here’s one example:

When you switch tabs, the content below should always scroll to the top, but it doesn’t here.

Here’s an even worse example, also from Settings:

Why should the content scroll to the top here? Because in these situations, the fact that the content container gets reused is just a technical quirk of the implementation. From the user’s perspective, this is all new content, and new content should always start at the top. Otherwise, things will get confusing really fast; imagine it especially in the default configuration without scrollbars, where you might assume result number 6 is the first result, or completely miss the most important, topmost options.

(Before you ask: Yes, I also see this in Tahoe.)

Randomly found this 2014 Dribbble from Jamie Nicoll and it made me smile:

For context, Save For Web was a popular export function in Photoshop at the peak of its use for web design, but assigned a rather unpleasant ⌘⌥⇧S shortcut. Using it often turned your hand into a… claw of sorts.

There was a Tumblr cataloging real and humorous photos of people pressing Save For Web. You can still find parts of it on Internet Archive, and here are some choice photos:

This is funny, but I actually found it enlightening – and lightly frightening – to ask coworkers how exactly they press common shortcuts like ⌘Z, ⌘C, ⌘V, and so on. There was a lot more variety than I expected.

(My basic heuristics say: three-modifier-key shortcuts should not be assigned to anything used often.)

A fascinating 25-minute video from Mark Brown at Game Maker’s Toolkit about how the team building Grand Theft Auto 3 conquered the technical limitations of PlayStation 2:

How do you squeeze a city that occupies over 50 megabytes into the 32MB memory of the console? You simply do what The Truman Show did, and construct the city around the player as they’re moving around:

This has, as you can expect, a lot of technical and even game-design consequences, and the video goes into a lot of detail on these – including Brown rebuilding the Grand Theft Auto 3 source to visualize things better.

This technique is also used in interface design, for example if you have a really long list of things that would take too much memory or GPU power to render. What the video calls “streaming” is, in the context of UI, often called “virtualization”: instead of having a full long list (or an entire world), you abstract it away – or, virtualize – into something nimbler.

Some of the challenges and techniques used by Grand Theft Auto 3 apply pretty directly here, as well:

• you can use UI skeletons as “low poly” models,
• in some contexts, you can guess the user is more likely to move in one direction (for example, going through fonts in a font picker), and more eagerly preload where they’re going to look next, rather than symmetrically in both directions.

On the other hand, “speedy players” and “pop in” can’t ever be solved because any UI list is random access, and slowing users down is not typically appropriate; better to make loading as pleasant as possible than introduce any roadblocks, even if figurative ones.

Since the early 2000s, Mac OS X had a few orientations of icons depending on whether they were applications, files, utilities and so on:

In 2020, macOS Big Sur unified those styles and made them more iOS-like:

A few years later, Jim Nielsen revisited the icon “Big Sur-ification”, and showed examples of apps that did the transition really well, but also those where the transition felt… lazy, essentially shoving their previous icon into a roundrect.

For those, Nielsen proposes some alternatives that are delightful to see:

The Word/​Excel/PowerPoint/​Outlook explorations are particularly nicely done.

In his latest video, Shelby from Tech Tangents unpacked, installed, and put to use a truly forgotten product: IBM 3119, one of the first consumer flatbed scanners.

The setup was a small nightmare, needing a rare hardware card installed in a specific computer, an ultra-particular combination of two operating systems working in lockstep, and even some careful memory balancing.

Even after all that, a 300dpi page scanner in the late 1980s was still a force to be reckoned with. It’s hard to remember how enormous scanned files were compared to anything else then, even on a black-and-white scanner like this one. The video shows a simple 90-degree image rotation in highest quality requiring over 9 hours, and I believe it.

But deep inside the video, at precisely 19:31, for only ten seconds, something appears that is absolutely worth celebrating. The nascent scanner software has a “curves” feature that allows you to redraw the shades of gray to capture shadows, highlights, and midtones exactly how you want them. Today, the feature would look something like this, with a real-time preview:

There would be absolutely no way to do something like this in the late 1980s, when just rotating an image is an overnight operation, right? And yet:

How was this accomplished? Absolutely brilliantly. Remember the palette swapping technique? Here, the entire screen’s palette is 256 shades of gray. It’s a very particular kind of a linear palette, and so you can easily take that line and… well, turn it into a curve. Since palette swapping happens on the graphic card, it takes as little as one frame of time, allowing for it to react to mouse movements as they happen.

This must have been mind blowing to experience in the moment. Sure, it’s only a preview, and actually applying curves to the image would take many minut—

No. This is a wrong frame of mind. Here’s my hot take: There are moments in software where the preview is more important than the feature following it. That’s because the preview making things faster isn’t just the difference between finishing something sooner or later. It’s a difference of doing something or not doing it at all. Would you even attempt to use curves if each adjustment took minutes or hours, especially in a land without undo?

I love this preview that hints at what the future will be. I like this clever use of extremely limited technology and tight collaboration between engineering and design. It must have been nice to be in the room whenever someone had the flash of insight to use palette swapping this way.

I have a confession to make. I prefer Apple TV’s 2015 remote:

The remote was universally ridiculed for its “which way is up?” problem – too much vertical symmetry which didn’t give your hand enough cues to know whether you’re picking it up the right way or the wrong way.

Apple tried a half-measure first; in 2017 they broke the symmetry by making the MENU button slightly distinct in visual and tactile ways. Hindsight is 4K, but I don’t think it had a chance of working – the tactile cues were too subtle, and the visual ones do not matter when you’re not looking:

So Apple overshot – the subsequent 2021 edition was a full-measure-and-then-a-half:

The remote shrank the touch surface but otherwise drastically increased the volume, and added four arrows, two new buttons, and a strange iPod-inspired clock wheel interaction on top. And to me it started feeling a bit complicated, inching toward the very TV remotes that earlier designs ridiculed. (It also wasn’t as pleasant to touch, as the buttons feel a bit rougher.)

But the reason I like the 2015 remote is primarily because it introduced one of my favourite gestures in recent history: tap to see progress.

It’s hard to describe how wonderfully light this interaction feels every time I use it. You just tap anywhere on the remote’s top half, you see where you are in the video via a subtle UI, and then wait a few second for it to disappear. After this, doing the same in every other player – YouTube, Netflix, HBO Max, anything on a Mac or even the iPhone – feels clunky and heavy. In many of them, you can’t even see were you are without stopping the video!

It gets better. Tap for the second time, and the elapsed time gets replaced by current time, and the remaining time by what the clock will say whenever you’re done watching. I thought this is delightful and clever, sneaking in clock functionality without showing it all the time.

There is also this really nice gestural separation. When you watch the video, taps and swipes are safe. Anything that is “destructive” – that is, causes the video to stop, or rewind, or fast forward, is on the “click” layer: press stronger on the center to pause, or on either side to move forward or back.

What I’m describing feels mechanically similar to other input devices, but the devil is in the details. On smartphones, everything is a tap, so you don’t really get anything lighter. On a Mac, tap as a gesture could only be available for people who opt in to press to click on their trackpad (like I do) – but the fact that tap is the default for clicking, means that can never realistically happen.

The Apple TV tap feels conceptually like Mac’s hover instead, but so much more pleasant and elegant and simple. (I want to prototype tap on a Mac as a lightweight “explainer,” showing tooltips there instead of on hover.)

To be fair, the tap gesture still exists in the still-current 2021 Apple TV remote, too – but the tap area is much smaller.

And just in case you were curious, these are the first two editions: the 2005 remote – shipped with the iMac, predating Apple TV – and the 2010 remote. (I’m referring to model years, because Apple’s own names are so confusing.)

I don’t have access to Apple’s user feedback, but I guess that Apple’s 2021 design was likely the very right thing to do. But looking at four-and-a-half of these models side by side, I am still in the 2015’s minimalistic, unusual, innovative corner.

On April Fools in 2021, the popular xkcd comic ran Checkbox, which was a Morse code puzzle in disguise. (It’s interesting to see the community trying to figure out what it actually does.)

Engineer Max Goodhart built the front-end and wrote a summary of the whole project:

This year was a doozy. We specced and scrapped several different ideas in the months leading up to today. We finally settled on today’s concept just 3 days ago. The need to do something simple was a really useful constraint, and we leaned into the idea of making something primitive but deep.

The team seems to have had a lot of fun with it, including even JavaScript being encoded in Morse Code (the link in the blog post no longer works, but you can still see it on the Internet Archive).

Goodhart also wrote about the immense challenge of adjusting the Morse tapping speed to the user, which counterintuitively ended up needing… adjusting the user to the speed. But the best part is that the server communications used the Morse code in URLs, as well:

We took great pains to make the API for this project use morse code in the transport. If you take a look at the network inspector, you’ll notice that the URLs requested have morse code in them.

This worked for every combination of letters imaginable, with two oddly specific exceptions: a solitary E, and a solitary I.

I liked this description of what transpired next, which would have made me think I was going insane, too:

Then, an even stranger thing happened. I copied and pasted the correct URL into my browser and pressed Enter, and right before my eyes, it deleted the ”.” from the end of the URL and returned a different result.

I was delighted to discover an answer here, not only because in retrospect it’s such an obvious thing that was staring us all in the face for decades, but also because it has interesting URL construction consequences.

The Pixar animated short Lifted was released in front of Ratatouille in 2006:

I’ve always been amused by this imaginary interface, which is so clearly not how any sort of computer would work.

Or so I thought. These are photos I took in Melbourne in 2024 of CSIRAC, Australia’s first digital computer from about 1949:

This is a “console” of the computer, used to tactically probe or input specific memory addresses (in binary), and to control functions like stopping and starting the program. Any proper programming and eventually inputting data would happen using gentler I/O devices like typewriter keyboards, paper tape, and magnetic storage.

Physical consoles like this one were last seen in the 1970s on hobbyist home computers such as the Altair 8800, and the Console app on your Mac diligently spitting out logs is its spiritual and virtual successor. But even if a CSIRAC console feels hostile today, 75 years ago it was quite the opposite:

And [CSIRAC] helped there too. It could display all its working registers and the last 16 instructions executed. It could be given an address at which to stop (a “breakpoint”), and be stepped by one instruction at a time. It even had lights to show the computer’s internal states. This was a user-friendly computer.

CSIRAC stood for Commonwealth Scientific and Industrial Research Automatic Computer, a typical naming scheme of the era. We also got ENIAC (Electronic Numerical Integrator and Computer) in 1945, BINAC (Binary Automatic Computer) in 1949, EDVAC (Electronic Discrete Variable Automatic Computer) in 1946, ILLIAC (Illinois Automatic Computer) in 1952, and then SEAC, SWAC, ORDVAC, TREAC, AVIDAC, FLAC, WEIZAC, BIZMAC, RAMAC, and UNIVAC.

The story goes that the name of 1952’s MANIAC (Mathematical Analyzer Numerical Integrator and Automatic Computer) was chosen to highlight and put a stop to the goofy naming practice. Did it work? I am not sure. Not only two more MANIACs were produced, but we also got 1953’s JOHNNIAC (nicknamed “pneumoniac” since it needed a lot of air conditioning), and SILLIAC (Sydney ILLIAC) in 1956. The last computer I can find using that naming scheme was TIFRAC, operating in India between 1960 and 1965.

CSIRAC had real work to do, but today it is known chiefly for being the first computer to play music in real time. The quality is… I’ll let you judge, with links below pointing to short MP3s preserved by Paul Doornbusch and subsequently Internet Archive:

• Auld Lang Syne
• Chopin’s March
• In Cellar Cool
• (I particularly enjoyed an alt recording of In Cellar Cool where CSIRAC itself appears in a background as a constant humming presence.)

Do you miss your PC speaker yet?

Engineers working on other room-sized computers of that era did similar things; whether this was solely one of the first attempts to humanize the big scary machines, or a distraction from the computers’s typically military uses is left as an exercise for the listener.

Today, one of the 1960s machines still plays music, headlining a fascinating annual tradition – every December, the PDP-1 restoration crew at the Computer History Museum in California invites visitors to sing carols with the computer older than most of them.

The last photo takes us back to where we started. Neither CSIRAC nor PDP-1 might be user-friendly by today’s standards but damn, wouldn’t you want some of your computer’s interface to feel this way?

A surprising entry in the thread started by Photoshop and continuing through screwdriver handles is this 11-minute video from Errant Signal about a platformer game called Derelict Star:

I was inspired by the video, and really enjoyed its exploration of a demanding game that’s composed of just a few mechanics that are done really, really well:

The number of inputs are small, but the expression those inputs allow is deceptively expansive. […] Derelict Star’s various areas are all built to explore the way movement systems function and even interact with one another.

I think of user interfaces similarly, and of their need to build a certain consistent vocabulary of names, gestures, interface elements, concepts, and so on. Perhaps in an enterprise app you right click and discover something useful in a menu, and this will teach you about the usefulness of right click menus in general. Maybe pressing ⌥ to get to alternate symbols on your keyboard would inspire you (either consciously or not!) to try holding ⌥ in said menus, only to discover this brings up useful alternative options. Maybe seeing a keyboard shortcut next to one of these options will suggest to do that next time, and so on, and so on.

I really loved this bit in the video that could apply to a lot more software than just videogames:

It took me maybe an hour to do this, but right on the other side is a checkpoint. The game is hard, but it isn’t cruel. It’s designed to challenge you, but it has faith in your ability to complete it.

The narrator uses the term “ludocentrism” to refer to games that ruthlessly prioritize the mechanics and gameplay over narrative, aesthetics, and so on. (“Ludic” meaning “relating to play.”)

Of course, the calculus of what videogames care about will be different than goals of creative software or enterprise software; no one cares about the hero’s journey of the largest number in your Excel spreadsheet. But I think some version of ludocentrism applies to “boring”software as well. My beliefs here are probably something like this:

• you can’t reduce everything to just functionality or just efficiency,
• especially in creative moments of software use,
• and people use software creatively much more often than we suspect, including software not thought as “for creatives.”

Should you ever be worried that displaying just one glyph could take almost 2 seconds and slow down your website by as much? Naw, of course not. This wasn’t a problem already in the 1980s and, in the lord’s year 2026, computers are pretty good at rendering a letter or a symbol at a moment’s notice.

Ha. I was just messing with you. Of course you should always be worried about fonts. All the time. Typography is beautiful, but fonts are brutal. They will constantly put you to the test, they will find ways to get out of alignment faster than a Zastava Yugo, and they will teach you about corner cases in places you didn’t even realize had edges.

Fonts will break your heart like it’s the month before the prom again, and again, and again.

Or, in Allen Pike’s case, break a heart somewhat literally. Pike wrote a nice quick story of the complexity of what needed to happen to show the heart emoji, and how under a very specific set of conditions – a certain browser, a certain emoji font, a certain emoji within that font – this led to an extreme slowdown.

What’s really interesting is that in order to fix it, Apple can either improve Safari or the font itself, and at the moment of writing, it wasn’t clear what was the right thing to do. (Oh, yeah. Fonts don’t just have bugs. Fonts have many kinds of bugs.)

Another interesting in-between-the-lines thing is that Apple’s emoji are perhaps the only survivor of the original skeuomorphic pre-iOS 7 era. Even today’s emoji party like 2008 never ended – still glossy, still textured, still bitmapped. I’m curious whether somewhere deep inside Apple, there exist exploratory designs for flat, vector versions of emoji that never saw the light of day.

I found this 9-minute video from Rex Krueger about screwdriver handle design really interesting in the context of my post about Photoshop’s dialogs.

Screwdriver handles evolved over the decades in response to user needs and usage patterns, with a few clever affordances: some for everyone, some for specific use cases that might not be obvious.

I think by now all the basic onscreen UI elements – input fields, pop-up menus, checkboxes, buttons, top menus, sliders, and so on – have similar richness, as do all the core input devices like a keyboard, a mouse, a trackpad, or a touch screen.

That doesn’t mean that everything is set in stone, that no changes are possible, and that stuff that fell out of favour can ever be taken away – after all, computer usage, input devices, and conventions are evolving much faster than screws at this point – but that one has to be aware of the history so that the changes are intentional, not accidental.

A few select comments from under the video that I found interesting:

The Craftsman handles are also different colors for Phillips and slotted screwdrivers.

The fluted handle was patented. So anyone else wanting to make a screwdriver would have to pay the patent holder. So they tried alternatives to make more money. That is the real reason until the patent expired. Plus if they invented a “better” way and held the patent, others would have to pay THEM.

The Swedish word for screwdriver is “skruvmejsel” with literally translates as “screw chisel.”

It’s hard to be in charge of continuity on a movie set. It would already be difficult under the best of circumstances: after all, you can’t freeze the sun in the sky, prevent hot drinks from going cold, cigarettes from extinguishing themselves, or entropy in general from doing all the stuff it loves doing.

But on top of that, scenes are shot out of sequence, and movies are shot out of sequence. There are pick-ups if you’re lucky, and reshoots when you’re not. About the only time your job will be noticed is if you mess up: cue Superman’s reverse CGI moustache, Josh Trank’s Fantastic Four wig situation, Commando’s damaged-then-pristine Porsche, and so on and so on. (This 7-minute YouTube video is a great walkthrough from an expert.)

Apple famously freezes time on their phones in all the promotional materials to be 9:41am. The specific moment they chose is a celebration of the first iPhone unveiling to be at around that time, but it also makes production easy – while people won’t mind that the time on the screen doesn’t match the current time, or even that it doesn’t seem to advance at a normal rate, they will definitely notice if you happened to splice two screenshots with different time side by side, just because you didn’t anticipate that splice as you were preparing them. So it’s easiest just to avoid this situation altogether.

But what I didn’t realize until today as I was recording the previous post’s screengrab is that 9:41am is also enforced whenever you record your phone’s screen via QuickTime. It’s a peculiar feeling: Start recording, and the time on your phone jumps to 9:41. Yank the USB cord out, and it’s back in sync with the universe:

Oh yeah, the date changes too, for the same reason – to January 9, 2007.

In a time-honored Apple tradition, I can’t decide whether I’m annoyed at it (there seems to be no option to turn it off), or admire it.

I want to show you something glorious. This is Bear, the note taking app:

There are desktop apps that get flustered if you ⌘+Tab away and back, misplacing focus or closing a dialog box inside. There are iOS apps that fully reset themselves whenever they get swapped out of memory and have to be reloaded.

But Bear, right here, remembers which note you were on, and exactly where you were in that note, even between phone reboots.

Software is transient and malleable, and one of the hard parts is knowing when that’s beneficial and when detrimental. In real life, you can leave a notebook on your desk, open on a certain page, leave a pen pointing to a specific word – and then depart for a two-month trip to Europe. You will find your notebook exactly how you left it. Why shouldn’t software behave this way?

Also, another thought: This is very likely not something users will complain about when broken, or suggest when absent, even if you go out of your way to open yourself for feedback. Just swapping an app out of memory is hard to understand and “repro” (in engineering parlance). There’s a certain design mindset and taste necessary to notice and care, and a certain vision to carry it through.

The lack of direct user feedback doesn’t mean it’s not worth doing. It just means that there are some things that designers and only designers will know how to properly weigh, describe, and prioritize. If you have a few design-minded users that actually send you feedback like this – treasure them. But most likely this will have to come from “inside the house.”

To me, it’s clear that within Shiny Frog (the makers of Bear), there are people who care about this kind of stuff, and leadership that trusts them. Kudos.

This is perhaps my favourite feature in Lightroom. You press ⇧T, you draw a few lines, and presto – your photo is now even:

This is doubly magical to me. The first part is that this is even possible – that you can straighten the photo in both dimensions after the fact, and save for some parallax nuances the viewer won’t know any better.

For decades, this has been the domain of tilt-shift lenses, but if you ever tried to use one, you know how harrowing of an exercise this is. A tilt-shift lens looks more like a medical device and less like a piece of photography equipment:

The “obvious” way to emulate a tilt-shift lens in software is a bunch of sliders, and Lightroom has those also…

…but that’s still pretty cumbersome in practice, abstracted in a strange ways, like piloting a plane by pulling the linkages connected the flying surfaces: you will admire someone who can do that, but won’t ever want to do it yourself.

Hence the second magical moment: The team created the new interface I showed at the beginning, where you point to things that should be straight directly, and the necessary tilt-shift calculations happen behind the scenes.

Alas, Lightroom didn’t fully stick the landing. The interface is a bit jittery, and missing nice transitions that could help understand what’s going on. But what brought me here was this unpleasant interaction:

What’s wrong with it? If you want to play along, stop here and ponder: How would you improve it? Because this is a classic UI exercise where there are symptoms, and there are problems, and there are principles under the hood of it all.

The first possible improvement: Don’t do a dialog like this. These are ancient and so annoying. Every time I see a centered dialog covering everything, popping up in response to a delicate mouse operation, I want to shout “read the room!” It’s better to drop a little tooltip next to the cursor that automatically disappears: more modern, and more “compatible” with mousing.

Then: Why am I allowed to start and finish an action that the machine already knows won’t go anywhere? Disable the drawing option, put a little “verboten” icon on the mouse pointer, or do something else that will prevent me from drawing a line to begin with.

But that brings us to point three, and how I would approach this as a designer. Because I would – counterintuitively – go the other way and allow the user to draw as many lines as they wanted, and just didn’t permit to commit the entire operation if there were more than four lines on the screen.

Why is that?

It’s the same principle as you see in all the social media composing fields, and in well-trained forms: do not constrain the editing process.

This field is limited to 300 characters, but it’s clever enough to only enforce its limits when you try to post. There is no downside to allowing you more room in the editing process. Maybe you write by constructing a few sentences first and only then combining them into one, maybe you want to see two riffs one below the other to choose the better one, or maybe – this is most likely – you’re not even paying attention and your motor memory is doing the editing for you, instinctively. Use any text editor for just a few months, and cut, copy, and paste, word swapping, and splitting sentences become second-nature gestures – that is, until the UI starts throwing in some arbitrary barriers.

Above in Lightroom, it might actually be easier for me to draw a fifth line and then delete a previous one, instead of doing it in the precise order Lightroom desires, or by dragging an existing line to move it instead of creating a new one.

Maybe an overarching principle would be this: If you are aiming to build something so delightfully direct manipulation as Lightroom did here, you have to fully commit to that stance, even deep in the weeds. Because every time I see a 1990s dialog appear when my fingers are flying fast, I feel like this:

And something tells me others will too.

In our Unsung yellow pages, in between people writing Chrome plugins to fix UI of other apps, and gamers creating mods to fix bugs that the developers leave behind, we need to make some room for another category of apps.

Some time ago, Daniel Kennett created a little utility called Keyhole with a singular purpose:

Have you ever been annoyed by your Mac’s media keys triggering a random video in your web browser, doing something else weird, or by them doing… nothing? Even though your music player is right there?

Me too! And so Keyhole was born.

Keyhole intercepts media transport key presses before the operating system gets a hold of them, and promises to do a better job dispatching them to the right place.

This week Kennett added another feature – the app will monitor the repeat setting that apparently occasionally gets out of whack, and fix it for the user.

We could call these kinds of apps “janitor apps.” I know of a concept called cron jobs, but I’m assuming these quiet workers do backend-y things like moving files around, cleaning up databases, pinging servers, and so on. I am less aware of work like Kennett’s that fixes stuff on the UI layer.

Is it strange that I find this kind of an app pretty… noble? Of course, Apple should fix it; perhaps Bugs Apple Loves could even introduce a serious multiplier for “a bug bothers someone so much they fix it for Apple.”

Of note in the last dialog box: “Keyhole has fixed Music’s repeat setting X times.” I think this kind of a counter is pretty brilliant.

The original 2004 Gmail iteration of the now-ubiquitous modern status bar (here presenting undo send) was internally nicknamed a butter bar because… well, just look at it:

(I believe at least Google today calls this a snackbar.)

The UI pop-up element hosting Google Talk inside Gmail – the very same thing that’s more commonly called a “toast” these days – was originally termed a mole:

The column view in NeXTSTEP was called a browser, but a few years later someone put together a different kind of a browser on that very same machine, and the original term has been sunset – after NeXTSTEP became Mac OS, the view was renamed to “column view”:

These three are off the top of my head. Please send in more!

I gasped when I first saw Lightroom do this:

I know this won’t have the same effect on you just watching. What happened was that, after I clicked on the Disable button, Lightroom moved the mouse pointer for me.

I don’t think I have ever seen anything like this, and it provoked many thoughts and emotions:

• This feels wrong. If the mouse is the extension of my fingers, and the mouse pointer the extension of the mouse, this is in effect the app grabbing my hand and moving it.
• I did not know this was even possible. I can see how moving the mouse pointer programmatically can be useful in very specific situations (like scrubbing, or accessibility), but… not like this.
• If you do something for the user, won’t that make it harder for them to remember how to do it themselves?
• I’ve seen this kind of a thing many times in my career: Someone genuinely asks “hey, if this is such a huge transgression, why wasn’t it codified somewhere in the style guide?” But to me the challenge is that it’s hard to imagine everything that needs to be preemptively captured and prohibited. I have to imagine this stuff for living, and I literally did not think anyone would just move a mouse pointer like this.

So seeing this now, yeah, I’d bundle this inside the “some interactions are 100% sacred” bucket, alongside focus never being hijacked randomly (especially in the middle of typing), avoiding scrolling anything until I specifically ask, undo and copy/​paste needing utmost protection, and a few more.

In the opposite camp, here’s a fun new project by Neal Agarwal (only worth clicking on a computer with a mouse). This is a situation where it feels perfectly fine for a cursor to be hijacked; as a matter of fact, there is something really interesting about a mouse pointer feeling less like a deity floating above it all, and more like a regular in-game actor.

This reminded me of that time, in the earlier days of Figma, when I prototyped an interaction where you could select someone else’s pointer and press Backspace to delete it:

We didn’t seriously consider it because it felt just too weird, and not that effective in solving “the other person’s cursor is distracting me” problem. But today it feels like it belongs to the same category as the two examples above.

I’ll let you decide if it’s closer to Agarwal’s delight or Lightroom’s terror.

I had some idea that many popular games have mods to tweak them – from small appearance tweaks and fan-made translations, to bigger gameplay or UI changes (and even an occasional trojan horse).

What I didn’t know was that for some games there is a whole community of modders who do one thing and one thing only: they fix bugs that the developer didn’t bother fixing.

This 1.5-hour (sic!) video by Fredrik Knudsen talks about a story of such a community for a popular game Elder Scrolls V: Skyrim:

I won’t lie: this video was a bit of a frustrating watch. The presentation is dry and takes its time. I was annoyed at Bethesda for not fixing the bugs to begin with and creating the whole mess. Also, some of the people in this story do not appear very mature, and post-Gamergate I have little patience for that kind of behaviour.

On the other hand, this covers so, so many interesting things and provoked so many thoughts:

• how hard it is to agree what a bug even is,
• how a bug fix can introduce more bugs and be an overall net negative,
• how a new distribution method for something can drastically change its nature,
• that everything, as always, boils down to communication,
• that in community- and volunteer-led projects, not spending time on governance will come back and bite you.

Not to mention these topics:

• dependencies
• change management
• centralization vs. federation
• copyright and DMCA
• version control
• volunteer burnout
• issues of trust and ego and power

If you are responsible for bug-fixing processes at a company or with a community, I am curious if you find this video valuable. I did.

The funniest moment was that drama/​debacle about a certain in-game portal was nicknamed… Gategate.

Not to mention the ending is truly poetic, and not something I expected.

I recently installed a screenshotting utility CleanShot, and I was enamored with its settings:

There’s much to like here – thoughtful grouping and layout, good explanations, more details than expected.

There are some nice interaction moments, for example the hints swapping to reflect the current status:

The fact that the tool allows you to override its single-key shortcuts, which are the hardest to change using third-party keyboard customization apps:

Or, when you want to customize the key visualization, Settings shows a nice preview:

There was even this lil molly guard:

But also just the settings themselves gave me a sort of competence contact high. A few clicks in, and I thought “oh, they do know what they’re talking about.” So many things here were for me, to solve specific problems I encountered.

It all gave me confidence this is the right tool for the job. (Also, perhaps a corollary: has there even been a bad tool with well-designed settings?)

Compare with also-new-to-me settings from Affinity, which I was much less impressed with:

It uses the troubled right-aligned style originating in iOS, the capitalization is clumsy, and the navigation muddy (it feels like in-page links on the web, which are always confusing).

Is this a fair comparison? Not at all. I don’t actually want to say that CleanShot is better and Affinity is worse. This is so very much east coast apples and west coast oranges.

I don’t even want to say settings are always worth designing well in the traditional sense; sometimes the only thing between you and 20 unnecessary options in your app is simply having no surface that could host them. A limited (but never unpleasant!) settings UI might be an intentional design decision.

But there was a nice quote in the Shadow of the Colossus book: “I often find myself exploring simply because it’s beautiful.” I too became a tourist in all of CleanShot’s settings because they were put together so well, and I was so curious what’s behind the next corner. Its creators understood that the best way to get to know what the tool is capable of is to take a stroll through the settings. I think it’s a good case study at how a proper welcome mat doesn’t always have to be a few onboarding tooltips flying spastically around the screen. Sometimes it won’t look like a welcome mat at all.

The keyboard and mouse settings in macOS are kind of boring these days…

…but somewhere deep in the underbelly of Settings lives a little nod to the original 1984 Macintosh…

…in form of the tortoise/​hare icons:

A 19-minute video from Tantacrul about a parallel universe that’s right next to ours, but most of us don’t get to think about – typography of fonts for music notation:

The video has some nice things going on besides specific details and conventions: there is a glimps of an obsolete app with a fascinatingly obtuse interface, a mention of modern standardization developments, and even a little (sad?) story of perfectionism and legacy.

I’m also kind of mesmerized by this shot of what music typesetting used to be:

There is also a short 1936 video showing more of that process. And small contribution from my end – a photo of the Keaton Music Typewriter from a museum in Catalonia:

First of all, correction for part 1 – the “focus mode” wasn’t removed. It was renamed to “quiet mode” and relocated to a different part of the UI, and I failed to spot it there. It’s still slightly perplexing, shiftily capitalized, and I doubt fully effective, but the effort is there:

I also want to warn you there will be no more positive things I say in this post.

When Cabel Sasser posted this on Bluesky in February…

…I experienced a little existential dread.

Now that I’ve experienced the dialog myself in Photoshop 2026, and a few other dialogs that have been upgraded toward what Adobe calls “modern user interface,” how did it fare?

These are 2025 windows and their 2026 equivalents:

On the surface, it feels like a lateral move. I do not personally find the new design language (Spectrum) attractive, or even particularly “modern.” The gestalt remains off and things are still generally misaligned – they’re just misaligned in net new ways.

But it was digging into the window below that showed all the problems in the still-wet foundations…

…and a lot of them have to do with focus.

1.
The first field is not focused, so you cannot start typing the number after opening this window. You need to immediately move your hand to the mouse.

2.
If you click on any field, the value is not pre-selected, so you cannot start typing a new number then.

A combination of both is rough in practice in repeated use, violating some of the basic things like this classic principle of interaction design:

Principle: Defaults within fields should be easy to “blow away”

When a user activates a field, the current entry should be auto-selected so that pressing Backspace/​Delete or starting to type will eliminate the current entry. Users can click within the field to deselect the whole, dropping the text pointer exactly where the user has clicked. The select-on-entry rule is generally followed today. (Sloppy coding, however, has resulted in the text cursor dropping at various unpredictable locations. )

3.
Clicking on parts of the input field doesn’t bring it into focus even though the hover state promises it. (Discrepancies between hover and focus handling are a horrible new thing I’m starting to see more in recent interfaces.)

4.
Simply backspacing through the field shows a crude error modal and – to add a second injury to the first injury – the dialog removes focus from the field!

5.
Tabbing now goes through “Pixels” menu on the way from Width to Height, making it harder to type width → press Tab → type height → press Enter, in a nice quick keyboard gesture.

I will recognize this is a tricky one, because it exposes a core tension with tabbing: some people use it for comprehensive keyboard access, but others want an accelerator “express train” with only relevant stops. However, macOS already has a “Keyboard navigation” setting for that – you can choose whether tabbing should go through all the controls, or only those you get to type in. Not only does Photoshop ignore that preference, but it’s inconsistent with itself – you can see that you cannot get to Anchor via tabbing anyway!

6.
Clicking on the “relative” checkbox or canvas extension color does not restore focus to last control like it used to.

7–∞.
There are tons of other transgressions. Some are downwind from focus; for example, undoing after moving a slider no longer works, because the ⌘Z keystroke is now swallowed by a UI element that doesn’t know what to do with it. Some are unrelated: Pull-downs are now of the slower kind, pressing ⌥P results in more blinking, and this tooltip below feels so cheap that I’m surprised it’s not a talking point of the current U.S. administration:

I am tired even just noticing all this. (What is that weird clump of pixels on the left of the bottom edge!? Did no one spot it before launch?)

So now what?

I generally avoid such harsh labels on this blog, but: this is awful work.

I’m angry. (Clearly.) We should all be angry in the face of stuff like this. This is how people get fed up with software – because it feels unstable and deteriorates on its own without needing to.

I know I brought up that an existing power user base can be a huge pain in the ass, and I am a decades-old Photoshop power user. But this is different than other examples where the product needs or at least wants to evolve past its core audience or toward a different market. For Photoshop here, nothing I see indicates any change in course or clientele – and yet all of these good moments in UI that used to help me out no longer exist.

Plus, all those transgressions are solved problems. Those issues are not buried in pages of heavily litigated patents, or in seven collective brains of world-class interface designers whose driveways are presently occupied by cash-filled trucks sent over by frontier companies. This isn’t some long lost art that requires archaeologists to decipher. This feels like carelessness and laziness in face of basic UI engineering; in a likely internally-motivated effort to refresh the interface, the team threw an entire nursery worth of babies with the bathwater.

It’s not just about disservice to craft. It’s not even about disrespect for change management, trivialization of institutional memory, and disinvestment in quality assurance. This isn’t only, in Tog’s words above, “sloppy coding.” This is also a failure of imagination. It’s not that hard to picture people spending 8+ hours a day going through these windows for years if not decades to come, and it’s not hard to add and multiply all of these microfrustrations into numbers that should make one pause. With these many paper cuts, you need to start thinking about establishing a blood bank. How can you expect people to use a professional tool effectively if you throw in so many roadblocks?

In an internally-motivated UI refresh like this, you not only need to meet users where they used to be, you also ideally have to give them more to cover for the pains of change. Sometimes that “more” is better storytelling – here, no one even tried to really sell me on the new interface – but ideally “more” means actual felt improvements. I’m not on the team, but it’s not that hard to imagine some of them:

• Change those annoying modals that announce typing errors into something lighter and more modern, like attached tooltips.
• Add more comprehensive equation support so e.g. I could type “660*2” like I can in increasingly more and more apps.
• Announce the invisible shortcuts that already exist, or add a few ones.
• Add a bit of memory/​stickiness to some options (like Use Legacy in the first window), so I don’t have to keep toggling them over and over again.

I started this post talking about a setting, and there is another setting in Photoshop, buried on the last page – you can turn off this “modern user interface” that feels so underbaked the moment you start actually using it. But is that a real solution to anything? Toggle it on and the existential dread comes back: Am I going to miss out on some good stuff? When is the hammer going to drop? It’s not a tax break, it’s only a tax extension.

Even this view above shows so little care, it would ordinarily deserve its own post.

(This is one of the meta posts about this very blog. If that’s not interesting to you, skip to the next one!)

Thank you for all your feedback and bug reports in response to my call two weeks ago. Since then, I:

• revamped the image and video pipelines, which should make the blog load a lot faster and CPU/GPU struggle a lot less,
• improved inline video handling on the web, and in (some) RSS readers,
• made transparent videos work in Safari, and figured out how to make even better transparent videos,
• improved Friday newsletters so they have a link to a nice web view, and GIFs hinting at video content (alas, you cannot put videos straight in email),
• and generally made the site work better on older computers and phones.

If you see anything wrong or funny as a result of these changes – or any technical problem otherwise – please let me know (contact info is always in the footer). And, in general, please continue with your thoughts and feedback about content of the stuff I post, too! I’m enjoying hearing from you.

★★★☆☆

Decades ago, I used to work for a videogame magazine, but those days are long gone, and any videogame I play is a rare and intentional event.

Shadow Of The Colossus, the 2005 title directed by Fumito Ueda, felt so important to get to know that I had to borrow a PlayStation in order to play it, instead of waiting for a conversion (which never came; the game remains a PlayStation exclusive even today).

If you are not familiar with the title, I’m going to say little – the approach taken by the game, as well – and just point you toward the trailer for its remastered edition:

Boss Fight Books has been publishing books about videogames since the early 2010s, and “Shadow of the Colossus” by Nick Suttner is a book number 10 out of 40+.

The rather small and short volume is divided into chapters talking about each level of the game, one by one. But don’t let this discourage you – after all, recaps can be a literary art form. Here, every chapter goes on a side quest to talk about a larger component of the game or its backstory.

Having said that, the writing didn’t fully connect with me. Some of the tangents do not flow well, and the author’s choice to put himself in the book yields mixed results. In good moments, it’s wonderful to see someone’s passion for the game, but at times we’re also subjected to tenuous anecdotes about, for example, author’s beard, or his walks in San Francisco.

But the game! The game is definitely worth knowing more. It’s widely considered a masterpiece, a testament to choosing only a few things and doing them exceedingly well, a celebration of minimalism and deliberation, with so much – from world design to nuances of haptics – intently focused on creating the right ambiance to tell a story.

This might be strange to say, but I have this belief the rules of world building and care about atmosphere apply even to boring enterprise apps with stock UI elements. You’re still creating a universe and its set of principles, figuring out how to walk the user through it all via certain narrative beats, and – ideally! – thinking about all the small design decisions that will contribute – ideally! – to a consistent overarching tone.

The book occasionally peeks under the curtain to reveal design choices and details that could be inspiring to more than game designers: the control scheme, the fluid camera movement, intentional repetition of themes just to have them subverted, or the fascinating concept of “futile interactivity” (giving the player control even if the outcome is predetermined). What is interesting in particular are paths not taken: the initial idea of 48 monsters pared down to 16, or the multiplayer roots abandoned to focus on a linear, single-player experience.

(In a particularly brilliant decision, the creators took some of the unfinished levels and still put them in the game… as ruins.)

Is it a perfect book? No. But I’m glad I read it, and that writing about videogames in this form still exists – for a while, this was called “new games journalism” – and one way or another, it’s good to get closer to this strange beast of an AAA game with an indie game’s soul.

4096 is a Russian UI artist (I just made up that title) who creates interesting audio-visual mashups. Here are some of the best ones:

Interfaces of rhythm games (like Guitar Hero):

Windows startup sounds, incl. fun hi-def reimagining of their splash screens:

Windows error messages:

If this looks like fun, check out the rest of their work, including Windows 95 mobile and the art of blank VHS tape boxes.

Before dark mode became mainstream in the late 2010s, there were two main customers of dark UI themes: programming and photo/​video production. But, to the best of my knowledge, they arrived at that preference from two very different angles.

Programmers’ fondness for dark mode was a result of decades of bad display technologies. The early CRTs were so awful, the burn-in risks so real, and the pixels so fuzzy and headache-inducing, that you wanted to see as little screen light up as possible – hence, defaulting to black background for everything computers did.

These challenges were there all the way through the 1980s, really, teaching generations of coders that computers meant light letters on dark backgrounds. Games moved away from being “in space” or “at night” as quickly as they could, text editing and spreadsheets went for paper-like livery soon after that, but programming never meaningfully existed on paper, and so the skeuomorphic pull wasn’t really there.

(Have you ever heard of a term “reverse video”? What’s kind of confusing about it is that its meaning was reversed around that time.)

AV professionals took a different route. They already had CRT calibration, gray walls, and monitor hoods so that light from outside wouldn’t contaminate content colors – and when computer UI started appearing on those CRTs, it was likewise best to keep it as dark and as neutral as possible.

Below are pictures of Avid Composer in 1990, Pixar’s Marionette/​RenderMan in 1995, and the first versions of Lightroom in 2006 where you can see the interface trying to at least gesture toward a dark theme:

Today, things are more flexible. Many people prefer one theme over the other for any of many legitimate reasons, most leave dark theming synced to daylight, and display technology can handle all themes so well that it jumped ahead of our brains, which still have some interesting asymmetries in processing light shapes next to dark ones.

As users celebrated dark mode appearing in popular apps and services in the 2010s, some had to catch up the other way: Apple TV added light mode (for some reason) in 2017, and Affinity apps celebrated new light UI option just earlier this year.

Most programming text editors still default to dark, but allow you to switch; as a software category they were probably the first to fully embrace color theming.

But what led me to writing this post was a delightful discovery today of this setting:

Why, of all apps, would iOS Photos allow you to switch to dark mode, and only while editing to boot?

I think this might be because of the above tradition of pro AV apps, where we learned it’s good for visuals to be surrounded by black; a little nod to its earlier professional roots – similar, perhaps, to the story of the Clear button in calculators.

But I had two more thoughts. First, for all the reasons above, to me at least dark mode still has connotations of “professionalism” and toggling the option makes me feel I’m a bad-ass pro whenever I’m editing a photo. I wonder if others also feel that way, too.

Second, dark mode looks different. Dark UI only when editing means it’s easier to spot whether I’m editing or just browsing, and be ever so slightly better oriented.

(In general, apps today are much more similar-looking, and I’m surprised neither iOS nor Android doesn’t allow you to switch the theme per app, just so it’s easier to know where you are as you move around quickly.)

To follow up from yesterday’s post, in Figma, object selection actually goes onto the undo stack. This is because in a professional tool with objects in multiple levels of hierarchy, it might take a while to construct a selection to work on – and since selection is always just one accidental click away from being completely cleared, undoable selection is extra protection.

However, at the same time renaming a file – or changing settings like file access – is not undoable. This is in part because we didn’t feel people would understand they could cancel out their rename this way (Safari too used to have “reopen last tab” under ⌘Z, until it reverted to Chrome’s ⌘⇧T), but mostly because you could accidentally undo through a file rename during regular work if you were not careful, without noticing, and that felt like it’d have more profound consequences.

In some ways, it helped me to think of these not as “ineligible for undo” but rather “living outside of time.” The moment a file is renamed, it will always have been named that way. (For the purposes of undo, at least. You can acknowledge anything you want on the version history screen.)

I’m not saying these are universally correct choices – as a matter of fact, some users find undoable selection (at least initially) pretty confusing! – but mostly sharing these as examples of intentional thinking about what deserves undo, and what should be exempt from it and taken care of elsewhere.

A fun bit of storytelling on the website for a git client Retcon:

I don’t have personal experience with Retcon. I definitely struggled a lot with git’s syntax over the years, and have my own cheatsheet that looks similar to this.

But what I really liked from this page was the elevation of undo to be the North Star. I think it’s very, very well deserved.

To the best of my knowledge, undo in its modern form arrived in 1983 with Apple Lisa – Byte magazine called it a “tremendous security blanket” – and then over the next decade or so blossomed into its current state: an infinite, multi-level, lightning-fast safety hatch that works pretty much everywhere, always there in the bottom-left corner of your keyboard, so second-nature you might not even realize you’re invoking it.

In early apps, before undo arrived, you had to be very careful about what you did and when you saved your work. Later on, undo worked on just one level, so you had to think a lot about how to spend it before things became irreversible.

Today, undo just works. It truly became Back Space: The Next Generation.

But any user-facing “just works” hand wave means a lot of people’s hard and invisible work behind the scenes. So if you’re reading this, and at some point in your career you worked on making undo better, my tip of the hat to you (and send me a message!).

Minecraft is so complex that it’s sometimes hard to know what is a bug and what is not.

Here’s the logic of the game:

• If you fall from height, you receive fall damage.
• If you fall from height but you’re in a boat, there’s no fall damage.
• If you fall from height and you’re in a boat, but you fall from a distance of 12, 13, 49, 51, 111, 114, 198, 202, 310 or 315 blocks, there is fall damage and you die.

The first is common in games.

The second is – I believe! – a former bug that was grandfathered in as a design decision: people got used to it, started relying on it, and it became “too big to fix.” The retroactive explanation became that the boat is your shield and takes all the fall damage, which is a very Hollywood action movie way of looking at the world.

So, only the third one is a bug… obviously.

But why those specific numbers? Here’s a 16-minute video by Matt Parker at Stand-up Maths that tries to answer it:

It’s an interesting video because it’s lighter on bug causes discussion, but heavier on math – and the moment you realize those numbers above are not random at all and coalesce into a nice formula, is genuinely a pretty fun moment.

I thought this was interesting, and a little contribution to a larger debate about how hard it is to even agree what a bug really is (which I previously briefly talked about).

There’s a category of “plain text” or “ASCII” diagramming and UI design tools:

• Mockdown – works immediately on the web, even on mobile
• Wiretext – works on the web, but desktop only
• Monodraw – a Mac app

I believe these are used by people who prefer intentionally limited visual choices, for low-key diagramming to put in source code, and – increasingly – as an entry point to gen AI.

They’re so interesting from the standpoint of this blog:

• Fun to see a contemporary take on something that peaked between 1970s–1980s – you can look up TUIs and Turbo Vision if you want – but (just like Mario the other day) now with modern sensibilities, performance, web access, mouse and trackpad affordances, and so on.
• It’s interesting simply as an exercise in constraint. I believe constraint practice will become more and more important as computers become more and more capable. It’s already useful to constrain yourself in order to make things easier for you. With the rise of AI, self-constraint will become important to make things harder, as well.
• There is a certain power and longevity of monospace plain text that’s worth celebrating – not just because the file format is portable, but because text editing as interface is so well-known and potent.

Also, ASCII spray in Mockdown is just really fun:

(Caveat: These tools are “ASCII” in a colloquial sense, the same way people use “GIF” to refer to a certain category of looping animations.)

If there was one go-to example of an impenetrable error message in the 1980s, it must have been this – popping up, for example, if your disk drive was dirty:

On some technical level, the options made sense: “Abort” would stop whatever you were doing, “Retry” would try to repeat the action, and “Ignore” would proceed as if there was no error. But in the heat of a moment, or seeing it for the first time, this was a puzzling choice to be asked to make. Not only were the words weighted improperly (the seemingly most innocuous action here, “Ignore,” was actually the only one that could do actual lasting damage), but it also wasn’t entirely clear what’s the safe thing to do to get out of the situation.

(The redesign of “Abort, Retry, Ignore” was “Abort, Retry, Fail,” and it wasn’t really a huge improvement.)

Last night, I installed Google Photos on my iPhone, and the first message that greeted me was this:

This is really a matryoshka doll of bad dialog presentation.

First: any buttons in a dialog should be labeled with enough information to keep me going. Here, both have generic labels, so now I need to pay attention.

Second: Even after reading, I have no idea what is the choice I’m making. I see the pathway marked “yes, keep it the way I had it” and, sure – this would be generally what I want from any given computer on any given Sunday. But what’s the actual alternative?

But the third, and most important one, is this: this dialog has no safe escape hatch. By now, in UX design, we established quite a few canonical escape hatches:

• a Cancel button,
• a × close box,
• a “No, thanks” link,
• a press of an Escape key.

But you can’t × this dialog out. The main button seems positive, but it also feels like I’m taking an action with consequences, and I don’t want to deal with that. There is a “No, thanks,” but it doesn’t feel like the other “No, thankses” I have seen – it’s juxtaposed with copy that makes it seem… a dangerous thing to choose.

And this last bit makes it a pretty serious design offense, because you are now messing with foundational stuff. You need to protect those escape hatches for the future; the moment you introduce hesitation into the mix and taint “No, thanks” as a concept, really bad things will start happening all across your product.

In real life, fire doors have to open outwards when pushed with body weight, aircraft stick shakers are impossible to ignore, and anti-lock braking systems do smart things even after your brain turns off its smart parts.

I know seeing a dialog like this would never happen in a moment of true panic, but sometimes I think of the user in their most absent-minded moment: trying to get their kids to hurry up for school, on hold with an annoying cable provider, with a cat looking like it’s about to jump up directly into a running toaster. A dialog on their phone pops up. If that dialog absolutely has to happen, what is the escape hatch it can offer so they can dismiss it safely if they cannot think about it at all?

This Google Photos screen needs a lot more rethinking and rewriting, but in its current incarnation, it desperately needs a clear and trustworthy escape hatch I can tap absentmindedly, just so I can get to my photos.

An interesting 10-minute video from gruz about Super Mario Bros. Remastered, a modern Super Mario fan remake with surprising depth that puts Nintendo’s own efforts to shame:

What I liked about it is that it’s wrestling with the idea “How do you improve on something considered perfect?” and touches upon the important area we cover occasionally here on this blog: when is software finished?

There is also another interesting angle. Even though the game requires original game ROMs to work, it’s still in a very, very gray area:

[…] Once you strip it down, this thing is built around Nintendo’s world: the Super Mario Bros. name, the characters, the visual identity, the level concepts, the branding, the whole presentation. And the more ambitious it gets, the riskier it feels. Once a fan project starts offering not just a remake, but extra modes, editor tools, custom-level browsing, ratings, and a growing user-generated content scene, it stops looking like a small tribute and starts looking like something operating in Nintendo’s lane.

(I didn’t expect to see the original Super Mario game to come up so often on this blog – I just added a tag for it – especially since I don’t have any personal reverence for it. But it seems it’s Super Mario and Doom specifically that became timeless pieces of software that keep being resurrected, revisited, and remixed, over and over again.)

An interesting flavour of a molly guard that can only happen in onscreen interfaces is “occasionally moving things out of the way to mess with the user.”

The messing-with-the-user part is, ostensibly, for their benefit. Making something not appear in the usual position, or not behave the usual way, becomes a speed bump, cancels out motor memory, and forces a conscious reaction rather than flying through the interface on autopilot.

The simplest example is dialogs that ask about dangerous actions suspending the “default action happens when you press Enter” behaviour:

(There is a way to continue the dialog on the right using the keyboard alone – but it’s only via ⌘R and not the default, breezy Enter.)

Another version is swapping buttons or showing them in an otherwise unusual order:

But remember when I said “can only happen in onscreen interfaces?” Well. The apotheosis of this very idea, spotted in a New York alley, proves otherwise:

It’s a Hirsch ScramblePad, inconsistent very much by design, a login mechanism where every time the digits get put in a different place.

The idea is meant to help with two problems:

• It makes it harder for someone standing behind to learn your code from just watching your movements, as it abstracts the movements to be one step away. (The strange visual filter is meant to make the viewing angle as narrow as possible, too.)
• It prevents uneven wear and tear of the buttons, which people could use to guess your code:

I understand “ScramblePad” was the original product (here’s the patent with some nice illustrations), and the name got genericized since. Here’s competition, MIWA Random Tenkey – once probably so much more futuristic, today equally quaint:

One can occasionally see more modern versions today:

But back to our beloved screens, where some banking web apps copied the idea:

And even recently, Motorola touted it as a feature on their phones:

I’m not a security expert, so I won’t try to opine how effective those things are. I tried to research whether forcing a password out of motor memory – which these will accomplish – is ultimately better or worse, but a lot of the papers I found were inconclusive. (As always, some of the theoretically good ideas for security bounce off of human limitations and convenience: Forcing someone to remember a password might mean they will write it down somewhere, effectively making things worse.)

I am a huge fan of all sorts of “recent” features in software; I think they’re extremely helpful in removing tedium, and thoroughly undervalued. A lot of our work is repetitive, even if it’s sad to admit.

I shared one example previously, and here’s five more.

1.
My bank’s website not only shows me the last payment I made, but also allows me to click to use the same number again:

2.
The app Transit has a nice list of recent destinations just below the main options:

3.
Google Maps promotes recently tapped-on items to be more visible than they would normally be:

4.
CleanShot X offers something I have always wanted from built-in macOS screenshotting – being able to capture with one keystroke the same area as I delineated last time:

5.
Google Pixel allows you to swap the current wallpaper and three previously chosen wallpapers easily:

What unifies all of these is that “recent” doesn’t live in a submenu somewhere, treated as a second-tier pathway. No, in all of these “recent” is embedded in the fabric of normal interactions, side by side with forward-facing options. I believe this is necessary for any sort of feature like this to be truly successful.

That last Google Pixel example also shows that “recent” isn’t only for repeating something faster – here, it becomes more of a “soft setting,” without introducing a lot more complex UI and interactions that a “real” setting might require.

I can finally update my ancient WarGames reference – turns out the computers on the TV show The Pitt are also preprogrammed to show the right things on the screen regardless of what the actors are actually typing.

But you still need to flail your fingers in vaguely realistic ways, so the actors in this (spoiler-free) TikTok share their strategies:

I want to tell you about something that might seem oddly specific and perhaps too technical, but a) at the end of it you will have a useful phrase somewhere in your brain that will pay off one day, and b) I swear I will make it worth your while.

Have you ever seen this problem?

The screenshot on the left is fine. But there is something wrong with the one on the right. In light mode, the shadow is wispy and weird. In dark mode, things are even stranger, and the shadow is almost… a glow?

I stumbled upon this problem occasionally for years now – there are a few screenshots on the blog with this weird problem, even – but it was never feeling like a deal breaker. However, I finally sat down to figure it out today.

Turns out, there are two kinds of approaches to alpha channel/​transparency. The normal one we all know well is called “straight alpha.” But on the right, we were looking at “premultiplied alpha” – something entirely more complicated, where the background is baked into transparency for… reasons. Premultiplied alpha is conceptually – and often literally – dirtier, but it also has benefits: more flexibility, better filtering, sometimes better performance. As far as I understand, premultiplied alpha exists primarily in the world of video and vfx, but occasionally it rears its unconventionally attractive head in our boring static 2D world of screenshots, too.

In my case, I finally figured out this was happening whenever I’ve pasted the screenshot from the clipboard to Photoshop instead of Preview – for some reason, a screenshot then got an alpha channel premultiplied against white background. But I wouldn’t be surprised if it happens to some of you under other conditions, too.

So, “premultiplied alpha.” That’s the useful phrase. What was the other thing?

This is an absolutely hilarious 7-minute video by Captain Disillusion that talks about various challenges with the alpha channel:

Captain Disillusion (or, Alan Melikdjanian) is one of my favourite YouTube educators. His work is mostly debunking fake videos – his most well-known one is about the Cricet bracelet, although my personal fav is one about laminar flow – and they’re just constantly interesting and hilarious at the same time.

Disillusion also occasionally does a more straightforward “let’s talk about some technical aspects of video production” episode which he bundles under a “CD/” umbrella. Here’s a handy list of all of them:

• Intro to the whole series
• Aspect ratio
• Frame rate
• Resolution
• Interlacing (and addendum)
• Color
• Alpha channel
• Shutter speed
• Blur

I am sharing this list because you should watch them all. Most are <10minutes, they are consistently entertaining, and even though none of them are about UX design, there is enough overlap between the two universes that you will come out of it all a lot smarter.

Pragmatically, in my case, I searched for [premultiplied alpha] + [Photoshop] and quickly learned of a new-to-me menu option: Layer > Matting > Remove White Matte. It turns premultiplied alpha back to straight alpha, and fixes the screenshot.

Non-pragmatically? If you want to really understand premultiplied alpha, the last thing I can do is suggest another great internet educator, Bartosz Ciechanowski, who has a more comprehensive interactive web explainer. There will be math. There will also be sliders. You decide.

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.