I know I’m usually driving the Finder pretty hard, but I think that’s a necessity, given its position as the center of macOS for power users, and its situation where it feels like Apple pretty much gave up on it.

But I also want to show things that Finder does well, and this might be something no one does nearly as thoughtfully: text truncation.

This is what happens when you have a filename that’s too long:

This is really nicely done, for many reasons that work in lockstep:

• Finder cleverly elides text from the middle, knowing that both the ending of the last words (or digits!) of the file name, and its extension are important.
• Finder shows the full name in a tooltip. I’m surprised how many tools forget to do that, offering no easy explanation for the missing letters. Here are some examples from Notion and Bear, neither of which offers help on hover:

• Finder position the tooltip exactly atop the existing text. I think this is really clever: it avoids overlapping other useful information, and makes it faster to reorient yourself. Compare with, for example, AirTable:

• Lastly, Finder only shows the tooltip when it’s needed. This is something where so many places lose their way. For example, here’s Paper and Google Drive, throwing up a tooltip indiscriminately, even if it has absolutely nothing to add to the conversation:

Why does this last thing matter? Because unnecessary tooltips are distracting, cover information, and also – maybe most importantly – turn the interface into a minefield where no safe places remain to just mindlessly rest your cursor without worry.

This last thing is very fuzzy, but so important. You know how unpleasant a lot of articles are on the web these days, solely because you’re always on the edge about what’s going to happen while you read? Am I going to be moved up and down? When and where is the ad going to appear? When will I encounter a new subscription pop-up, and what will be the weird way to close it this time around?

I know you don’t literally tense your muscles while reading those, but I feel like in some sense, in the back of your head, there is always this unpleasant worry that you’re dealing with an unstable interface.

This is not a strong, but I feel a similar way about spurious tooltips; they make interfaces feel less stable. You rest your cursor, something jumps up at you, you get distracted and move your cursor instinctively to avoid it, and with any luck, you trigger yet another tooltip, and so on.

I will write more about this in the future. If you asked my former coworkers, I bet a significant portion would say “this guy gets angry at tooltips, like, all the time.” I promise I will get angry at tooltips more here. But today? Today, kudos to the Finder. It shows us that if you care, you can make this small moment feel really great and thoughtful – knowing that small moments multiplied in the thousands are no longer small.

For a while, the digital artist James Dalzell Hodge kept a video diary of various design decisions while making his next game. This 13-minute video is interesting because it harks back to my mention of diegetic interfaces just a few days ago:

It’s a nice quick dive into the subject – a rare coverage of what “diegetic” means outside of the realm of movies.

I like these videos because Hodge focuses on details and shows working through things, including approaches rejected along the way. Inside, there are even occasional peeks at interfaces from Unreal Engine tools and Blender, not to mention examples from other games.

I keep thinking about MacCharlie, this strange product from 1985 that turned the original Macintosh into a dual-purpose machine that could also run software by its chief competitor, early PCs:

I’m fascinated by it because it almost feels like cargo culting: “hey, PCs are big and ugly, so if we make a Mac big and ugly, it must turn into a PC.”

Of course, there was more method to this madness, and two alien cocoons wrapped around the Mac and its keyboard actually have the correct technology, but still – what an absolutely soul-sucking experience: an ugly on/off switch, ugly disk drives, ugly, slightly misaligned elements, ugly, ill-fitting, slightly off-color plastics, even ugly colors for key legends.

(Okay, I liked one thing – the embossed Dayna logo matching the Apple’s.)

This was not a novel idea. Those kinds of matryoshkas happened to computers before, and are still happening to computers today:

There even exists a concept of a “naked robotic core” – devices designed specifically to welcome more infrastructure around them. Here’s an example from the professional cine camera world…

…but your smartphone with MagSafe is gesturing toward this idea, too.

This is not limited to hardware, and it is in software where things get really interesting to me. Here’s a thing I saw the other day when installing some keyboard modification software:

The top is the native macOS interface. The bottom, including those arrow tendrils, comes from the interested app, trying to walk me through the process using some overlaid coach marks.

Or, this is something I saw on my Windows laptop. Putting aside none of this was what I gave consent for – again, top is native, bottom comes from McAfee:

Those adornments, whether “white hat” (like the keyboard tool), or “gray hat” (like the McAfee), all feel equally desperate and hopeful.

Desperate, because if this is the best idea, there are no good ideas. You can almost feel developers gritting their teeth, saying “I can’t believe we have to do this.”

Hopeful, because – well, you’re skating where you hope the puck will remain. At least the hardware, once mounted, cannot morph into something else. But the software appendage you create doesn’t really know how the host organism will evolve. Even a singular word change in the original UI can throw everything out of balance. This is no software proprioception where you control both sides of the equation and can re-synch them when either needs to evolve.

Okay, I imagine if you think ahead enough, and have an appropriately vivid imagination, and a robust QA process set up so you can react immediately when the host changes its UI from under you, you might get something passable.

But I think it will be hard. Sure, McAfee’s pop-up didn’t even try so its approximation of the “Enable extension” button is basically laughable – but CustomShortcuts did, and even then, the rounded corners and the shadows don’t quite match.

I think this is the foundational disadvantage of this kind of an approach. I imagine there are much worse and more nefarious “black hat” examples than the McAfee callout I showed above, but even without that, shoddy facsimiles of things are all around us – fake text messages from fake support centers, fake smartphone pop-ups telling you to update your OS – and we learn not to trust them. And this kind of UI inevitably starts as a shoddy facsimile. You can pull it, with effort, to be something better, but it will never forget its roots.

Here’s another “white hat” example:

This is from Raindrop. Again, you can sense some pretty understandable desperation as presumably iOS doesn’t allow you to add the highlighting and annotating commands to its top toolbar – hence additional, bottom toolbar.

I consider Raindrop a generally well-made app, but you can immediately feel a certain maccharlieness of it all here – what was mismatched plastics in the 1985 is mismatched liquid glass effects in 2026.

And, on top of all that, once in a while, disaster strikes:

When taking screenshots, macOS at some point followed iOS and introduced a “floating thumbnail,” which serves as a proxy of the screenshot you just took – you can drag it somewhere, open it to annotate, etc.

The thumbnail is a nice gesture. The problem is that I rarely do the things it enables, so the thumbnail is now an extra thing to deal with and dismiss. And you have to dismiss it, because inexplicably on macOS the floating thumbnail is diegetic, meaning it itself can be screenshotted. And this happens, routinely, if you do a few screenshots quickly in a row – the screenshotting tool literally ruining your screenshots. “You had one job,” &c.

(“Diegetic” is perhaps my favourite pretentious word. It generally stands for “in-universe.” If characters in a movie are listening to the song, that song is diegetic. If the song is just for the viewer as part of the soundtrack, that song is non-diegetic.)

You can turn off the thumbnail, but then outside of the sound – which is unreliable for other reasons – there is nothing else to tell you the screenshot was taken. And I think it’s good to have some sort of a confirmation, especially since the screenshot shortcuts are so harrowing.

Now, on Windows, when you press the equivalent (Windows key + PrtSc key), this happens:

I think this is better. It’s elegant, unmistakably recognizable as a screenshot, gone immediately, and a cute skeuomorphic nod towards old cameras.

In response to my recent interactive essay about interactions, Waider on Mastodon posted a great crystallization of a common problem:

There is nothing quite so frustrating as a persistent user interface papercut. You know it’s there, but you keep running into it because the moment you start thinking about what you’re doing instead of how you’re doing it, that knowledge slides away until BAM you run into it again.

I think this is really nicely put and highlights about why it’s very important to care about this kind of stuff.

If you forgo a standard interaction out of carelessness, a bug, bad systems thinking, or for other reasons, you’re not just making your users frustrated by something not working. You’re also at risk of making them frustrated at themselves, assuming they can change what their fingers do easily, not fully knowing that a) this is motor memory, not just regular conscious actions (and any memory is hard to “update” intentionally), and b) motor memory is separated from regular, declarative memory, and not possible to reason with using the same techniques.

(As an example, it’s very hard when keyboard shortcuts or mouse gestures disagree between apps, because while you consciously might know which app you’re in, that’s not necessarily true of your fingers.)

Waider continues with an example:

The canonical example of this, for me, is Microsoft apps on macOS: even now, decades after Microsoft started producing macOS versions of their apps, they insist on largely disregarding the native UI idioms in favour of their own. Current pet hate is that if I’m commenting on a document, the Ctrl-A/Ctrl-E actions do not work, and boy howdy do I use those constantly.

My recent example is that even though I wrote about Safari overriding the natural “scroll to top/bottom” tap gesture on their tabs – so I am aware of it in my declarative memory, I know Safari designers messed it up, and I know exactly what to do and not do – my fingers still occasionally tap to scroll in Safari anyway.

From Brad Woods, a messy (in a good way) and copiously illustrated/​animated exploration of “juice,” or:

Our wet little term for constant and bountiful user feedback. A juicy game element will bounce and wiggle and squirt and make a little noise when you touch it. A juicy game feels alive and responds to everything you do - tons of cascading action and response for minimal user input. It makes the player feel powerful and in control of the world, and it coaches them through the rules of the game by constantly letting them know on a per-interaction basis how they are doing.”

It’s mostly, but not exclusively videogame related, but it has some obvious tentacles reaching into the consumer and even professional UX world – at this point in Unsung’s history you all probably know I see these worlds as overlapping, hence linking to a lot of videogame interaction stuff.

Won’t be a surprise that I particularly liked the “level of juice” slider:

The whole page is messy, but that’s actually kind of great. It generously links to other things, too. I don’t agree with all the examples, but I the entire effort feels like it came from a person, and I really treasure that.

I also thought this notion was very clever:

There is a trend to juice rare events in non-game software. For example, an explosion of confetti to celebrate completing onboarding or a funny animated 404 page. Game developers do the opposite. They focus on the mundane, routine tasks. Because these are the foundation the rest of the software sits on.

(Brad Woods’s “Digital Garden” is generally worth checking out as a whole.)

Here’s a big interactive essay I just finished.

The theme: What does it take to build interfaces that truly allow for fast operation – and why that matters.

If you like the interactive details posts here on Unsung, the essay is kind of a concentrated dose of all that. You can technically read it on the phone, but it’s so much better on a computer (or a big tablet). It has ~40 interactive playgrounds, and sounds, and a glossary, and all sorts of fun stuff I’m doing for the first time.

I wanted to share some things I learned over the years, and nod toward mostly anonymous creators of UX inventions I’ve long admired. I also thought it could be interesting to make interfaces appear as machinery – you’ll see what I mean.

Let me know if I succeeded!

You might have seen Bret Victor’s 55-minute Inventing On Principle talk soon after he gave it in 2012. If not, you should check it out. If you did, you should check it out again and see how it makes you feel today:

It is about interactions but in the service of something grander, which (if I’m doing my job well) you might recognize as Unsung’s core theme.

Victor – a designer, researcher, and computing historian – gave a few other talks in the few years since, and I thought a little guide might be helpful:

• Media For Thinking The Unthinkable (40 mins) is the continuation, with slightly more academic examples.
• Drawing Dynamic Visualizations (35 mins) is specifically about information visualization, chiefly a demo of the “Illustrator, but programmatic” tool showed briefly in the above talk. There’s also a bit more theory.
• Similarly, Stop Drawing Dead Fish (53 mins) is a demonstration of a different programmatic tool to make animations.
• The Humane Representation of Thought (56 mins) presents more theoretical underpinnings to the Inventing On Principle talk.
• The Future of Programming (32 mins) is a – mostly static/​traditional – history lesson about what programming could be.

There are some wonderful repeating themes in there:

• We can do and expect better from computing and interactions.
• You have to know your history to march confidently toward the future.
• Ideas need an environment that nurtures them.
• Playful environments leads to more discoveries.
• Feedback doesn’t just have to happen. It has to happen immediately and comprehensively.
• There are no left-brained and right-brained people, but our brains have two different modalities: language (algebra) vs. spatial (geometry).
• A big emphasis on two-handed operation (kind of like Fontificator just yesterday).

I love this blend of theory and practice, inspiration and pragmatism, high- and low-level. The tools look surprisingly professional for research projects, but underlying their microinteractions is a deep philosophical stance. It all reminds me a bit of Jef Raskin and Doug Engelbart.

Victor’s last talk of this era is Seeing Spaces (15 mins) from 2015, serving as a sort of introduction of him moving toward computing in physical spaces. As far as I understand, Victor has been spending time on Dynamicland since, which is definitely more physical computing, but also a lot more academic and scrappy, and as such out of range for this blog.

(His website is worth checking out, especially if you’re not in the mood for talks and would like to get to know his work in a different way.)

In game development, there is this strange effect known as “tunneling.” It happens when you do collision detection. Imagine a simple situation where every time you move a cube, you also test whether it touches the wall – and if it does, you make it bounce off of it.

This works great, but if you move and detect the collision less frequently, something weird can happen:

Here, the movement was so coarse that there was no point at which the cube touched the wall, so the collision wasn’t detected, and the cube passed cleanly through… as if it made a tunnel.

(You can play with this simulator yourself, by the way.)

The easy answer seems to be “well, run the collision detection more often then,” but… how often? And what if the entire game engine runs off of computer’s frame rate, which you are not in control of it at all? All in all, it’s not a trivial challenge, although various techniques exist to remedy it.

We talked before about another challenge with frame rate dependence. They’re not limited to games; for interfaces that are based on physics, they will rear their ugly head, too. But tunnelling happens in simpler UI situations as well. Here’s an example from Photoshop – I’m holding a button and if I drag slowly, each item will be toggled. But when I start moving fast…

Fortunately, the remedy here is much easier than in the complex world of videogame physics: just remember the last one touched, and toggle everything in between that and the current one.

On the tldraw blog, Steve Ruiz covers a slightly more complicated scenario where you do have to do some physics: an eraser in a drawing tool.

Pointer input isn’t continuous. The browser reports the pointer’s position as a series of discrete samples, and when you move fast, those samples can land far apart. Flick your wrist and two consecutive pointer events might be a hundred pixels from each other, with three small shapes sitting untouched in the gap between them.

A naive eraser asks “what’s under the pointer right now?” on every pointer event. At slow speeds that works fine. At high speeds it tunnels straight through anything that happens to fall between two samples, which is exactly when people use the eraser most aggressively: big, fast, careless swipes to clear a region.

Here’s Ruiz’s example of the eraser in FigJam, with heavy tunneling:

And here’s one in his drawing tool:

You can click through to learn more and see the algorithms, but either way it’s worth remembering: if it applies to your interactions, think about the “flyover states” and make sure to make things deterministic, regardless of whether the mouse is a tortoise, or a hare.

And, I liked Ruiz’s sentiment at the end:

[…] The decision to test segments instead of points is the difference between an eraser you can trust at speed and one that mysteriously leaves survivors behind. Users will never notice it working, and that’s the point.

A nice little old-school moment from Flickr: When you accidentally type the name of the new photo album in the search field instead of the “new album name” field, Flickr just passes on that value to save you from having to retype it:

(I bet you witness a version of this all the time when dealing with “I forgot my password” flows which should pass on your login from one field to another, but they don’t.)

I’m not saying this dialog is beyond reproach; one way to reduce this problem would be to make those two treatments different enough visually to reduce the chance of confusion. But it doesn’t matter, because the truth is that often there is no dividing line between the problems and the symptoms, and both overlap to a scary degree.

As a designer, I think it’s sometimes good to simply face this truth: no matter what I do, the user might type something into a wrong field. Anything I can do to help then?

Two nice follow-ups to topics we covered before.

In February, Nobert Heger did some analysis of precisely which pixels in Tahoe are intercepted by mouse when trying to resize a window. In April, Steve Ruiz, author of tldraw, did this more extensively for all the drawing apps like Canva, Figma, Illustrator, and so on:

When a user has one or more shapes selected, we display an interactive overlay that allows the user to transform their selection: a drag inside the box will translate the selection; a drag on the edges will resize along that axis; a drag from the corner will resize along both axes; and a drag from further out on the corners will rotate the selection.

Like many features in tldraw, my design here was meant to follow the conventions of design tools. This meant a broad survey of other applications, both new and old, reconciling differences between them, and picking a design that I felt best served the user while remaining conventional.

Remember the “if you put the Apple icon in reverse” joke from January? Last month, Jim Nielsen on his blog pulled on that thread and showed a few more examples:

Some 3rd-party apps continue to fight a good fight, even as Apple’s definition of what an icon should be — or what’s even possible — shrinks all around them.

One finding from this blog post for me was that things changed. In Big Sur, the squircle form factor was encouraged, but not enforced. Well, it is enforced now, when even shapes very similar to the squircle are now inside “the gray box of hell”:

These gray boxes are not some pedestal for icons. They’re the actual icons.

Anyway, I always appreciate efforts of people methodically documenting things so we can all learn and notice patterns and/or continue the work from the best possible starting point.

Ever since I wrote a post about the molly guard, I have been on the lookout for those, and I think I collected enough to do a little follow-up.

First, some classic industrial molly guards from a museum in Germany:

This IBM electronic typewriter had a gorgeous perspex molly guard around the power button:

Other machines opted for “softer” quasi molly guards that still aimed to prevent you from pressing a button or switch by accident, but without having to get something out of the way first:

Even softer? This below is not a traditional molly guard, but the placement of “I’m writing to the SD card” red light was not accidental. Ejecting the card while the camera is writing to it might cause some damage, so the light was positioned right next to the card door and the card itself, making you more likely to spot it and wait:

This one is even more clever. You know how some old floppy drives have a handle that lowers the reading/​writing head so that the diskette can be used? That same handle also prevented you from pulling the disk once the head was lowered. It felt so natural, you might not have even realized it’s a molly guard doing its job:

On the other side, these following guards are more of a “you really shouldn’t do this” variety – much closer to a disabled state in graphical user interfaces:

Let’s jump into software.

This is a nice situational molly guard in Finder when you press ⌘O and have a lot of files selected:

iPhone’s “slide to unlock” no longer graces the home screen, with one exception – stopping the alarm:

There’s something about this treatment that doesn’t sit well with me. I’m not sure what it is: The text not feeling centered? The control being circular? The icon on the slider making it seem like it’s a stop button you can press?

Speaking of stuff I don’t love, you might recognize this molly guard from Chrome:

This one never felt pleasant to me. You might say “isn’t the point of the molly guard that it doesn’t feel pleasant”? But I think one needs to separate the intent and the mechanics. I don’t mind the intent here, but the styling is ugly, the message kind of confusing – you don’t really have to hold ⌘Q, just press it again – and you also don’t get any feedback during holding.

Contrast with this extremely skeuomorphic CD burning molly guard in early iTunes, suggested by one of the readers:

And lastly, something I didn’t expect to ever see. Per this issue (page 14) of an alumni magazine of University of Illinois, here’s the actual Molly with her father:

Interactive explainers are one of my favourite things about the web: people passionate about things introduce them to others, for free, with care, and often using some interesting interactive or educational approaches in the process.

I picked a few I particularly liked for this post. These aren’t just explaining things useful to know as a designer, but also themselves contain inspiring/​unique interactive moments worth knowing about:

1.
Curves and Surfaces, Bartosz Ciechanowski

• Every example has draggable points, but it also pops up an undo button once you start messing around, so you can feel safe experimenting:

• Specific ideas and definitions are color coded between text and the interactive pieces:

• For complex three-dimensional shapes, you can simply rotate them around to orient yourself better:

• I liked this trick of claiming something is impossible, but leaving a door open to try it anyway – I bet it will get some people more engaged, in the “but I’m sure I can lick my elbow” sense:

2.
ASCII Characters Are Not Pixels, Alex Harri

• I think the traditional “drag a divider to swap between two representations” interaction is actually kind of bad, but this essay subverts it by allowing you to toggle between representation A, representation B, or both side by side:

• A button to copy code to clipboard is always appreciated:

• I don’t know, I liked these minimalistic sliders:

3.
Tab Roving, Niklas Gadermann

• It’s hard to know what to do with complex interactivity, for example a specific sequence of keystrokes… let alone the fact that mobile phones don’t have easily accessible arrow or Tab keys. Here, a brilliant solution: not just on-screen soft keys, but also automatic playback!

Also, kudos to all three creators for their explainers working equally well on phones as they do on desktop computers.

Do you know those “Are you still here” screens? In some cases – like banking – they are ostensibly there to improve security. In public transit ticket or similar machines, on the other hand, they exist just so the machine can easily reset itself ahead of a future customer.

Resetting to default state happens on your phone, too. I’ve been thinking about it this past week and found a few examples.

The Google Search app comes back how you left it, except if you abandon it for longer than 45 minutes. If that‘s the case, it returns to a pristine, deterministic homepage. (You can always come back to the previous session, though.)

When you pause a podcast or music, at least in my setup, it will be on the home screen for 5 subsequent minutes – you can then resume it by simply tapping on your AirPods. But leave it dormant for longer than that, and the home screen forgets about it and resuming is impossible:

My favourite: if you swipe through the apps back and forth on the iPhone in a touch UI equivalent of command-tabbing, there needs to be a specific moment where the app you switch to becomes the “current” app. On desktop, it’s easy – you can reset the state at the next invocation of ⌘⇥. But there is no such obvious moment on mobile.

When there is no obvious moment, timeout can be a great answer. And so it is here, and it seems to be set at about 5–6 seconds:

I understand the Google Search and the app switching examples. But I am not sure I know why a podcast resets so soon. A challenge when talking about this without seeing the code – as it is with many things on Unsung – is that I don’t know if this is carelessness, a technical limitation, a design consideration I’m unaware of, or just something that’s intentional, but I happen to disagree with. Even testing this has been hard if the delays are longer than seconds.

The extra challenge for Google Search, as it is for many other apps, is that they also reset when iOS itself purges it to make room for other apps. This isn’t great, and can be avoided if you care; we talked before about Bear and how it remembers its precise state even after the system evicts it from its memory.

Whether you want your app to remember you forever, or whether you want some deliberate forgetfulness, it could be important to take ownership of that. My go-to example of a miss in this category is Google Maps, which completely throws away its current trip-in-progress status whenever the iOS kicks it to the metaphorical curb – and returning to that status later again as a user is a really complicated sequence of steps including rewinding back the time, on top of travel already being stressful.

By the way, I can think of fewer examples on the desktop, but that makes sense given desktop apps are less tactical, and given that ⌘Q exists.

But Spotlight does freshen itself up after about 7 or 8 minutes…

…and Raycast actually offers an option to set its short-term memory from between 0 seconds and three minutes, with the default being 90 seconds:

In Figma, when choosing a font, you can filter down a list of fonts from “all” to specific categories or e.g. only fonts present in the current file.

But when you type into the search field, the search cuts across all fonts again, ignoring the applied filter. The search effectively lives outside the filter.

In Keyboard Maestro, when adding an action, you can click in the nav to filter down to a specific category. And when you search, the current filter remains active, so you search inside the filter.

Which one is better?

I don’t have a universal rule here, because it will depend both on the UI treatment, and the specific filters and searches people do.

But I think here, my recommendation for Keyboard Maestro here would be to do the same thing as Figma does. I designed that flow in Figma, so I might be biased, but my reasons are:

• There aren’t really a lot of options in each category, so you don’t benefit a lot from double filtering.
• But the most important thing: For both Figma and Keyboard Maestro, the text field might smell like a text filter and as such expected to be multiplexed with the category filter, but I think this field is actually something else: It’s quick keyboard access, like ⌘F or Spotlight or Raycast. And if you think about it this way, it’s important for it to be deterministic – I can always type “Output Sans,” no matter what state am I in, and get to the font.

On that last note, I find it’s good to look around what you’ve designed once in a while and consider not what the UI set out to be, but what it became – there might be more examples of that around you.

I love looking at origins of obvious things, because of two things:

• They help me get unstuck. If you go far enough, you will find out that even the most ossified conventions that are older than you haven’t always been this way.
• They put me in the mood of “what of the things that feel normal today that deserve to feel dated, obsolete, or awkward?”

I’ve been emulating the Apple Lisa recently, and I was struck by how many of its UI strings were slightly or wholly different than what we’re used to.

It makes sense. Lisa came out in 1983 as Mac’s predecessor and really the first GUI that is directly linked to what we’re using today. Even though it borrowed things from work done at Xerox, tons of conventions were not established yet.

So, I thought it would be fun to actually take a closer look.

For context, Lisa was as slow as it was expensive, and generally considered a failure. It was basically abandoned by 1985. Not much third-party software has ever been written, but Lisa shipped with 7 impressive office apps with fantastic names: LisaWrite, LisaCalc, LisaDraw, LisaGraph, LisaList, LisaProject, and LisaTerminal.

The screenshots below come from an emulator and from manuals (this links to the 1984 version, but each manual also includes a link to the original 1983 edition). The emulator is pretty harrowing; please upvote the idea of Lisa in Infinite Mac if you would want to see it!

As Lisa powers up, we see the appearance of the “wait” dialog box. We’ll encounter more symbols like this triangle, inspired by traditional flowcharts.

Let’s start with menus, as these really were the treasure map to the whole system.

The Desk menu is basically the equivalent of the dock today.

The File menu has Print appended to it, indicating how important printing was still then; a truly “paperless office” won’t really be possible for two more decades (and seemingly still hasn’t fully arrived).

There is no Window menu yet, so the menu also contains some of that burgeoning functionality. Set Aside is what we would call Minimize today. Save & Continue is basically a contemporary Save, and Save & Put Away a hypothetical Save & Close. Revert to Previous Version is the same as today’s Revert. By the way, in the Revert dialog I appreciated the nice gesture of telling the user how much time passed since the last save, and a warning about undo (we’ll get back to this):

Print Current Selection would today be just Print Selection. Print As Is is basically Print… but skipping the setup dialog with number of copies, etc. It was added later in Lisa’s life, and today, we’d probably call it Print Again?

If you’re noticing a pattern already, it is more wordiness compared to what we see these days. It makes sense. Our growing familiarity with these concepts is what will allow these strings to become tighter over time.

This is that Print… dialog, by the way, with beautiful “while you wait” and “while you work” verbiage (although usually I do not condone strings getting so close to each other). The manual explains: “You can have the Lisa use most of its attention to print your document while you wait. A document will print more quickly if you choose While You Wait, but you won’t be able to use the Lisa for any other tasks.”

The other strings feel less typical. Format For Printer… is Page Setup, but with a lot of quirks. Printers were not usually yet WYSIWYG, able to mirror stuff exactly on the screen. They often came with their own fonts, so some matching was necessary:

The manual had an entire section called “When Settings Don’t Match a Printer,” and there were I imagine god knows how many error cases that had to be covered, including:

And Monitor The Printer… is today’s Print Center: a way to see the real-time printing status. Note a lot of writing here elaborates further on the “while you wait/​while you work” dichotomy:

Monitor The Printer was important, by the way, since the manual warned you your printer might occasionally become haunted:

But, let’s go back to the File/​Print menu. I actually found a version of this menu that comes from a 1982 pre-release Lisa, never launched to the public. Let me show them side by side:

It’s fun to see designers figuring it all out. You will notice the lack of dividers and ellipses actually touching the work-in-progress strings. 1983’s Set Aside is 1982’s very modern Close. Save & Put Away is Put Back. And, at the bottom, it seems the team didn’t yet figure out that the menu options need to consistently use verbs for commands, and adjectives or nouns for toggles – so we see Intended for Printer… (rather than Format For Printer…) and Printing in Progress… (rather than Monitor The Printer…).

Lastly, in a released version of LisaList, this menu would come bearing a harrowing Fix Damaged Document command. Not only it doesn’t even have an ellipsis, but the manual also says “there is always the chance that the recovery process will make things worse instead of better.” Vaya con dios, I suppose.

Let’s move on to the Edit menu.

Today’s Select All is a verbose Select All Of Document, and since this is the first public appearance of undo, that feature is also more descriptive, appearing as Undo Last Change. But otherwise the menu feels surprisingly modern, shortcuts and all.

Unsurprisingly, the first undo wasn’t as developed. We saw earlier in this post “Once you click OK, you will not be able to change your mind, even with Undo,” which today would probably say “This is not undoable.” You could also see a frightening error message arriving without any further clarification, like above.

Sometimes, the app would warn you undo doesn’t have your back. We’ve seen this before, and here’s another example.

Since undo only had one step, LisaCalc and LisaList also had Restore Previous Entry for when you changed your mind after editing a cell in the spreadsheet. You had to employ this strategically, as you did the already-mentioned Revert to Previous Version.

“You can even undo Undo!” bragged the manual, and I imagine there must have been interfaces where undo came without a matching redo. But the eventual solution, of course, was bidirectional undo/​redo with many steps. This basically only needed more memory, still very expensive in 1983.

Above we also see Clear Entries that would just be called Clear today.

Elsewhere in Edit menu, Clear Lines Off Top would appear in LisaTerminal only, and was a charming (and I would argue better) way of saying Clear Scrollback.

The next menu, Type Style, would be called Font today. “Type” is typewriter nomenclature – Lisa was meant to be a typewriter replacement. The point/​pitch convention for font sizes and letter spacing also comes from typewriters, and in an older version of that menu even font names arrive from that universe (PS = Proportionally Spaced!):

Otherwise, notable is the deterministic Plain Text reset with a P shortcut that would in time lose to printing. I miss this sometimes, this “reset” idea, as I think it would nicely compliment Paste And Match Style.

(By the way, Lisa was the last computer to use Apple logo as a modifier key.)

While Type Style is for selection, Format ¶ is all about paragraphs – HTML people know this distinction as “inline vs. block.” (The pilcrow symbol means “paragraph,” although I did not expect it to be common use even then.) The flyout menus with their convoluted mechanics weren’t invented yet, but in some sense there was no need for them as the options were very limited.

It is interesting to see Margin/Tab Ruler as two options with deterministic shortcuts ([ and ]). But the most unbelievable shortcut must be Same As On Clipboard. It reformats the current selection to match what you have in the clipboard – an early salvo in an endless battle that later brought us Paste Special, Paste And Match Style, Paste And Retain Style, Copy/​Paste Properties, Paint Format and so on, and so on. And it was given S, rather than spending it on Save (& Continue).

Otherwise Left Flush and Right Flush would be called aligning today, and the ¶ pilcrow symbol would be replaced by a simple Paragraph Spacing.

In LisaCalc, Format is missing the ¶ because, well, there are no paragraphs in spreadsheets! I love Words Left/Nos. Right, and empathize with trying to align the digits. But it wasn’t even close, was it.

Page Layout shows that we’ve had UI boolean problems from day one. Show Page Ruler and Hide Page Ruler do it deterministically, with one always disabled, and without checkmarks. Preview Pages and Don’t Preview Pages do the checkmark, but introduce a dreaded double negative. (These last options, by the way, is the “pages/​pageless format” showing page margins and dividers, that bother us so much about Google Docs.) Today, these would all be in the View menu that doesn’t exist yet.

And speaking of boolean challenges, here are some top-level menus from LisaList with even more conventions:

But, back to the Page Layout Menu. Insert Page Mark would be Insert Page Break today. I really love Allow To Cross Pages as the opposite of Keep On Same Page, and the incredible O and Q shortcuts.

In LisaCalc, this particular menu comes with a beautifully named For Your Information (sentence capped, for some reason)…

…throwing up a sheet-like window showing basic stats. Today, that window would have a more boring name and probably land in the File menu:

The Search menu is fascinating – why wasn’t it called Find like its items are? I am particularly enjoying W keyed off of Find What (today: Find), while F is taken by Find Next Occurrence (today: Find Again). There is some mnemonic sense to it all, but I like today’s proximity of ⌘F/G better.

What we know as Replace is Change here, and I am particularly loving Cases Must Agree and Cases Need Not Agree (today usually called “case sensitivity.”)

Hide Dialog Box is a string with surprising to me amount of UI jargon. The H shortcut was added later in Lisa’s life, presumably at users’ behest. It’s strange today to see a shortcut like this to hide one specific floating dialog box.

Similarly, Insert Wild Card with a confusing ellipsis allows you to insert a symbol in your find dialog that stands for “match anything here” – top-level menu options reaching inside specific dialog boxes were not uncommon in early years of GUIs, but I think fell out of favor over time as the idea can be conceptually confusing.

The menu below is from LisaWrite, and I like how comparing it with other apps makes us see the team trying to settle on a convention. In LisaList there are no ellipsis, but question marks!

And in LisaCalc, there are… both:

You can notice that it wasn’t clear where one would put Find-related commands and their today’s presence in Edit menu doesn’t really make a lot of sense, either. We just got used to it. (Also note the “occurence” typo.)

Spelling menu has a bunch of fun options and conventions, and an extremely generous use of keyboard shortcuts:

• Find Next Misspelling (you don’t often see that word!)
• Suggest Corrections + Paste Guess (this is just replacing the word with the suggestion – interesting use of the clipboard metaphor)
• Put In Dictionary (today: Learn Spelling)

LisaDraw sports the Arrangement menu, which will look very familiar to anyone using Illustrator, Sketch, Figma, and so on. This is where Bring To Front and Send To Back started! With a tiny bit of editing (Arrangement is now Arrange, and some of the Objects nouns would be omitted), this would feel pretty modern.

I love these visual menus, and I think we lost that kind of stuff along the way:

Okay, let’s move on from menus. The system also relied a lot of dialogs. Let’s look at some of them:

This wordy dialog would become a small loading state today. The verbose “To terminate the operation, hold down the Apple key while you type a period” probably felt necessary because other than Shift on a typewriter, people were not familiar with modifier keys. Lisa doesn’t have the Esc key, and Mac still respects the ⌘. convention in many places in 2026.

(By the way, why would you want to stop saving? Presumably because it could take quite a while.)

In this similar dialog, you can see a reference to a “micro diskette.” Even though Lisa’s “Twiggy” disks seem gargantuan today, they were smaller compared to the original, 8″ floppy disk. (In a similar way, Lisa and other machines of the era were called “microcomputers.”)

Lisa had some proprioception: In this dialog, the disk put in the first drive is called an “upper diskette.” (Also note: more undo education.)

Disks were not large, so sometimes you had to deal with this kind of horror. It’s interesting how the dialog plain sends you to the manual – an early equivalent to eventual Learn More links.

This is another example of a rather verbose set of instructions. On one hand, this is better than “Error 456” and nothing else. On the other hand, it feels like a lot of stuff to memorize.

Also of note, the beautiful Housekeeping menu. I actually forgot about the Finder (or, in Lisa’s parlance, Desktop), so here’s a screenshot of it also:

Housekeeping was basically the junk drawer – on the Mac a year later, this will be named Special. It also has some stuff that today would be in the View menu. (This later version of Lisa calls Trash the same as the Mac. Earlier on, you would see it named a Wastebasket instead.)

Of note elsewhere in Desktop is the use of the term Stationery, roughly meaning “template,” but with extra sprinkling of desktop-metaphor skeuomorphism. Also, Attributes Of is an early version of Get Info.

Another verbose dialog (compare with Abort/​Retry/Ignore from around the same time). This is before we invented hint text that we’d just put under the buttons themselves.

In case you haven’t noticed by now, Lisa’s strings all have two spaces after a full stop!

There was lot of “you cannot” dialogs, walking you through some recovery steps.

Plug and play didn’t yet exist (this would all happen in the 1990s), so that had to be explained also.

I also love the anthropomorphic phrasing “Preferences has been told,” which I don’t believe you see anywhere today.

And I think we can round up this post with a few small delightful language details like this one.

As a huge fan of the slightly pretentious “presently” over “currently,” I smiled seeing this next to the printing status.

“Just a moment, please…” feels so old-fashioned, somehow.

And I want to end on a pre-release version of the Edit menu we’ve already seen. You can spot here Select Entire Document (instead of eventual Select All Of Document), but of course the best thing is the Copy, Cut, & Paste with an ampersand! I find it so, so charming.

I hope you enjoyed this tour. It was interesting to me to see how many of these became the standard back there and then, how many were tweaked a little bit, and which ones had to be redone more thoroughly.

Now, excuse me as I have to go deal with my whistling printer.

I have mixed feelings about Raycast announcing their move from the native interface to one powered by web tech (this is the same thing that made Photoshop’s dialogs so bad), but their blog post announcing the change has at least a useful list of some details that separate good native apps from bad web ones.

I think it’s worth checking out that list and internalizing it even if you’re nowhere near that kind of a decision, because some of these are universal requirements for a better-feeling interface:

• No cursor: pointer on interactive controls. Desktop apps don’t do this. It’s small, but it immediately signals “this is a website.”
• No hover highlights on most controls. On macOS, buttons and list items don’t highlight on hover the way they do on the web.
• Settings open in a separate native window, not a modal or a side panel.
• Popovers and tooltips render as native windows, not as DOM elements inside the WebView. They can extend beyond the window bounds, just like native popovers do.
• On macOS Tahoe, we adopted Apple’s new Liquid Glass material so Raycast blends with the system’s updated visual language from day one.
• No flickering when views appear or transition. This is a common tell in web apps, and we did a lot of work to eliminate it.

There is more in the blog post, and a lot more still left unsaid. Let me add one that I see all the time: accidental text selection. Web makes all text selectable by default, regardless of whether it makes sense for that text to be selected. On top of that, text selection heuristics on complex layouts are not that great. That means that surprisingly often you will see half a text on the page being selected in response to an accidental click or drag.

Here’s an example from YouTube I just spotted, where dragging a sidebar selects everything inside it:

It’s all solvable via the use of event cancellation and user-select, but requires someone to think about it happening.

Yes, there are moments where GUIs allow you to select text for a reason…

…but it’s always been a tricky proposition given the scarcity of affordances. It might be better to employ a pretty common “copy to clipboard” pattern instead.

A simple rule for overflow logic that will prevent your app looking a bit stupid…

…is to avoid “more” expanding to just one item. If the expansion takes up as much room as the UI to show the expansion, why not show it in the first place?

To me, “tap anywhere at the top to scroll to the beginning” is an amazing and underappreciated mobile gesture:

It not only provides an alternative to desktop‘s Home and ⌘↑ keys, but the student laps the teacher here; it’s actually better than every way to scroll to the top on desktop (do you like pressing ⌘↑? do you even have a Home key?), and it’s an icing on a cake of a regular flick to throw the page to the top already being pretty nice.

Tap to return to top is also distinctively mobile in that it allows you to tap just anywhere near the top edge that’s not already a tap target; as far as I can observe, traditional GUIs detest being imprecise in this way, always asking you to click on something specific (although window moving on macOS in the post-title-bar era is also starting to feel similar).

The iPhone gesture seemed to work so well that, over the years, more patterns started borrowing from it. In Bluesky and tons of other apps, you can tap on any tab with scrollable content a second time to scroll all the way to the top. (Again, something that’s hard to imagine on desktop, where you pretty much almost never think of clicking on an already-selected item.)

It’s not just the top, either. In Podcasts, tapping Home goes back to the left:

And in Photos, to the bottom:

To me, the whole “tap to return to the beginning” gesture universe feels ascended to be the core property of the interface. In that way, it is similar to scrolling, undo, copy/​paste, arrow keys moving the text cursor, and so on, all inducted to the National Register Of Historic Gestures.

Why? Because these gestures can only blossom if they work consistently, everywhere. You need to start trusting them so much they slide into your subconsciousness. Breaking the gesture in one place will make it less trustworthy in other places, too, ejecting it from motor memory back to the level of deliberate effort, and therefore making it a lot less usable. “Does this thing work here or not?” is a death knell of flow.

The fact that tapping on tabs is idempotent means there’s also no penalty; if you’re already at the beginning but are not sure, tapping it mindlessly won’t hurt or send you back somewhere else.

This is all great. And this is why I’m unhappy Safari started mucking with it.

Safari has tabs at the bottom – starting with two (regular set and “private” set), although you can add more. Above is a long list of site cards, with newest at the bottom. It’s exactly the same situation as in Photos, and yet tapping on either tab doesn’t restore the scroll position. Instead, it opens the settings dialog:

And, tapping around the buttons does nothing.

I would imagine Safari is a pretty important app used by many people, and so this feels like a bad place to introduce an inconsistency that could have a more serious consequences of un-teaching people about tap to scroll to top in the long run.

The funny thing is that the solution is already there: you can tap ··· in the upper left corner to get to the same functionality. The long press on the tab also opens the same menu.

Messing with a “tap to go back to the beginning” system gesture like this means to me the design team doesn’t fully share the understanding of the value of their own creation, or maybe that stewards of the gesture system are not vigilant… or perhaps the awareness is there, but the caretakers aren’t recognized, rewarded, or empowered enough.

It’s similar to the “no, thanks” example I shared before, a possible worrisome tragedy of the UX commons in the making if the respective teams do not change course. Because, wedging that sort of an exception in – even if you have a great set of reasons in the moment – creates a precedent. Inevitably, from my experience, the next team that will want to override scroll to top, or misuse “No, thanks,” will now require less of a justification.

I like sharing, thinking about, and revisiting basic rules and principles because they really do ladder up to help you with more complex things down the road.

I wrote before how a simple rule to give some breathing room to your length-limited edit fields can be upleveled to a more general “let me color outside the lines when I’m editing” principle. This is another example of a similar situation.

I am in Buttondown, which is a mailing list software. I created a quick test draft just to check something out in the editor, I didn’t do anything else, and then I proceeded to delete it. Then, I was greeted with this:

This is nothing more than a larger version of the “You have 1 email(s)” problem. There might be a situation when I’m deleting something that has been published and linked to. In that case, it’d be good to know about how any links to that thing will cease working.

But this is not that kind of a situation, and the software has all the info to know that. In this moment, it could show me a simpler, much less alarming message more appropriate to my situation. This is not the end of a radio pharma ad where you have to rattle out all the legal disclaimers just in case something could happen.

One tiny counterexample from my neck of the woods: in Figma, when you start writing a comment and then exit without posting it, you get a little warning. But you don’t get that warning when you type something that’s <= 8 characters. In this case, the assumption is that retyping a few characters elsewhere (assuming you haven’t just changed your mind altogether) is much easier and faster than cognitively processing and dismissing the warning.

The challenge with Buttondown’s dialog is that this is more than just extra cognitive processing and “cheapness.“ Here, the stakes are higher, as we’re talking about something adjacent to data loss; the dialog really does feel a bit scary and makes me think I can do some real damage in a situation no real damage is possible.

The post about Photoshop’s new dialogs traveled through some of the internet’s pipes and alleyways. Michael Tsai has a nice roundup of reactions; let me pick a few things that caught my attention.

1.
Nick Heer at Pixel Envy made a discovery that Photoshop’s new windows are… websites:

Maybe it really is possible to build a web app that feels platform native. But I have never used one — not once — and for this mess to be increasingly used in the industry-standard professional suite of creative tools is maddening.

I think it is possible – especially in the realm of classic form fields – but you really have to care and step up and test and replicate a some stuff that the operating system controls give you for free. (As an example, if the web platform/​Electron don’t give you access to the “keyboard navigation” OS accessibility setting, you’ll need to build a bridge from the OS to pass it through. This is how Figma’s Electron app got haptics, for example.)

It is true that we don’t see that level of effort often. But there are also bad native interfaces, and there might be more; Roger Wong recently made an interesting observation that stuck with me. Emphasis mine:

The mechanism differs but the outcome is the same: the platform stops being a place a designer can rely on. […] [Text user interfaces] are back because the platforms quit, and the curriculum can’t fix that.

I think I agree with this; I’ve felt there haven’t been a lot of improvements in native desktop interfaces recently.

In the mid-1990s, Apple was losing to Windows 95/98, and after years of falling by the wayside, the team eventually got their priorities in order, and rebooted classic Mac OS into a (I believe generally successful) Aqua. And in later years, Apple as a whole has often been good about creating extra distance from the peloton even if there was no immediate danger of being overtaken.

But not here. Windows lost its way, and perhaps even the memories of the darkness of the 1990s and the revival of the 2000s are now forgotten. Even if Liquid Glass was executed extremely well, macOS would still feel bereft of true evolution and care. I know there have been some slight improvements to window tiling and more recently Spotlight, but little of this betrays urgency or suggests a vision.

Finder feels like it’s been abandoned for over a decade. AirDrop UI is worse in use than many of the file sharing interfaces that came before it. This common UI is stuck in the state of the art of display colour science that is out of the previous century:

Just on the topic that is fresh on my mind: Why does Shortcuts feel like a toy in all the moments it shouldn’t, but few of the moments it should? Why does the keyboard customization situation feels so messy? Or, why are both macOS and iPadOS still stuck in the ancient way of thinking that menu bars contain all the app’s commands, when the modern approach is: it’s command bars that do, with menus containing only a subset? An innovative modern operating system would offer a universal API for command bars that any app that wants one could use – instead, apps invent their own with varying levels of success and UI quality, and automation tools cannot do much since nothing’s compatible. (This in particular is an example of an area where web apps started leading the way.)

These are just some examples that come to mind. It’s true I have admired and been inspired by some work done on Apple TV and the Vision Pro, but we also have to acknowledge that designing for net-new platforms is in many ways easier than for legacy ones.

2.
Back to Photoshop. In the Hacker News thread, at least one person from Adobe dropped in to comment, and one paragraph caught my attention:

These changes were part of the Beta program. As far as I am aware the response there was not on the same level as this blog post.

It’s not my intention to pick on this Adobe employee, and I am not aware of the specific of their beta program (although I have used Photoshop in beta for a few years). But from my experience, this is why beta testing fails in this regard:

• People in beta programs might be more lenient and excited to experiment.
• For obviously broken small UI things, people will be more inclined to think “oh, they will surely take care of that in the polish phase.”
• In general, reports of smaller UI things are less likely than bigger functional bugs like “this is not working” or “this is really slow now.” You really have to encourage and reward and incentivize people to do that, and usually identify the right people first, too.
• Please excuse my directness, but Photoshop’s user interface has felt low-quality for at least a decade now. There are a lot more examples. It’s hard to expect people in the beta to flag small UI stuff – including literal broken windows – when the evidence all around them is that the company doesn’t care.
• Just because we all encounter interfaces doesn’t mean everyone knows how to identify the things and say the words and connect the dots, especially when it comes to generally undefinable and unmeasurable craft. Good UI is deep expertise. Just like you cannot research or data science your way out of fundamentally bad product decision-making process, you also cannot add craft through relying on your users to tell you. You need to foster this on the inside.

3.
Oh, and when I say “broken windows,” I’m not just being cute. Here’s an example of Photoshop’s “explore” halo that occasionally appears on top of another app just because I have Photoshop open underneath. And, there is nothing I can do in Photoshop to get rid of it:

I think there is something fundamentally very broken with Photoshop’s (custom?) window management, seeing how PS windows jump in front of other applications, or how PS breaks other apps’s mouse pointers. But that’s a story for a different post.

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

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.

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.

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.

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.

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

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.

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.

Right next to the generic function to delete photos by going through them one by one, my camera has a specific version – Delete All With This Date:

Below the actions to close the tab, and close all other tabs, Chrome has a specific version called Close Tabs To The Right:

In After Effects, next to typical save options, there is this – Increment And Save – which saves a file and changes the number at the end to be one notch higher (Project 2 → Project 3, and so on):

I’m mildly fascinated by these strangely specific accelerators.

The one in the camera is genuinely useful. Photo projects are often day-long affairs where you download the photos at the end of workday, but might still keep them on the card just in case. Allowing to quickly delete a day’s worth of photos makes a lot of sense, saving you from having to go through them one by one in an interface not suited for that kind of operation.

Chrome’s “Close Tabs to the Right” takes a bit of figuring out, but I believe it’s meant to make it easy to clean up after a fruitful research session where you kept ⌘-clicking and opening tabs to learn more, and those tabs now fulfilled their purpose. (Curiously, Firefox also has “Close Tabs To Left” which I don’t understand.)

After Effects’s “Increment and Save” is… I don’t know. Maybe it’s cheap? Maybe it’s honest? A proper version history would be nicer, but that’s a tall order. This is simple and, most importantly, reliable. I still often do the “poor man’s version control” elsewhere…

…so this works for me.

It’s always interesting to me to think whether these kinds of oddly-specific examples are nice gestures toward the user, or treating symptoms in lieu of fixing actual problems. Either way, I don’t think an interface can survive too many of these, as their obscurity and weirdness add up and can contaminate the entire UI.

Would love if you sent me more of these kinds of commands from the apps you use!

Why is there a short wait if you press a button on your headphone remote or your AirPods to pause the music? Because the interface has to let a bit of time pass to figure out if you’re going to press the button again, making it a double press (advance to next track) instead of a single press.

This kind of disambiguation delay is everywhere for simple gestures.

Why is there a short wait if you press a button twice in that situation? The double press processing also has to be delayed, because there is a chance it might become a triple press (go to previous track).

Why is there a short wait if you press a button to go to the next track on your car’s steering wheel? It’s a delay of a different kind, but the same principle: the function cannot kick in on press down, because press down and hold mean “fast forward.” So, software has to wait for button up event to go to the next track (which feels a bit slower than button down), or for enough time to pass so we’re certain it’s a button-down hold rather than a slow press. Here, both interactions experience a penalty for coexisting.

The most infamous of those disambiguation delays exists in mobile browsers. Since every double tap can zoom into the page ever since that famous 2007 iPhone presentation, every single tap on a link or elsewhere has to be delayed by about 300ms. This has been a source of contention since it does make the web feel a bit slower, and today browsers suspend double tapping on sites designed for mobile, trading zooming affordances for higher interaction speed – after all, you can still zoom in by pinching. But if you always wondered why older websites tend to be a bit sluggish to interact with, now you know.

Different tradeoffs are possible. In the Finder, clicking on icons isn’t slowed down even though double clicking exists, because selecting an icon is compatible with opening it! So in effect it’s not a choice between a faster A and a slower B – it’s A or A+B.

Even in the iPhone presentation above, you can see the interface highlights the link on double tap, to at least make it feel snappier, at the expense of the highlight being “wrong” and potentially distracting – or even confusing – when you end up double tapping. (You can imagine smartphones pausing on the first remote/​headset button press, too. It feels like it would be compatible with advancing to the next track, but I think it might also feel too “choppy,” too chaotic, in practice.)

Lastly, why is there a short wait if you press a button on your hotel TV to increase the volume? Oh, I think that one is just sluggish for no good reason.

One of the readers (thank you, Peter!) reminded me that there is a version of a blink comparator that all of us are exposed to perhaps every day: many photo editing apps – Apple Photos, Darkroom, Aphera, I imagine others – allow you to quickly compare the photo as-shot and with your edits. Sometimes it’s a tap, sometimes an onscreen button, and in the case of Lightroom it is a backslash key. Here’s that feature on a color graded photo with some dust removed:

But these blink comparators are smart. If you e.g. rotate the photo, the comparison will be with the original also rotated so the pixels still map to each other 1:1 – even if you rotated the photo as the last step in your editing process:

I think this is a brilliant example of understanding the spirit of a feature rather than its letter. A naïve blink comparator would show an unrotated photo, but in this way it would cease being a blink comparator.

In late 2023, designer Anthony Hobday published a small list of 20 interface quality of life improvements, and recently Hobday and Katie Langerman chatted about it on an episode of their podcast Complementary.

It’s a fun listen (perhaps if you skip a bit of a bummer 9-minute beginning), covering four listed things in more details:

• generous mouse paths (especially in menus)
• coyote time for modifier keys
• optical alignments
• tooltip timing details

There were a few interesting things that caught my attention:

• Figma does have “coyote time” in the very interaction the hosts are talking about, perhaps showcasing that the details of the details can make or break them.
• “Should modifier keys be reversible” and “should modifier keys be consistent with one another” are interesting challenges; some more recent graphic tools have changed the long-standing behaviour here, malking modifier keys more “sticky.”
• Wholeheartedly agree with how frustrating it feels that the menu interactions are not yet baked into browsers as primitives. “The fact that the companies keep having to implement it themselves manually is maddening.” It is.
• Good observation that some people associate animations with “feeling premium” (see also: the quote I put in the title).

A few years ago, I suggested adding a new interaction to Figma. If your text cursor was on a misspelled word (anywhere inside, or the edges), you could press Tab to quickly accept the suggested correction, without even seeing it:

Independently, Google Docs approached it from a slightly different angle, but landing on a similar interaction – in their version there’s a small visual callout, although you can still press Tab (and then Enter) to accept the suggestion:

I know the Tab key has a lot of jobs – from indenting bullet points to jumping through GUI elements – but in this context this new addition doesn’t seem to be in conflict.

(Should I write a long photoessay about the Tab key, similar to the ones I wrote for Return/​Enter and Fn keys?)

Since we added it, I’ve really loved how it feels. From various typeaheads and autocompletes elsewhere, Tab has a strong “forward movement” energy so it makes conceptual sense, and it’s just really fun to go around and quickly fix your writing this way.

I think a lot about how to make keyboard interactions feel superpower-y: a good keyboard shortcut on a large key, a tight interaction, a blink-of-an-eye velocity – something that’s eminently designed to lodge itself in your motor memory as quickly as possible, as it builds on top of prior motor memory. I’m biased, of course, but I like the “no scope” Figma version more, and it has that feeling to me.

Column view cut its teeth on NeXT computers…

…and blossomed on early versions of Mac OS X…

…but where I thought it really shone was the first iPods:

This was perhaps the most fun you could ever have navigating a hierarchy of things; it made sense what left/​right/up/down meant in this universe, to a point you could easily build a mental model of what goes where, even if your viewport was smaller than ever.

It was also a close-to-ideal union of software and hardware, admirable in its simplicity and attention to detail. This is where Apple practiced momentum curves, haptics (via a tiny speaker, doing haptic-like clicks), and handling touch programmatically (only the first iPod had a physically rotating wheel, later replaced by stationary touch-sensitive surfaces) – all necessary to make iPhone’s eventual multi-touch so successful. And, iPhone embraced column views wholesale, for everything from the Music app (obvi), through Notes, to Settings.

Well, sometimes you don’t appreciate something until it’s taken away. Here are settings in the iOS version of Google Maps:

I am not sure why the designers chose to deviate from the standard, replacing a clear Y/X relationship with a more confusing Y/Z-that-looks-very-much-like-Y. They kept the chevrons hinting at the original orientation – and they probably had to, as vertical chevrons have a different connotation, but perhaps this was the warning sign right here not to change things.

I think the principle is, in general: if you’re reinventing something well-established, both of your reasoning and your execution have to be really, really solid. I don’t think this has happened here. (Other Google apps seem to use standard column view model.)

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

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

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

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

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

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

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

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

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

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

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

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

I mentioned placeholders before in the context of Dropbox Paper…

…and I wanted to share a response by Nikita Prokopov, because he had a great point about those Dropbox Paper placeholders that I didn’t consider:

For me it’s […] confusing placement. Like if somebody writes “Have a nice day” on a door instead of “Push” or “Pull”. I don’t mind seeing “Have a nice day” message somewhere neutral, in a place not occupied by any other function, but not where I expect very specific help.

I was reminded of Prokopov’s comment when I saw this at the airport yesterday:

I remember, eons ago, how impressed I was when one of the Chrome designers was telling me how all of these error pages were specifically designed to feel like liminal spaces and notlike destinations. These were, in a way, placeholder content.

But “Press space to play” feels like a strange thing to put in here. (Previously, the message said “No internet” or “There is no Internet connection.”) I understand that this is Chrome’s popular mascot, but this is still an error page whose purpose is to tell me what’s wrong, rather than serve as an entry point to a minigame.

Also, just a few days ago, I just stumbled upon this fun example of a placeholder collapse – where a temporary text becomes permanent:

If you are curious, this is what it looks like if you don’t forget to set the message. And funnily enough, given where we started, it says “Have a nice day”:

I feel like social media and recently the slate of AI-powered “tell me what’s here” features continue to show us the power and longevity of screenshots. After all, nothing beats a more or less approachable shortcut and a file format that works literally everywhere.

But screenshots have issues, and I liked how Bear (a note-taking app) brilliantly integrated OCR inside images into its flows. This just worked for regular ⌘F finding without me having to do anything:

The recognized text also appears when you search through notes, and so on. It’s just a great peace of mind that you’re not going to miss on text just because you happened to screenshot it.

Apple operating systems have had detection of text inside images for a while – I know on iOS in particular it sometimes gets in a way of normal gestures – so I thought it was just that, but curiously this doesn’t work as nicely in Apple’s own Notes.

To be fair, I am traveling and haven’t looked for solid evidence or citation that this works for people, but I personally like this approach: in lieu of a separate language selector button, each option here itself is both a language selector and a commit button.

The labels themselves are not the name of the language, but a call to action; I imagine recognizing the one label that means something to you should be easy if the other nine look like gibberish.

And, a thoughtful moment by one exhibit: Not only showing you where you are in the sequence of three videos, but even within the currently-playing video.

(I’m less of a fan of stretched type, though.)

This is a typical iOS Gmail dialog that allows you to snooze an email so it resurfaces later:

If you invoke that function on an email that’s an order receipt, a new option appears:

It’s great to see this clever and thoughtful button which is likely the best option here. But:

• It reshuffles everything else, preventing motor memory from building. At this point, you can no longer rely on “bottom left” to always be “custom date,” and so on with other buttons. (One idea would be to put it at the back but draw attention to it visually, or at least make it span the entire row.)
• It doesn’t show you the inferred date, even though there already is a precedent for doing that – especially important here as the feature seems to be powered by AI, which can get things wrong.
• The icon heavily promotes the AI association, which is not that useful. It would probably be better to show a truck or some other visual signifier of “delivery.”

The search for the strangest Adobe setting continues in Lightroom, where the first option in the Interface section is… end marks:

Presently, only one option is there…

…but at least back in 2012 there were many more:

What does it do? It adds an old-time’y glyph at the end of either left or right panel.

The internet is rife with people perplexed by this option and I cannot deny – I’m one of them. (The title of this post is a reaction of one of the users.) It feels like such a peculiar way to add delight.

You are not limited to the pre-existing (one) flourish, as you can upload your own. Some people add a logo of their production studio, but John Beardsworth found a more creative use:

Alternatively, with a tiny bit of imagination you can exploit an often-forgotten detail of Lightroom’s interface – the “panel end marks”. These decorations at the bottom of Lightroom’s panels have often been derided as a waste of programming time, but in fact they can be made to serve more than their somewhat-trivial purpose. And as you can see in the examples on this page, they can serve as a reminder of star ratings, colour labels and even keyboard shortcuts for flags.

This is a fascinating hack, and an example of William Gibson’s famous “the street finds its own uses for things.” It made me curious why didn’t onscreen interfaces ever evolve to allow you to annotate them easily? You see stuff like this a lot in real life…

…but the Lightroom end mark hack is the only thing that comes to my mind where an onscreen UI got this kind of a treatment – and the feature wasn’t even intended for that use.

I think about some aspects of interface design as sugar.

This is how you adjust the photo in Photos app in the previous version of iOS:

And this is the same view in the current version:

The difference is in the delayed/​animated falling of the notches.

I don’t think it’s great. It’s “delightful” in a rudimentary and naïve sense, but like sugar, you cannot just add it to your daily diet without consequences. This extra animation serves no functional purpose, and the sugar high wears off quickly. What remains is constant distraction and overstimulation, the feeling of inherent slowness, and maybe even a bit of confusion.

It pairs nicely with the previous post about avoiding complexity and rewarding simplicity. I often see this kind of stuff as related to designer’s experience. Earlier on in your career, you are proud you’ve thought about this extra detail, you’ve figured out how to make this animation work and how to fine-tune the curves, and you’ve learned how to implement it or convince an engineer to get excited about it.

Later in your experience, you are proud you resisted it.

MKBHD’s Waveform podcast (audio or video) sometimes has a fun “Did they even test this?” section. This week, for the first 12 minutes, the team was ranting about various volume controls – a meandering conversation that I also found just very enjoyable.

The cited answer to “why do a lot of car volume controls max out at 38?” is in a 2021 article from Car And Driver:

But then some research revealed that about 20 years ago, Chrysler decided to try to find the perfect volume interval, one that would result in meaningful difference in sound level without going too far. After much experimentation, they decided that 38 discrete volume settings provided the perfect amount of adjustability—not too fine, not too coarse. So the decree went out across the company that all stereos should go to 38.

However, no citation is given, and I couldn’t find any more information about it.

The one thing the group missed in their discussion is “why even show a number”? I think it helps people in remembering their preference, especially if they share a car with someone else. Remembering that “my volume number is 17” can be helpful, even if it feels a bit clunky.

When volume controls were physical, I believe if they didn’t have a number, they at least had a certain amount of notches so you could remember the nearest notch you liked:

Keynote is an app that could use something like that. At this very moment, I am trying to unify the volume of various clips across slides for an upcoming presentation, and having to use environmental cues like “between Edit Movie below and the rewind button above”:

I have been at times frustrated by cute placeholder text in places, most notably Dropbox Paper, which still puts them in a just-created doc…

…and in new to-do items:

This bothered me for two reasons.

First was a potential tone mismatch. What if you are writing a layoffs announcement, a project cancellation doc, or something personal and heartfelt? At Medium back in the day, at some point we added a fun celebratory dialog after publishing that said something like “Now, shout it out from the rooftops!” We took it down very quickly as people made us realize Medium is used to write many kinds of things we didn’t anticipate, and in those situations the cutesy message really failed to read the room.

But the other half of my frustration with Paper was that it felt like the app was making itself too comfortable in my space, in effect shouting all over my inner voice and distracting me. I felt like any app giving you a creative canvas should back off of that canvas unless it’s explicitly invited to participate.

Turns out, I can now attach something tangible to that discomfort. From Scientific American earlier this week (emphasis mine):

The researchers asked participants to fill in an online survey with questions about hot-button social and political issues. Some were prompted with an AI autocomplete answer that was deliberately biased toward one side of the issue. For example, participants who were asked whether they agreed that the death penalty should be legal might receive an AI suggestion that disagreed.

Across all the different topics in the survey, participants who saw the AI autocomplete prompts reported attitudes that were more in line with the AI’s position—including people who didn’t use the AI’s suggested text at all. Overall, the study participants who saw the biased AI text shifted their positions toward those espoused by the AI.

Interestingly, the people in the study didn’t tend to think the AI autocomplete suggestions were biased or to notice that they had changed their own thinking on an issue in the course of the study.

The quoted study shows an example…

…and elaborates on how adding warnings didn’t really help:

The Warning and Debrief messages failed to significantly reduce the attitude shift, which is concerning because they were also inspired by those used in real AI applications. AI tools such as ChatGPT show brief and general statements about AI’s propensity to hallucinate false information (e.g., “ChatGPT is AI and can make mistakes. Check important info.”), similar to the messages used in our interventions.

I know on this blog I often focus on the mechanics of interactions, but the job of every designer is to think of more than that. I keep coming back to both pull-to-refresh and infinite scroll mechanics. Both can be put to good use and feel “delightful,” but both started being abused so much that it led to their respective creators disowning them.

There are fun things you can do in software when it is aware of the dimensions and features of its hardware.

iPhone does a cute Siri animation that emanates precisely from the side button:

A bunch of Android phones visualize the charge flowing to the phone from the USB port…

…and even the whole concept of iPhone’s Dynamic Island is software cleverly camouflaging missing pixels as a background of a carefully designed, ever morphing pill.

But this idea has value beyond fun visuals. iPhone telling you where exactly to tap twice for confirming payment helps you do that without fumbling with your phone to locate the side button:

Same with the iPad pointing to the otherwise invisible camera when it cannot see you:

Even the maligned Touch Bar also did something similar for its fingerprint reader:

The rule here would be, perhaps, a version of “show, don’t tell.” We could call it “point to, don’t describe.” (Describing what to do means cognitive effort to read the words and understand them. An arrow pointing to something should be easier to process.)

You could even argue the cute MagSafe animation is not entirely superfluous, as over time it helps you internalize the position of the otherwise invisible magnets on the other side of your phone:

In a similar way, as it moved away from the home button, iPhone X introduced light bars at two edges of the screen – one very aware of the notch – as swiping affordances:

And under-the-screen fingerprint readers basically need asoftware/​hardware collab to function:

One of my favourite versions of this kind of integration is from much earlier, where various computers helped you map the “soft” function keys to their actual functions, which varied per app…

…and the famous Model M keyboard moving its keys to the top row helped PC software do stuff like this more easily:

(And now I’m going to ruin this magical moment by telling you the cheap ATM machine that you hate does the same thing.)

The last example I can think of (but please send me your nominations!) is the much more sophisticated and subtle way Apple’s device simulator incorporates awareness of the screen’s physical size and awareness of the dimensions of the simulated device. Here’s me using the iPhone Simulator on my 27″ Apple display. If I choose the Physical Size zoom option, it matches the dimensions of my phone precisely. The way I know this is not an accident is that it remains perfectly sized if I change the density of the whole UI in the settings.

Why am I thinking about it all this week?

The new MacBook Neo was released with two USB-C ports. Only one of the ports is USB 3, suitable for connecting a display, an SSD, and so on. The other port’s speeds are lower, appropriate only for low-throughput devices like keyboards and mice.

To Apple’s credit, macOS helps you understand the limitations – since the ports look the same and the USB-C cables are a hot mess, I think it is correct and welcome to try to remedy this in software. It looks like this, appearing in the upper right corner like all the other notifications:

I think this is nice! But it’s also just words. It feels a bit cheap. macOS knows exactly where the ports are, and could have thrown a little warning in the lower left corner of the screen, complete with an onscreen animation of swapping the plug to the other port – similar to what “double clicking to pay” does, so you wouldn’t have to look to the side to locate the socket first.

“Point to, don’t describe” – this feels like a perfect opportunity for it.

This iPhone UI for dark/​light theme is doing something clever:

Ostensibly, there are two modes here:

• automatic, for when you want the theme to match the time of day
• manual, for when you want to keep one of the themes forever

But check out what happens when I am in automatic mode, but toggle the theme by hand anyway:

More rigid or less thoughtful interfaces would either disable manual changes when you’re in automatic mode, or understand a manual theme switch to mean “I want to turn off automatic.”

But here, iOS is quietly putting me in a temporary hybrid mode: a manual theme override until the theme catches up with what automatic mode would do, at which point it snaps back (I’m resisting very hard calling this rubber banding) to automatic mode.

What I think is clever is that this isn’t presented as a third mode – which could be more confusing than helpful – but the design simply reuses the existing Options field to set the expectations.

One has to be careful designing in shades of gray; once you enter the space you really have to commit to it and see it through. My go-to analogy is symmetry vs. asymmetry. Symmetry in visual design is usually easier and safer. If you venture into asymmetry you have to make an effort to make it work. The highs of asymmetry will be higher than anything symmetry can provide, but getting to those highs can be arduous and sometimes might even be impossible.

I thought this particular example was really nicely done and the team found a great balance. (I think Apple’s previous shade of gray – “Disconnecting Nearby Wi-Fi Until Tomorrow” – ended up slightly less successful.)

I just stumbled upon a nice little power-user innovation in Chrome’s Web Inspector.

In Safari, and previously in Chrome, when editing CSS properties, you’d get a usual editing typeahead for the property name, and then the same on the other side for the property value.

In newer versions of Chrome, the typeahead menu works as before on the right side. However, the menu on the left side also includes the right side.

I think this is really clever in this context – not just to speed you up, but also to aid understanding. Just like the inert mouse up and down in the previous post could serve as a safe “peek” into the values, this new interaction can quickly allow you to explore the CSS space if you are curious, or if you only lightly remember part of the name, or even just one of the values.

This blog is authored in Apple Notes, and some time ago Notes added quick linking via typing >>, and that has a similar effect: The interactions are so nimble and precise that it is very easy to link to something, but a nice side effect is that it also feels very welcoming just to type a few letters to remind yourself of a title of an article, and then cancel out.

The downside of the Chrome change is, well, more stuff matching, but I think the audience for this UI is going to be okay with that.

I know we’re probably collectively a bit tired talking about macOS Tahoe, but I just noticed something that I think is a good example of how small details can ladder up to bigger things.

This is macOS Sequoia (the pre-Tahoe release) and a typical pop-up button:

One clever thing macOS has been doing since basically the dawn of GUIs is that upon clicking on a button like this, the currently selected row will be in the same place as before you clicked. (As opposed to, for example, the entire menu appearing below like it would from a top menu bar.)

This has interesting and often underappreciated consequences. It allows you to orient yourself quicker since you don’t have to find the selected option again. And, it saves you movement overall: the next or previous option will always be at the absolutely shortest possible distance. (Of course, the approach also has some challenges,for example if the button is positioned close to the top or bottom of the screen.)

There’s another clever thing that happens throughout macOS: All the menus work using a classic click-to-open and click-to-select sequence, but they are also usable via the slightly more advanced, but faster mousedown-drag-mouseup gesture.

These building blocks work together and mean that selecting the next option can be as simple as a little flick of a mouse.

Now, check out macOS Tahoe (current release):

You will notice that iCloud Drive, upon clicking, is now misaligned both horizontally and vertically.

On the surface, this feels just like a visual blemish – slighly embarrassing, but without much consequence. But check out what happens if you hold your mouse button at a certain position, and then release it without moving:

The stability of macOS’s interface and the thoughtful set of aforementioned rules allowed for an emergent fast behaviour: mouse down and up meant you could “peek” into a menu safely, or you could change your mind right after seeing what’s inside. In a bigger sense, it created a certain trust between you and the operating system: it’s worth learning those gestures, as they will be rewarded.

In Tahoe, some of that learned behaviour – by the way, I see it in all of these buttons, not just this one – will now work against you. Now, you can accidentally change an option without intending to do so.

Is it a big deal? No, not really. This likely – hopefully! – simply fell through the cracks in a rush to get Liquid Glass out the door, rather than no one being there to care, or no one understanding that all these gestures add up in aggregate, creating a GUI that feels fast, trustworthy, and catering to your motor memory in a way that elevates your experiences with the interface in the long run.

But I’d feel better if it wasn’t almost half a year since the release, and if we hadn’t already seen other things exactly like it.

One of the most mysterious keys on the PC keyboard has always been Scroll Lock, joining Caps Lock and Num Lock to create the instantly recognizable LED triumvirate:

Scroll Lock was reportedly specifically added for spreadsheets, and it solved a very specific problem: before mice and trackpads, and before fast graphic cards, moving through a spreadsheet was a nightmare. Just like Caps Lock flipped the meaning of letter keys, and Num Lock that of the numeric keypad keys, Scroll Lock attempted to fix scrolling by changing the nature of the arrow keys.

This is normal arrow key usage in Lotus 1-2-3, doing what you’d expect, if likely a bit slower:

And this is Lotus 1-2-3 with Scroll Lock enabled. Here, the arrows do not move the cursor, but move the spreadsheet:

(You can play with it yourself!)

In time, scrollbars helped with the problem, then mice with wheels solved it in one direction, and then trackpads in both. (Although even though my 2025 Windows laptop doesn’t have a Scroll Lock key, its onscreen keyboard does, and the key still works in Excel.)

But, I grew to believe that UI problems never fully die, and often come back dressed up in new clothes.

This is the TV app on my Apple TV, doing movement as you’d expect:

But Netflix a while back picked a different approach – scrolling almost as if Scroll Lock was on:

More recently, I saw that approach spread to HBO Max and YouTube apps as well:

Is this good? To me personally, the Scroll Lock-esque approach feels strange and claustrophobic. I see the (hypothetical) value of keeping the selection in one place, but the downsides are more pronounced: things feel lopsided, going back in this universe is flying blind, and the system creates strange situations at the edges, where Scroll Lock struggled as well.

And yet, given I just dated myself by reminiscing Lotus 1-2-3, I’m curious how it feels to others.

Mac allows you to assign keyboard shorcuts to menu items, but the interface is clunky – you have to select the app even if you just came from it, and then type in the menu item name by hand without any assistance:

Other tools, like Keyboard Maestro, do something similar. You either have to type it again, or you can point to it, but in a replica of the menu of the app shown in a very different style and orientation:

But this week I learned of another app, KeyCue, that approaches this differently. You simply point to the menu item and hold the desired key for a while:

Okay, this is not a universal endorsement. The feature works clunkily, and KeyCue as a whole is way too comfortable adding itself to login items without asking.

But as far as singular interactions go, this is great and eye-opening. It made me realize that the previous things I’ve shown – System Settings, Keyboard Maestro – are really not GUIs, and they don’t practice direct manipulation. They’re still partially command line interfaces dressed up in GUI clothing.

We kind of lightly made fun of Jony Ive going angelic on “staying true to the material” and things being “beautifully, unapologetically plastic.” And there is, of course, value in command line and those kinds of approaches. But this part of KeyCue at least is unapologetically a graphical user interface, and it is nice to still be surprised in this space.

I keep thinking about this very good 11-minute Not Just Bikes video about traffic calming. In it, a simple argument is made: the posted speed limit of any given street or road doesn’t really matter. What matters is how the street feels. Generously wide and separated lanes, sparse traffic lights, and the road being straight past the horizon will make you unconsciously speed up. Reducing the posted speed limit or adding flashing YOUR SPEED signs won’t help:

The truth is that many drivers will not slow down because of signs or speed limits. They’ll slow down either because they don’t feel safe, or because they’re afraid of damaging their car.

The only answer is redesigning the street for the desired speed limit – narrowing the lanes or joining them, creating choke points and speed bumps, adding posts and planting trees close to the road, and even adding visual cues like “dragon’s teeth.”

One of the great thing about driving in the Netherlands is that it’s rarely necessary to look at the speed limit. The road design takes care of that for you.

There is an app I use a lot called Forklift, a suped up Finder, with one of its functions being syncing files to a remote server.

In its version 3, the syncing window looked like this:

This is a pretty straightforward and dependable function – and I’ve depended on it for years.

I recently updated to version 4 to check it out, particularly since it promised faster syncing. But I was thrown aback by how it randomly deteriorated:

It’s not that there seem to be some UI challenges: the new icons make it harder to understand hierarchy, and one of the switches starts with “Don’t” in contravence of rules of avoiding double negatives.

No, the worst part is this:

This is a new temporary state that meant to help me understand the details of what’s changing.

On the surface, it’s a thoughtful thing. But it’s done in the worst possible way for this kind of a power-user interface: It’s very slow to invoke and slow to cancel. I often activate it by accident – it makes large swaths of UI a minefield where you can no longer rest your cursor safely. It also changes the hierarchy of the output in a way that’s confusing – and it even animates the text wrapping in a distracting way. Then, if you press Esc instinctively to get rid of whatever happens, the window closes altogether.

It’s a “delightful,” luscious transition that is completely out of place. I think this is how many people misunderstand craft – that it’s only about “high polish” without any thought underneath. Here, the effort was spent on executing something that couldn’t be saved this way and needed a more serious rethink. It seems like its creators forgot who’s using the app and for what, and embarked on accidental UI calming.

There are other challenges along the same lines, both downgrades from version 3:

• when the app analyzes the differences, I can no longer press the Sync button and walk away
• even when the button becomes active, I can no longer press Enter to activate it – I have to use the mouse

In version 3, I could invoke Sync, immediately press Enter, and get on my merry way, with syncing continuing in the background. It was exactly what I wanted. Version 4 slows me down by requiring me to pay constant attention to the interface: it matters where I rest my mouse, it matters when I click the button, it matters what input device I use to commit.

It’s okay to think of friction and sometimes transitions are indeed very helpful for UI calming to avoid drastic movements or accidental activations. But here, this isn’t great at all; the creators of Forklift promised me faster syncing and achieved the opposite.

As you progress in your UI design career, you learn that there are quite a few unsolvable challenges:

• do you write My Items or Your Items in UI?
• do you put hand cursors over buttons?
• for a boolean item (especially in the menu), do you talk about the present state or the future state?
• do you try to solve for change blindness or change aversion?

I was reminded of one of those today: how do you sort items in a bottom-aligned menu?

One school of thought is to keep it in the same order as you would a regular top-aligned menu:

On the positive side, this allows to build consistent understanding of how menus are structured: the most important thing is at the top, Quit is always at the bottom. But the downsides are obvious, too – now the most important item is furthest away from where you cursor started, and you have to awkwardly cross all the other items on the way to it.

iOS’s springboard went, literally, the other way:

Here, the bottom aligned menu reverses its item order. This tripped me up today. The dock in macOS was actually more defensible upside down because there, every menu was always going the same way. Here, the inconsistency starts rearing its ugly head.

Of course, the best way to not face an impossible choice is to avoid it altogether. Not sure how one could accomplish it here, though. Placing the menus consistently below would make some of them scrollable, or basically invisible for bottommost icons. You could also slide the entire screen up to make room for the menu, but that would probably feel disorienting.

So, I can’t say this is a wrong solution. The inconsistency might only bother people who use this often, and maybe no one uses this often? Or, perhaps, it was really important to allow to resize widgets and make that item as easy to tap as possible? But still, I think I would have done it the other way – align as needed, but items always in the same order.

I have been enthralled with this tiny feature in Google Sheets called “Show edit history,” which premiered in 2019:

Mind you, it’s not unconditional love. The execution feels a bit clunky, showing the edit values in a pop-up rather than in situ, with formatting that feels too heavy, and an awkward “No more edit history” state rather than just disabling the button.

But! Just its very presence here is delightful. Version history is often this huge, comprehensive, perhaps disorienting mode you enter that by design deals with the entire file. It always feels like a longer trip:

But edit history reimagines the feature from the perspective of the cell. You can just peek inside, quickly and effortlessly. Right click menu, a few arrows, I learned what I needed, and I barely even moved my hand. It’s a perfect example of the rule “to make something feel faster, make it smaller.” It’s like picking your newspaper at your doorstep in your pajamas rather than having to dress up to go to the newspaper store.

(…he said, dating himself and perhaps also thinking of The Sopranos for some reason.)

This kind of reimagining of something that already exists (see: undo send in Gmail) can be really hard, and I don’t even imagine Google Sheets was the first with this idea – but for me seeing this remix was eye-opening, and it inspires me to this day.

For a few months now, when re-running search queries in Bluesky’s iOS app, I ended up occasionally arriving on the wrong search, and it happened enough that I started suspecting something’s afoot. (Ahand?)

So I opened the app on my Mac via iPhone Mirroring, and started clicking testing carefully. This is what I saw:

Turns out there was something wrong there – the touch targets are so vertically lopsided you’ll often end up tapping the item below by accident.

I reported the bug to Bluesky, and a few days later I saw Norbert Heger doing a similar thing vis-a-vis the macOS Tahoe rounded corner bug (previously):

Heger’s method is automated and a lot smarter than mine, but I enjoyed seeing these parallel efforts.

What’s the lesson here? I think it’s this: Trust your fingers, and occassionally speak for them as they can’t speak for themselves.

This is a nice way iOS Safari behaves the moment you tap one of the font size buttons – it immediately ejects all the other chrome:

After Liquid Glass specifically, we seem to be going through an interesting re-evaluation of whether “the content is the king; it should feel expansive and UI should get out of the way at all costs,” so seductive as a principle, is ultimately the right approach. Liquid Glass-sporting operating systems have so many contrast and blending and distraction issues that I wonder if they alone are radicalizing people, making them appreciate traditional rigid toolbars with solid backgrounds and fortified borders.

But here? Here letting contents shine and putting the UI atop feels like the absolutely right thing to do, since you are redesigning your reading experience.

Contrast this with Books:

It’s not even that the crossfaded transitions feel awkward. It’s mostly that the interface takes up so much room that the content preview slice becomes almost claustrophobic. And it’s even weirder when you tap the Customize button, and whatever was visible gets inexplicably replaced by a pop-up with… largely the same content anyway.

How will the entire page feel? For that you have to use your imagination – or keep tapping back and forth.

Old-school computing has a term “molly guard”: it’s the little plastic safety cover you have to move out of the way before you press some button of significance.

Anecdotally, this is named after Molly, an engineer’s daughter who was invited to a datacenter and promptly pressed a big red button, as one would.

Then she did it again later the same day.

You might recognize molly guards from any aerial combat movie you ever watched:

And some vestigial forms of molly guards exist everywhere in civilian hardware, too: from recessed buttons, through plastic ridges around keys, to something like a SIM card ejection hole.

Of course, molly guards happen in software, too: from the cheapest “are you sure?” dialogs (which sometimes move buttons around or disable keyboard activation to slow you down), through extra modifier keys (in Ctrl+Alt+Del, the Ctrl and Alt keys are the guards), to more elaborate interactions that introduce friction in places where it’s needed:

But it’s also worth thinking of reverse molly guards: buttons that will press themselves if you don’t do anything after a while.

I see them sometimes, and always consider them very thoughtful. This is the first example that comes to my mind:

Here’s what became a standard mobile pattern:

These feel important to remember, particularly if your computer is about to embark on a long process to do something complex – like an OS update or a long render.

There is no worse feeling than waking up, walking up to the machine that was supposed to work through the night, and seeing it did absolutely nothing, stupidly waiting for hours for a response to a question that didn’t even matter.

It’s good to think about designing and signposting those flows so people know when they can walk away with confidence, and I sometimes think a reverse molly guard could serve an important purpose: in a well-designed flow, once you see it, you know things will now proceed to completion.

I liked this little microinteraction by Mario Guzmán explored on Masto – it felt like a clever idea to help you locate a tiny widget on what might be a huge screen or two:

But it also made me think. I still strongly associate macOS shake with “wrong password,” meaning “you’re doing something wrong” – something the system has been teaching us ever since the late 1980s NeXT computer, whose windowing manager it inherited. Am I careful about the motion vocabulary and the semantics of shake, or am I simply overthinking it? Sometimes it is hard to tell.

(By the way, is it okay for me to link to random work by strangers, or is it weird? Don’t be afraid to let me know. One thing I want to practice on this blog is various ways to be a critic, in the sort of Roger Ebert sense.)

This menu in Chrome feels like a surface running away from its creators:

I think cerebrally I understand the subtle difference between Show and Always Show, but is that difference worth it? Because at some point the repetitiveness and heaviness of that top section is casting a huge shadow over the rest of the menu.

I have an internal rule for adding a new menu item that happens to result in the longest string yet: think about the volume – the literal amount of pixels – you’re adding to the whole surface. Big menus are scarier, wide menus separate items from their shortcuts, submenus become harder to jump into, and so on. The economy of words can benefit in more ways than just the obvious ones.

But what made me a little nervous were the two grayed out options. What does it mean for something starting with Always Show to be grayed out here? What does it mean for something to be grayed out and enabled? My guess is that someone wired these without thinking too much about all the states, but it results in a stressful tension. Software should be making it very clear about what is under my control, and what is not.

Lastly, and this is almost funny: Full Screen is either 🌐F or ⌃⌘F, in all standard Mac apps. This alone is already confusing, as is Apple’s entire horrible Globe/Fn strategy (this is a story for another time), and I verified they both work independently in Chrome. How did they get conflated into one shortcut from hell is probably a really interesting bug somewhere – but also a sign no one is seemingly paying attention.

A few thoughts after reading Gruber’s take on Finder and its new auto-sizing columns:

1.
Column view as a concept and when done well deserves to be in the UI hall of fame. It flew and still can fly high in the Finder, and it was the unsung hero of both the iPod and the iPhone. It’s really fun to fire up NeXTSTEP 0.8 in Infinite Mac and see its first incarnation.

2.
Apple decided not to ship the auto-sizing columns a few years ago, hiding it under a “defaults write” incantation as a sort of a beta, but then seemingly just launched it this year without any changes. There are some charitable explanations – perhaps the beta was hard crashing Finder and the released one no longer does? – but in the current zeitgeist I’m feeling that it’s something more like this: the people with taste who were stopping it from getting launched in the bad state were either sidelined or are no longer there.

3.
And it is a bad state. It’s a first draft made public. Like anyone who deals with layouts learns over time, things like this one need careful min and max widths to have certain good pleasing and stable visual rhythm. They might even need a scale or a grid on top. And the fact that the width accommodates only visible objects doesn’t seem to make sense.The top hand doesn’t know what the bottom hand is doing, and it feels the feature is incompatible with itself.

This feels like an old Unix windowing feature, a sketch of an idea for GUI nerds who get excited about just the cool concept alone, ignoring the execution. Although, to be fair – this is opt-in and buried as the last checkbox inside a pretty obscure window. This might still be GUI nerd territory.

4.
So Apple really did think we’re going to love Liquid Glass, huh?

Just a few hours after writing about floppy disks, I stumbled upon a bona fide floppy icon in the Bluesky’s iOS app, anno domini 2026:

I imagine this, in a nerdy view deep inside settings, might be more of a fun nod, but it made me curious – does Word still use a floppy icon?

Yes, it does! Right next to the icon-less AutoSave toggle, deep within a veritable kowloon walled city of interface elements.

And yet, maybe I should chill with the jokes – NN/Group revisited the save icon in July of last year and surprise! People still understand them.

83% of participants associated the floppy disk icon with saving. […] Another 13% described this object literally with responses such as “disk,” “disc,” or “this is an SD card for storing information.” These responses were not coded as “save,” but still suggest familiarity with the image.

What a fascinating journey! The icon didn’t change at all, but its perception went from being a literal representation of a familiar object, to a skeuomorph once floppies were replaced by hard drives, to then a symbolic representation of physical media in general (a lot of people think it’s an SD card – or perhaps even that floppy disks and SD cards are one and the same), to increasingly just an abstract symbol that represents saving as a concept, registering similarly to the circular arrows for syncing, and an arrow pointing south for downloading.

NN/Group is itself kind of a floppy disk, trying to walk a fine line between their legacy and reinventing themselves. They’re dismissed by many as old-school, academic, boring enterprise software aficionados, relics of a different era. I see some of that and often disagree with them, but I also sometimes appreciate their rigor, reliance on user studies, and outright dismissal of fashion in UI design. I want to revisit their site in more detail and see how I feel about it today, 30 years after Jakob Nielsen’s books rocked my world.

Many designers and engineers have Apple products with their flawless and praise-worthy trackpads. By default on macOS, trackpad means only “shy” (iPhone-like) scrollbars are shown. Shy scrollbars become half-visible when two-finger scrolling, and only fully visible when hovering over them.

To anyone working on front-end, I encourage you to toggle this setting to “Always,” and convince half of your team to do the same. Your macOS will now pretend you have a mouse connected, and show more traditional scrollbars, all the time.

Why? Because you might already be accidentally generating spurious scrollbars without realizing. Here’s something I just spotted in Coda today:

This scrollbar serves no purpose, so it will become visual noise for a lot of your users. But when you yourself use “shy” scrollbars, you might not even realize.

Of course, the scrollbar is just a symptom of a bigger problem – an accidentally scrolling surface that will be janky to everyone regardless of their scrollbar visibility status.

Always-visible scrollbars make it easier to spot these, not to mention also being helpful in spotting:

• scrollbars mismatched in theme (e.g. light scrollbars on dark-theme surfaces) or accidentally left unstyled
• scrollbars not fully nestled into their correct edge, accidentally being offset from the top or the right
• using a wrong CSS setting for overflow (or not knowing about the -x and -y variants), and consequently showing both scrollbars when one will suffice
• the loading state or skeletons not anticipating a scrollbar appearing later
• that most frustrating occasional math/​measurement issue where the appearance of vertical scrollbar reduces the horizontal space, and as a result also makes a horizontal scrollbar appear (see also: scrollbar-gutter)

After James Moylan’s death in December, we were reminded again of the Moylan Arrow, the little arrow telling you which side of your car has the little fuel door:

I started wondering: what would be the conceptual equivalent of this in software? My best guess would be iOS offering to fill the one-time code from a recent SMS:

This is what it has in common with the Moylan Arrow:

• everyone benefits from it
• it happens all the time
• it solves an actual little (but not too little) frustration
• it’s there at the right place at the right time
• it is relatively low-tech (it’s not an overdesigned or an overengineered solution)
• once you know it’s there, you will love it forever

Curtosis on Mastodon unearthed the original 2019 Twitter thread from one the creator of the iOS feature, Ricky Mondello (link to XCancel), which I‘m reproducing here:

The idea for Security Code AutoFill came out of a small group of software engineers working on what we thought was a much more ambitious project. It wasn’t a PM, it wasn’t just one person, and it wasn’t what we set out to do initially.

It started as a small side idea we had while designing something very different. We jotted it down, tabled it for weeks, and then picked it up after the “more ambitious” project wasn’t panning out. It was hard, but I’m so glad we changed focus.

Even with a gem of an idea, it was still just an idea. Ideas are obviously super important — they’re necessary, but not sufficient. Here, the end result came from the idea, teamwork, and execution.

Years later, I’m still so proud of the team for making this feature happen. The team combined expertise from several areas to ship magic that worked on day 1, while asking nothing of app and website developers, without giving anyone your text messages. This still inspires me!

To every one of the folks who made this happen, I’m still in awe. Y’all are the best. <3

Addendum: FAQs
- “SMS is bad.”
↪ I know.

- “MITM.”
↪ I know.

- “FIDO is better.”
↪ It’s complicated, but acknowledged; I totally get it.

- “Android did it first.”
↪ Nah. Details matter. Privacy matters. And clipboard != AutoFill.

- *negativity*
↪ Not now. :)

I asked others on social and here are some other contenders I liked:

• The indicator that alerts you of Caps Lock when typing passwords
• Underlined letters in Windows
• Return key as an equivalent of the default action in a dialog box
• Proportionally-sized scroll bar handles
• Showing the current folder at the prompt in the terminal
• The quick link to your post after you post it
• The preview of the outside of the frame from the wide angle lens in the Camera app
• Holding space to move your cursor in iOS
• iPod automatically pausing music when you unplug the headphone jack

You can check out Mastodon and Bluesky threads for more ideas, if you are interested.

One of the most potent themes in Stanisław Lem’s writing was the fallacy of first contact.

Lem argued that we are just not ready for an actual meeting with something truly alien. That the most open-minded of us are close-minded on a cosmic scale. That sci-fi made us think that aliens will look like human with prosthetics when good, and insect-like creatures when evil, but sci-fi needs to be self-constrained for all the same reasons; showing us something actually inhuman will immediately render it utterly incomprehensible.

He wrote about it in Eden, and Solaris, and The Invincible, and Fiasco. The last of these is a book I was once so angry at that I threw it at the wall.

It also happens to be my most favourite book, ever.

Anyway. This is a diagram for a single-button flashlight called Andúril 2 (larger version):

I saw it for the first time earlier this week. I was speechless. Maybe a little bit in awe. I know I’m supposed to hate this, but this feels so profoundly… alien, that I don’t know if anything I know applies here. I don’t want to judge it by the wrong set of rules. I want to understand the dividing lines between the UI and its explanation. I want to study it more.

Oh, and because I was curious too – this is the flashlight:

I have recently stumbled upon two websites that try to do something interesting and inspiring when it comes to showing scale.

John Wallace’s Tangible Media Connection’s initial appearance might not feel very well-crafted, but jump to any page (for example this one) and it’s astonishing how great the photos of the objects are.

They’re great not just on their own (it’s really hard to photograph metals and plastics!), but also consistent with each other when it comes to angle, style, and – most importantly – scale. I am not sure if I have ever seen on online museum do this before. It’s very well worth checking out.

The other example is Neal Agarwal’s recent Size of Life. The whole website is delightful, with subtle music and sound effects, great handling of keyboard navigation and swiping, and so on. And the way it resizes objects and uses transitions to always keep you oriented is something a lot of other interfaces, even for productivity apps, could learn from.

Of course, now I wonder what the first website would feel like with the user interface of the second.

The state of menus on Google’s search result page: all inconsistent, most ugly, ignoring UI mechanics learned decades ago (for example understanding the importance of diagonal movement or supporting mousedown-drag-mouseup in addition to just clicking), with easily triggered buggy states, bad animations, and even clicks falling through.

I wouldn’t be so angry, but I use – or at least see – these all the time. I wouldn’t be so angry if we hadn’t learned how to make GUI menus well 30 or so years ago.

I don’t want to pin it all on browser makers; if the designers and engineers cared above, there are ways to make great menus in custom JavaScript. But I wonder why the web tech didn’t evolve quicker to provide well-built and stylable and accessible primitives for this kind of stuff. I would love to understand more why that didn’t happen. Even scrollbars and sliders still feel unfinished on the web, and those are much easier than multi-level menus.

Also, Gemini:

Are the mechanics of menus on google search page working well?

In terms of technical execution, the mechanics of Google’s menus are a masterclass in Interaction Design (IxD). They are designed to feel “snappy” even on low-powered devices, using a blend of instant feedback and carefully timed animations.

Skynet would probably love Papyrus, too.

I stumbled upon this small page about friction by Carl Barenbrug. I found myself vehemently disagreeing with one example listed; I don’t think Undo Send is an example of friction, as to me it actually feels like the exact opposite (“Are you sure you want to send this email?” dialog box would be friction – just like the last example Barenbrug showed).

But this paused me in my tracks:

“Intentional pagination instead of infinite scrolling is progress with awareness.”

It made me realize that the only implementation of infinite scrolling I know is basically pretending the page has already been there the whole time… if it’s done well, and if you move slow enough, and if you don’t pay attention to the scrollbar, it really feels like the page goes on and on forever.

But… it doesn’t have to be that way. You could turn off the smoke or hide some of the mirrors. You could uncouple the gesture from what follows. You could add milestones (in the traditional sense of the word) after every X results. You could make the scrollbar react differently. Instead of frictionless scroll, you could force the user to bounce off of a bottom of the page in a similar vein as pull-to-refresh forces them to bounce off of its top.

I’m curious now. Did anyone ever experiment with infinite scrolling that feels… closer to pagination?

I love how this Byte magazine archive by Hector Dearman tries to do something different. It inspired me, and reminded me of the excitement of what Internet was supposed to be. I think we all wanted the web to feel more like this – fast, with infinite information right at your fingertips, the biggest library you could imagine at the comfort of your home.

I hope seeing everything in single, searchable place offers a unique perspective.

(The details of the zoomable UI are a bit wonky in practice, but one can imagine fixing all that.)

If you choose to remove the app names from the springboard, a small thing Apple could do would be to show the app name in the long-press menu here. Otherwise, I found it feels really easy to forget the name over time! (It would be a small riff on this disambiguation detail.)

I was surprised at this little thing that appeared in my Chrome Canary this morning.

It is rare to see an interface clean up after itself this way. This flew by quickly and wasn’t communicated very well, but I believe this changed my new tab page from this…

…to this:

Now, I said “surprised” and not “delighted” not just because the implementation felt a bit rough. I am also suspicious of the motivations, as Google’s sister iOS app played very fast and loose with this surface, literally moving the search bar from under my thumb in order to create room for features I would never use and could never remove. I suspect this is a preparation for something else that would take the place.

But until that day comes, this was an interesting gesture, and it’s really welcome to see a new tab harking back to the simplicity of Google from days past.

Daniel Kennett in A Lament For Aperture, The App We’ll Never Get Over Losing (also note an alt title in the URL):

Start spending time in the online photography sphere and you’ll start to notice a small but undeniable undercurrent of lament of its loss to this day. Find an article about Adobe hiking their subscription prices because they added AI for some reason, and amongst the complaining in the comments you’ll invariably find it: “I miss Aperture.”

Kennett goes deep into two specific details: the HUD-like UI that travels to the photo, and the technically impressive loupe. It’s worth checking it out just to reflect on the importance of execution; ostensibly those features exist in Adobe’s Lightroom (Aperture’s main competitor), Photos, etc. But Aperture designed them in particularly memorable and impressive ways.

Back in the early 2010s I used Aperture, too. I was rooting for it. I felt like it was designed, and Lightroom merely existed.

It reminded me of the 1990s when I felt the same about Netscape 4 over Internet Explorer 4. There was something about Netscape’s feel that appealed to me more. The way buttons were designed. The way they responded to clicks. The way pages loaded. All these little nuances. This was perhaps the first time I appreciated one app over another for things I didn’t know how to measure, or perhaps even describe.

Aperture vs. Lightroom feels like a similar story, because for all my appreciation for Aperture, I remember it being slower than Lightroom, and the noise reduction (much more important 10+ years ago) was worse, too. In a small way, it was a relief that Aperture was discontinued, because it saved me from a tricky choice: better designed vs. technically superior.

But: I miss Aperture, also. Maybe it would’ve caught up technically today and it would’ve been the best of both worlds. To this day, I use Lightroom (now Lightroom Classic). If it’s filled with UI quirks, it’s mostly bad ones. If there is beauty in it, I no longer know how to see it. It’s a tool in the most reductive sense of the word. My photos deserve more.

Also something I learned from Kennett:

“Shoebox” apps are apps that contain the content you use with them, as opposed to document-based apps which work with content you manage as a user. It’s an extremely common design nowadays, but less so back then — early pioneers of the shoebox app were iPhoto, iMovie, etc.

I added a table of contents UI to the most elaborate essays on my site, and then wrote about some of the design details and choices I made there. Let me know if this is an interesting case study! I tried to do something new here with tons of mini videos.

At the bottom, I will also be collecting other implementations I see that are interesting alternatives to my approach.

Let’s say you are in Reeder (an RSS reader for iOS), looking at the list of posts, and already from the title you know you don’t care, and you want to mark it as read.

You can tap to see it and then swipe back the moment it shows. This is the slow path.

There is a faster path. Reeder enables you to slide right or left on the item. You get nice haptic feedback, and many apps support this kind of an interaction.

But there is an even faster path.

You can tap to see it and immediately swipe back. Your thumb is already there on the left anyway, and the distance is a lot shorter now.

Like every advanced gesture this takes a bit of practice, but I noticed I started doing it instinctively, without even thinking.

This happening required two small design details: The original slide transition to be interruptible at any moment, and the app to support swatting/​draging the incoming item away even if my finger was nowhere near it. Both are clever, and both feel very welcome, because they enabled this emerging (to me) behaviour that made going through the list snappy without me even realizing.

This might be a good modus operandi: Think of the slow interaction. Think of its fast version. Then, think some more.

Nicely done, Reeder team. (Or, if this is a default iOS behaviour, nicely done, Apple!)

One of my favourite recently-noticed little patterns is this one thoughtful accelerant in iOS Photos.

If you want to add a photo to an album, you normally have to choose from a list of albums:

However, once you do that one time, a new menu option appears. It’s effectively “Add again quickly to the album you just chose” (Fiałka is the name of my cat):

That skips the album selection altogether. It’s always only just one album you used more recently, so it’s relatively simple… but so helpful. You often, after all, want to add more stuff to the same album, and it saves you choosing the same album over and over again.

This is great because it flattens the option space to zero options, which mirrors how we all think when we’re focused. It’s tunnel vision exactly when you want it.

I have always been a fan of both “repeat”-type actions and smart “recent”s, and consider them a truly underappreciated secret weapon. Those little savings really add up over time – in saved time, in less tedium, and in avoided mistakes. (Imagine not only having to choose the same album for 30th time in a row, but also… making a mistake doing that and tapping on a wrong one! Then the frustration very quickly compounds, as you have to recover from something that felt completely avoidable.)

I always respect designers of interfaces that invest in functions like these. There is also an anti-corollary to this, which is: if there’s only one option, consider not even asking. Slack seems to excel (derogatory) here:

The second one is somewhat defensible since it’s a settings dialog you enter at your own will, although the active “Re-generate answer” when I haven’t done anything (and nothing can be done) feels overbuilt.

But the first of these always appears on a way to other settings (like adding emoji), and it’s even worse than the Remember me? examples because it repeatedly stops you for absolutely no reason at all.

John Gruber (twice) on macOS Tahoe rounded corners (previously), with a nice bit of archeology:

It was, I’d argue, a small mistake for Apple to stop putting a visual affordance in the lower right corner of windows to show where to click to resize the window. It was a bigger mistake to change the scrollbars on MacOS to look and work like those on iOS — invisible, except while you’re actually scrolling (by default, that is — savvy Mac users keep them always visible). The removal of the resize indicator happened long ago, in Mac OS X 10.7 Lion, released in July 2011.

I can recall at least one place in macOS where you can still see the resize grabbers – it’s in column view in the Finder.

I still think sometimes of old Windows where all the 8 affordances for resizing were clearly visible. I know Windows 3.1 was generally kind of ugly, but I liked how they aligned with the title bar and the buttons:

By the way, don’t love Gruber’s “Dyehoe” thing in the title. Feels Trumpian.

A nice short analysis of window resizing in macOS Tahoe by Nobert Heger:

Since upgrading to macOS Tahoe, I’ve noticed that quite often my attempts to resize a window are failing. This never happened to me before in almost 40 years of using computers. So why all of a sudden?

I understand this might be the casualty of the absurdly large border radii in the new macOS.

The little video in the middle made me laugh:

(I do think there is room for gestures triggered “outside” a window, and we’ve seen rotation and some specific flavors of resizing or cropping work this way in drawing and design apps across the last few decades – but one has to be careful. Often, those are secondary and/or for power users.)

I still sometimes think of the miracle that is Undo Send in Gmail.

Michael Leggett announcing it in 2009:

This feature can’t pull back an email that’s already gone; it just holds your message for five seconds so you have a chance to hit the panic button. And don’t worry – if you close Gmail or your browser crashes in those few seconds, we’ll still send your message.

There’s so much cleverness hiding in here: recognizing that this particular flavour of l’esprit de l’escalier exists, shifting time from the past to the near future, the repurposing of the undo branding, the fallback if things go wrong.

There was, I imagine, even the challenge of having to forget about the previous version of this feature elsewhere, which were the awful emails with RECALL: in the title, which I think maybe only worked in Outlookk, if at all? (Everyone else suffered like green bubble people do today.) I don’t know. Sometimes the biggest hurdle to a great idea is blocking bad execution you already know from your head. On the other hand, sometimes someone else’s bad execution can be motivating.

I even think that not using ⌘Z for this was a clever idea. ⌘Z without text editing context/​focus can be really tricky. Do you remember when Safari had ⌘Z to bring back last closed tab before they came to their senses and used ⌘⇧T like Chrome?

It is sometimes harrowing when you want to click it Undo Send and just miss it – keyboard is more precise here – but not sure ⌘Z would register here. Even Esc would be tricky.

I miss when Gmail was in the “young and open to trying new things” phase.

I have been wondering the other day why aren’t there more mouse pointer museums and here’s one – Amiga Pointer Archive! (Amiga was a 16-bit home computer especially popular in Europe.)

Doesn’t work so well on mobile, but it’s fun on desktop. I recommend zooming the page to 200%.

An extremely bad click-through experience in Vimeo: a whole lot of redundant text, and a double captcha (luckily you only have to click on one).

Put the little captcha box in the middle of the screen and that’s it. Nothing else feels necessary. A great example of an insecure interface.

The first iPhone famously introduced the soft keyboard, which could change its shape depending on the need. Sometimes it would mean becoming a keypad (for numeric entries), and sometimes something subtler, like introducing a “.com” key to the bottom row, or adding a new column of keys and making the keys a bit more narrow for a few languages that need that.

Bear (the note-taking app) does something interesting: after a button press, it replaces the onscreen QWERTY keyboard with a “funpad” or a “function keypad” (like StreamDeck or Figma Creator Micro). This achieves a similar result to a scrolling toolbar above the keyboard (see: Apple Notes), but in a different way. I haven’t seen anything like this before, and I think it’s really clever and it has worked well for me in practice.

(It also cleverly closes itself upon some actions like introducing a divider, but stays put for bolding, indentation, etc.)

Was always so inspired by this pattern in Mac OS – showing me an extra bit of information only and exactly when it was needed:

I just saw a version of it in Nova, the text editor:

Yet another good post by Nikita Prokopov, continuing the theme of icons in Mac OS Tahoe (previously), going into more depth:

In my opinion, Apple took on an impossible task: to add an icon to every menu item. There are just not enough good metaphors to do something like that. ¶ But even if there were, the premise itself is questionable: if everything has an icon, it doesn’t mean users will find what they are looking for faster.

I always liked this kind of an exercise:

There’s a game I like to play to test the quality of the metaphor. Remove the labels and try to guess the meaning. Give it a try:

Also, this must hurt:

Microsoft used to know this.

Nick Heer at the excellent Pixel Envy, commenting on the above post, adds:

This is a gallery of elementary problems. None of this should have shipped if someone with power internally had a critical eye for consistency and detail. If Apple deems it necessary to retain the icons, though I am not sure why it would, it should be treating this post as one giant bug report.

Thank you to Scott and Ezra.

One of the frustrating patterns for me is a dialog box that doesn’t offer “skip it next time” option, or even just defaults to remembering.

My go-to examples? Apple’s Remote Desktop which always throws this thing up on connection:

And this in Photoshop upon saving a PNG file, which has been there forever:

I never change these options. These are flow-killers; trees have grown to maturity as I have spent collective hours in those dialogs over the years/​decades, even though they serve no purpose for me.

(The worst part might be if you forget this dialog waits, and move on to do other things, and the operation you thought was completed never actually finishes.)

Bear – beautiful, whimsical, delightful, but dry on the details. This window was on the screen for many minutes:

Obsidian (or, at least, the suggested Obsidian Apple Notes import plugin) – functional, informative, precise, but a bit on an uglier side:

As the meme goes, why not both?

A thoughful moment in Buttondown. Gmail’s truncation has been going on for decades, and I have no idea why they still do this. Even the overflow interface for a truncated email is awful – the rest of it doesn’t appear in situ, but it opens a new window that where you have to start from the top.

So it’s nice that Buttodown warns you about it.

In iOS, I like how cropping quietly snaps to things that look like borders, with gentle haptics, without announcing anything:

An extremely thoughtful moment in DaVinci Resolve. When you drop the first video clip into a new project, it suggests to update the settings of the entire project, on the correct assumption that the first media might set the tone of the whole thing.

“You can’t undo this action” is scary and kind of… untrue? But I’ve stopped reading by then. I press Enter and it saves me a trip to a complex project settings dialog box I always forget the location of.

From Scott Jenson’s 2021 post about Tesla 3 interface, this is so clever (emphasis mine):

Edward Tufte has this visual rule that 1+1=3: With a single line on the screen, you have just that single object, but adding a second line does something interesting, it adds a third ‘object’ on the screen, the negative space between the two. All good visual designers deeply understand this effect.

In UX design we have a cognitive equivalent. If you have two buttons, there is a third ‘object’ created: the decision a user must make on which button to tap.