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 as strong, but I feel a similar way about unnecessary 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.

On the most recent episode of The Talk Show podcast, this monologue from Jason Snell made me nod my head (the passage starts at 1:35:47):

[… Apple] decides to do a big feature. The circus comes to town, they build the feature, they launch it, they leave town, and that feature sits there.

And the problem is, there’s bugs, things are broken, and in Year Two, you’re like, “You’re going to fix all the things that were broken in the thing you shipped last year, right?” And in the last decade, I would say, a lot of times what happens is they just don’t. And if you’re lucky, they’ll fix it Year Three or Year Four, […] give it a polish.

The thing that troubles me most about Apple software quality in general is the feeling like they don’t have the people to own the thing that they launch. They build the thing that they launch, and then those people go off and do something else, and nobody is maintaining and improving the thing that’s there.

And whether it’s Time Machine, things that are often really system critical but that are super quirky, then they will do a brush up and you’ll be like “yay,” but… there’s still this bug, and then it’s “good luck, wait three more years.”

Or I think the one that we’re all thinking of this year is Screen Time, which they have a big revamp of. […] On one level, it’s great, but on another level, if you’ve talked to anybody who’s tried to use Screen Time, it’s broken. And so what they’re really doing here is trying to fix it, and we’ll see how they do. […]

The new features with problems is not a crime. It happens. The crime is: they never fix the problems.

And that’s the part that I would like to see Apple get better at: if you’re going to launch something, you got to maintain it. Sometimes I feel like Apple is willing to spend the money and time and effort to launch something, but then they’re not really willing to do anything other than walk away.

And I think that’s irresponsible. If you can’t stand by that feature, you shouldn’t launch it.

I think this is spot on, and said really well. Are you honest with yourself about resourcing and focus for right after the launch and then later on? Have you really thought about worst case and best case scenarios vis-à-vis bug reports, latency, user feedback, and craft/​quality however you define it? Have you actually started to make room for those outcomes ahead of time?

For me, an ongoing tension with Apple is Finder, so central to my (and I imagine many people’s?) use of a Mac, but rewritten at some point eons ago in a new framework that caused all sorts of problems, and then pretty much abandoned like a proverbial American city’s downtown. (I gave up listing stuff on this blog because it didn’t feel like fun, but I also see 100% of what Ilya Birman sees in his “Finder” section, many times every day.)

It’s not a story unique to Apple – I’ve seen many a designer and engineer quitting their jobs when an empty promise of a “fast follow” never materialized – but you’d expect them to do better here.

Adam Engst at TidBits did the lord’s work of transforming the “sweating details” slide from WWDC26’s opening keynote…

…into a nice, human-readable list of 264 items.

It’s an impressive list that garnered universally positive reactions, but I have one observation:

• “Fast” and variants thereof appear on this list 59 times.
• “Reliable” and similar words appear 22 times.

It’s true that everything could be faster and a whole many things should. Speed is paramount to great user experience. Speed is also more than just speed; there are nonlinear aspects when latency or delays cross invisible thresholds that can drastically change app usage for the better.

But in my experience, much more often the things that frustrate me about using Apple’s products are not issues of speed, but issues of reliability:

• I don’t need faster network connectivity in Finder, but I struggle with computers not appearing, a pizza cursor that occasionally just dies spinning, or randomly being thrown to the root of the networking volume.
• I don’t need AirDrop to be faster. I just want it to connect reliably every single time, give me consistent and understandable UI feedback, and stop forgetting I’m not just “everyone” when sending stuff to myself.
• I don’t need Messages to be faster. I need them to just, you know, not haphazardly stop syncing across computers on occasion.
• We just talked about undo being profoundly broken, and I have many more examples like that. (Often from apps like Finder and Settings that are not on the list at all.)

It’s not just me. 15 out of 17 bugs listed on the Bugs Apple Loves site are about reliability. None seem to be directly about speed, although more on that in a second. Or, here’s a recent list from Ilya Birman – different issues, but a similar shape.

I’m going to say it: Speed is an easier problem. Not easier in an engineering sense; I’ve seen an engineer try to carve ten milliseconds out a busy computer’s schedule, and in that moment, one must truly imagine Sisyphus happy. But it’s easier as a problem: it often comes with a lot of pre-built telemetry, plus a clear goal of “here’s Xms and X now needs to be smaller.”

Reliability is much harder, more difficult to debug, reproduce, agree on metrics for, even find ownership of – just generally fuzzy around the edges, and less obviously thrilling as a challenge. It needs more champions and structures.

I know a simple marketing slide is not meant to be an accurate representation of Apple’s efforts. I wasn’t at WWDC so perhaps the vibe in the room was different than what this slide represents. Yet, the slide exists and I’m allowed to judge it.

(And yeah, I know in some cases speed and reliability are correlated. After all, if you have a timeout, making something finish faster and do so before the timeout will turn it from unreliable to reliable. But hey, I wasn’t the one choosing the words on the slide.)

I just… I would be a lot more excited if the 3:1 ratio of fast-to-reliable on that slide went the other way.

• [ ] Typewriters
• [ ] fujitsu standalone
• [ ] canons cat add
• [ ] Find the old file catalog
• [ ] move to spreadsheet

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:

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.

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

I feel macOS these days starts feeling like Windows in the 1990s where occasionally some core component of it breaks, and a reboot is necessary to restore it to full functionality again.

But even with that in mind: this happened literally right after the reboot, with nothing much happening and no other signs of the system in distress.

It’s hard for me to even understand what would make this kind of thing pop up. Trash feels like one of the core tenets of a GUI – like undo, or copy/​paste, or windows gaining focus. You don’t expect it to just… stop working, especially with a circular error message like the above.

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?

If you plug in a CD drive (he said with a straight face in the lord’s year 2026), and then eject too soon, the system offers this dialog, which allows you to say: Eject whenever you’re done with whatever you have to do.

But more modern media, like SSD drives, don’t show that window. The best case scenario is that you get a dialog box like the 1990s never ended:

It gets worse. Often, you get zero help in identifying what the “programs” actually are. (The word on the street is that it might be stuff like Spotlight indexing, which you can’t really control.)

More often than not I just click Force Eject or jank the drive cable out, which feels really unpleasant. I would guess many people do the same.

So at this point we are two steps worse than the original CD experience, which… wasn’t even that great! A pretty clear improvement on this already exists elsewhere in macOS, and could be reused here – “hey, you don’t have to do anything, just give me a second while I finish up here.”

(Can’t help but notice the discrepancy of visual styles of these windows, and even the inconsistency between calling things “applications” vs. “programs.”)

Reported to Apple as FB21787458.

Fun little story by Bruce Horn on folklore.org about the original Mac and how modes are sometimes good:

We went to quite a few stores in the week or so after the introduction, and found that, without exception, every Mac’s floppy disk had a garbage name! They were all named something like ”;lkakl;rt;klgjh”, as if someone had just randomly typed characters to see what would happen. Which is exactly what they did.

In the Finder, the startup disk would appear on the desktop, in the top-right corner, ready to be opened. The Finder would initially select it; once selected, typing would replace the current name, following the modeless interaction model that I had learned in the Smalltalk group from Larry Tesler. This meant that whatever anyone typed when they first came up to the Macintosh would end up renaming the disk.

On the early Mac, just typing with any item selected renamed it, which caused all sorts of trouble.

The eventual solution for renaming that survives until today was: click to select and then click again to rename… but don’t click too fast, because that’s double-clicking, and that means something else. Windows, starting in Windows 95, did something similar, but also put rename under F2 – so at least you didn’t ever have to wait.

I liked the emergent behaviour from some graphic apps which put rename under ⌘R. It’s not that hard to make Finder work that way – see below – but I have always been curious why Mac or Windows didn’t steal this solution.

(Added later: People reminded me that of course Enter also renames, and does so immediately. I wonder why it slipped my mind in this context – possibly because in any other list or similar place, Enter would be the equivalent to opening? Maybe I’m discovering in slow motion how unusual Finder can be in its details compared to conventions we established after.)

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.

This appeared when trying to delete (even when trying to Delete Immediately, skipping the trash altogether):

Same thing right after, when trying to tag some existing items, for which I don’t imagine any new space should be necessary:

Also, why are these dialogs so different?

I feel like not so long ago there were literal books making fun of bad dialogs like these.

Reported to Apple as FB21509633.

I am starting to collect all the problems I routinely find in Finder. I can think of ~15 off the top of my head; maybe this will turn into an essay of sorts. I hope this isn’t too boring for you.

Sometimes Finder takes a really long time to update the list of files after something changed it.

All my screenshots go to a specific folder. In these videos, you can see me taking screenshots with ⌘⇧4 while looking at the folder where they arrive.

The first one is fast – just as fast as it should be. The ones after that arrive with a few seconds of delay that feels completely random.

But this is nothing compared to this, just a few minutes later, where the delay was over 50 seconds. Nothing changed. The computer was not under load.

This happens routinely and feels completely random.

There is also, as far as I know, no way to force a re-sync with a keystroke or a button or a pull-down gesture, which could be at least a way to manually alleviate the symptom (if not the cause).

Hearing what others told me and based on prior experiences, I don’t have high hopes for any of this, but I want to be a good citizen. So I am filing bugs with Apple for all of these. I do not believe I can link to this directly, but the report I filed for this one is FB21444299.