Go to Settings > Accessibility > Zoom, and then turn on “Use scroll gesture with modifier keys to zoom.”

Then, at any moment, you can hold Control and swipe with two fingers (or use a scroll wheel) up or down to zoom the entire screen.

I’d also recommend turning off “Smooth images” under “Advanced…” so you see individual pixels better:

Over the years, I found this feature very useful to inspect various misalignments, to check visual details, and occasionally simply to read text that’s too small.

Compared to other ways of zooming, this one has three benefits:

• it’s extremely motor-memory friendly and so my fingers do it without me even thinking
• it’s a system-wide thing, so it will work everywhere
• it’s safe, because it’s something that I call a peek gesture

Peek gestures are fast, but the main benefit is that they’re safe. In some apps, pressing ⌘+ a few times and then ⌘– the matching amount of times doesn’t guarantee you will end up back in the same situation. The window size might change, the scroll position might move, the cursor might end up in a different place. In contrast, the Ctrl gesture is 100% deterministic and reversible; it will always work the same and never mess anything up.

I treasure peek gestures in general. Here are a few other useful (and/or inspiring?) ones:

• previewing things in Finder by pressing (or, for power users, holding) the spacebar

• using ⌘⇧4 with the intention not to take a screenshot, but just to (roughly) measure a distance between two objects, and then pressing Esc to abort

• in tools like Figma and Sketch, using Ctrl+C just to quickly verify the color, and pressing Esc to cancel (rather than clicking to put the color into the clipboard or apply it elsewhere)

• I also previously mentioned Chrome typeahead and macOS menus that had a similar property

The story about the original Macintosh’s built-in font set being named after “world-class cities” is well known and documented by Susan Kare on the Folklore site:

The first Macintosh font was designed to be a bold system font with no jagged diagonals, and was originally called “Elefont”. There were going to be lots of fonts, so we were looking for a set of attractive, related names. Andy Hertzfeld and I had met in high school in suburban Philadelphia, so we started naming the other fonts after stops on the Paoli Local commuter train: Overbrook, Merion, Ardmore, and Rosemont. (Ransom was the only one that broke that convention; it was a font of mismatched letters intended to evoke messages from kidnapers made from cut-out letters).

One day Steve Jobs stopped by the software group, as he often did at the end of the day. He frowned as he looked at the font names on a menu. “What are those names?”, he asked, and we explained about the Paoli Local.

“Well”, he said, “cities are OK, but not little cities that nobody’s ever heard of. They ought to be WORLD CLASS cities!”

So that is how Chicago (Elefont), New York, Geneva, London, San Francisco (Ransom), Toronto, and Venice […] got their names.

If you check out the actual Philly stops and witness all their provinciality, you can understand what Jobs was after:

Go to first Macintosh via Infinite Mac, open Infinite HD and MacWrite within, and you can examine the nine eventual fonts in their pixellated, cosmopolitan glory:

The list goes in this order: New York, Geneva, Toronto, Monaco, Chicago, Venice, London, Athens, San Francisco.

But: How about some hard evidence for the original anecdote? Turns out, the March 1984 issue of Popular Computing used pre-release Mac software and printed a screenshot of the names rejected by Jobs:

Since on the facing page we see the output in the same order, coming up with the correct mapping is not hard:

• Cursive → Venice
• Old English → London
• City → Athens
• Ransom → San Francisco
• Overbrook → Toronto
• System → Chicago
• Rosemont → New York
• Ardmore → Geneva
• Merion → Monaco

One has to admire the final order of the Mac fonts that went from dependable and utilitarian at the top, to progressively more weird; this earlier list is all over the place.

In later releases of Mac OS, three other world-city fonts – Boston, Los Angeles, and Cairo – joined the party, so let’s show them here for completeness’s sake:

(Cairo is the classic icon font and in a way a predecessor of modern emoji, with inside jokes like Clarus The Dogcow.)

But that’s not the end of the story of the original Mac fonts. Let’s get back to 1983. On yet another page of the magazine, we see this list from MacPaint:

You can tell this screenshot is even older than the previous one, because it is itself set in an earlier version of Chicago, with a single-storey lowercase “a,” and many letterforms being works in progress. (I talked about the history of Chicago in my 2024 talk about pixel fonts.)

And it is old enough that this isn’t just interim names for surviving fonts – it’s actually quite a few old fonts that didn’t make it to the release day.

Unfortunately, this particular version of Macintosh software remains unknown, but one similar pre-release version of the first Mac software leaked, and so we can take a look at some of these fonts, too:

(You can download a lot of these fonts thanks to the hard work of John Duncan. They are still bitmap fonts and might not work in all the places in modern macOS, but they seem to work in TextEdit at least.)

Here’s what I learned from looking at this list:

• You can definitely see how unpolished some of these fonts are in terms of spacing, letterforms, and available sizes – kudos to the team for holding a high quality bar even though there was little precedent for proportional fonts on home computers at that time.

• Even the fonts that shipped – London (née Old English), Venice (née Cursive), and Chicago (née System) – have had their letterforms tweaked and improved.

• Chicago is not named Elefont, but simply System. Had the System name persisted, this Medium snafu from 2015 would have been even more hilarious.

• The name of the monospaced Elite font is likely inspired by one of the two classic sizes of typewriter fonts: pica (larger) and elite (smaller).

• Cream came all the way from Xerox’s Smalltalk and was the original system font for Macintosh-in-progress, before Susan Kare created Elefont/​Chicago.

• PaintFont was a symbol/​icon font, but distinct from Cairo and emoji in that it seems it was meant to be used only by the app to draw its interface. (Today, SF Symbols serve a similar purpose.)

• Apple originally planned to use Times Roman and Helvetica, but this hasn’t happened presumably because of licensing issues. Only years later, the proper Times and Helvetica fonts were introduced. Here’s a comparison:

But the most interesting thing I haven’t noticed before are two fonts called “Marie Osmond” and “Patti.”

I am reaching outside of my well of knowledge here, but from context clues I’ll assume the latter means Patti LaBelle. And so, pulling on that thread, it’s kind of cool to imagine an alternate universe where the original Mac fonts are neither suburban Philly stations, nor well known cities, but something like this:

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

Nice, clear, simple copy in ClarisWorks from 1997:

No “Maybe later.” No “Not now.” Thirteen characters. Now, Later, Never.

(Can’t help but notice that Esc and ⌘. – the classic Mac’s equivalent of Esc – still map to Later, however. Also, this breaks the rule of button copy being fully comprehensible without having to read the surrounding strings first, perhaps most well-known as the “avoid «click here»” rule. Never Register/​Register Later/​Register Now would solve that problem, but wouldn’t look so neat.)

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.

This from a blog post by my friend Glenn Fleishman about audio/​video settings in macOS just made me laugh:

It’s doubly funny if you are aware of Fleishman’s extensive experience in printing.

Also, this:

I guess this is how I keep humble. Despite decades of using a Mac, I can still miss a Video menu in an audio app.

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.

I was embarrassed for Apple when I saw the recent bug fix for columns introduce a new bug, explained in this post by Jeff Johnson:

Without the path bar, the columns are now taller, but the vertical scrollers remain the same height as before, leaving vertical gaps, a ridiculous amount of space between the bottom of the scrollers and the bottom of the columns, looking silly and amateurish.

It’s impossible to talk about craft without talking about embarrassment, and pride, and shame, and lust, and a lot of other words – all tricky to describe, all fluffy. So, I tried to interrogate my feelings.

First, it was embarrassing that it broke. I’ve been there: you build a complex system, and forget about some lesser-known state. That’s why it’s important to invest in whatever it takes to shine a light on those states: quality assurance, automatic screenshotting, tests, and so on. Sometimes it’s simple hacks – like half of your team having scrollbars visible. And when you notice a bug, you try not to just fix it, but to rebuild it to be stronger (“leave the campsite in a better place you found it”) – be it by fixing the cause and not just the symptom, adding unit tests, changing practices, and so on.

But it also felt embarrassing how it broke. It feels clear there’s some manual calculation going on somewhere, and someone forgot to add this new change to it. One of the tricks I learned over time is that a well-designed system designs itself, but it takes effort and imagination to make a system resilient in this way. Here, if there was some abstraction of “adding stuff to the bottom,” then you wouldn’t have to worry about adding extra math. The system would take care of itself in many of these corner cases you will forget about.

I don’t want to shame (see, that word again!) individual people at Apple because I don’t know if it’s the lack of talent, or the whole system being wired in a way that doesn’t reward forward thinking or the kind of invisible work that needs to happen in those spaces. But the embarrassment should be there – if it doesn’t exist inside Apple, then that’s perhaps the sign of a real problem.

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?

Everybody who routinely takes screenshots on a Mac knows very well the motor memory heaven and hell that are the screenshotting shortcuts: ⌘⇧3 to grab the whole screen, ⌘⇧4 to grab part of it, hold ⌃ ahead of time to put the result in the clipboard, press space at the right moment to select a window, hold ⌥ at a different time to remove a shadow, and so on. (Yes, there’s more.)

It’s strange to talk about those shortcuts, because the world is divided into two groups: people who have never used any of these because they are the scariest shortcuts that induce RSI if you just think about them, and people who have used them for so long that their fingers do all the work. Either group would struggle with writing the above paragraph – as did I, needing to watch my hands first, and then take notes.

But: why do the shortcuts start with 3? After all, ⌘⇧1 and ⌘⇧2 don’t seem to do anything.

That wasn’t always the case. Turns out that once upon a time Apple was trying to create a larger universe of nerdy shortcuts for your Mac. The effort is so old – they were introduced in 1986 – that ⌘⇧1 was added as a quick shortcut to… eject the floppy disk. And, since you could also have an external floppy drive, ⌘⇧2 was assigned to eject that, and the shortcuts for screenshots followed in sequence: ⌘⇧3 to save the screen, and ⌘⇧4 to send it straight to your printer. (Even then, there was already Caps Lock thrown into the mix, too, switching between the entire screen and the current window.)

Early BASIC programmers knew to separate their line numbers by 10 because there will always be a line you want to insert in between, but keyboard shortcut designers do not have that luxury.

And so the nice system backfired immediately. Some Macs started coming with two built-in floppy drives, but still allowed you to plug in an external one. What would you press to eject that?

Well, of course it had to be ⌘⇧0, since ⌘⇧3 was already taken.

(In an absolutely delicious bit of rhyming, the 0 key itself is on the “wrong” side of most keyboards – except Hungarian – because it was added to keyboards before the 1 key was! It felt more natural to put it after 9 than right before 2.)

Things were quiet for a while. Floppies disappeared over time. Only in 2018, Apple evolved the old Grab app that it inherited from NeXT into a Screenshot app, and assigned it a new shortcut, ⌘⇧5. That was a nice improvement – video recording, a very helpful timer, a few smaller options, and a bit of a GUI thrown atop for convenience.

There are a bunch of system and change management lessons in here, but I want to talk about something else I just learned about.

Acorn 8, a graphic app, has a delightful screenshotting feature parked under ⌘⇧7 that does something incredible: it takes a screenshot, but does so in a way where windows are separate layers, grouped by app. It’s amazing; you can re-compose stuff afterwards, reveal covered stuff, remove windows, even change the wallpaper. A mouse cursor arrives too in its own tiny layer, like a cherry on top.

I’m sharing this both because I gather people who read this blog take a lot of screenshots – but also because this is software craft. I know “delightful” is (mis—? ab—?)used to refer to beautiful but slow transitions, and cute but distracting UI copy, but this is the stuff of true delight: using newly abundant technology to actually do something useful, and rewrite the rules of something that hasn’t been touched for ages, in a way that feels magical. There is still room for improvement – notably, you cannot just fire and forget a screenshot straight into your filesystem – but I find this kind of stuff inspiring.

I also know what you’re thinking: hey, what happened to ⌘⇧6? I’m not going to tell you. It’s probably not that hard to google it, but maybe you’ll enjoy trying to guess like I did. What was a feature of Macs that arrived after 2018 that Apple would want you to forget about even more so than the floppy disks?

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)

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

A great post duet from Craig Hockenberry that flew by on Mastodon and clarified something for me:

[For] the extra work to create a custom SF Symbol, our experience is 8-10 hours per symbol. This is also an expert level task: lots of knowledge on how SVG control points work and how to maintain compatibility across different sizes and weights.

If you’re paying a designer to do this, the cost will be somewhere in the $1000-2000 range. For Apple this is an easy cost to absorb, for smaller developers it’s a big “nope”.

And, of course in the Mac menubar (and now iPadOS) you need a lot of them.

Another subtle example of how out of touch Apple Design is with day-to-day development.

So not only is the overiconification of menus in macOS and iPadOS a bad idea, but it’s also expensive. You could make an argument that it would push people into reusing SF Symbols – ergo “consistency” – but that would land better if we haven’t already seen even Apple is struggling with that on their own (previously, previously).

Savage from heliographe.studio on Threads (via Daring Fireball):

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

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.

h/t my friends Scott and Ezra.

When you accidentally rename a file to a name that already exists, Finder tells you about it, and then just dumps you out of rename, so you have to enter rename mode again and type the desired name.

This feels like such a 1990s way of doing things: throwing a dialog box and washing your hands away from the responsibility to make things smoother and more fluid.

It’s not hard to imagine a better solution that returns you to rename mode and keeps the name you entered so you can refine it, or even something that eschews the dialog box altogether, and does something simpler like a password shake or a little callout.

Reported to Apple as FB21509667.

A thoughtful look at macOS 26’s application of Liquid Glass by Howard Oakley:

I’m sure that, in the right place and time, transparency effects of Liquid Glass can be visually pleasing. Not only is this the wrong time and place, but those with visual impairment can no longer remove or even reduce these effects, as the Reduce Transparency control in Accessibility settings no longer reduces transparency in any useful way.

I have heard so many bad things about Liquid Glass specifically on Tahoe that I’m holding on and not updating at this time. Something tells me I might have to skip a version or two altogether, which feels unprecedented in the modern Apple times.

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.

Forgot about this cute little story:

It used to be that when you dragged an item off the Dock and dropped it, the icon would disappear in a puff of smoke and make a satisfying noise. The animation was strangely primitive against the backdrop of the slick user interface of what used to called Mac OS X.

I too wondered why that animation was weirdly amateurish, almost like a placeholder. Well,

One of the most talented engineers on the team took out a piece of paper. I wish I could say it was a napkin to make the story better. ¶ On the piece of paper, he drew a series of five frames. The intention of the designer was that these drawings would stoke further discussion. That it would get cleaned up and refined later. ¶ But that never happened. It shipped as is. And the rest is history.

Also when looking it up, I found a mention of a fascinating bug that exposed the origin of the animation as a sprite.

Scathing from John Gruber:

I think the fact that Liquid Glass is worse on MacOS than it is on iOS is not just a factor of iOS being Apple’s most popular, most profitable, most important platform — and thus garnering more of Apple’s internal attention. I think it’s also about the fact that the Mac interface, with multiple windows, bigger displays, and more complexity, demands more nuanced, more expert, interaction design skills. Things like depth, layering, and unambiguous indications of input focus are important aspects of any platform. But they’re more important on the platform which, by design, shoulders more complexity.

A great read – harsh, but deserved. It’s good to punch up. I don’t have a lot of context on Alan Dye, but the parts that resonated the most was appreciation of the craft of interface and interaction design for complex things. iOS has had occasional sprinklings of great interaction design, especially in its physics-based gestures that blossomed since iPhone X. macOS feels abandoned in this regard, with even hard-won victories like fast Finder and great user preferences deteriorating.