Apple might have undone the macOS Tahoe menu icons decision, but this wasn’t the only contentious iconography issue in their ecosystem.

On his blog, Jim Nielsen writes how Apple filed away so much expression by forcing rigid icon bureaucracy in macOS. Nielsen focuses mostly on distinctiveness; previously, you could make the icon unique by its general shape or the shape of its contents, but one of these two levers has now been taken away:

This over-emphasis on “systems” design seems endemic to modern software. Systems prescribe rules because they are the easiest attributes to document, enforce, and automate — “All icons must use this shape, this lighting, this stroke.” Excellence, by contrast, is harder to systematize. It requires judgment, taste, care, experience, and a sensitivity to context — all in service of meaning and purpose, not superficial similarity.

However, one also can’t help but notice how ugly and amateurish the Creator Studio icons are, so it all feels absolutely like a net negative – the new system took something away and the proposed replacement feels low quality:

Elsewhere, on Rogue Amoeba’s blog, Paul Kafasis straight up asks Apple to undo the 2025 decision to contain macOS icons inside squircles:

Apple’s prohibition on shapes is a step backward for both usability and creativity in app icons. Icons are now harder to distinguish because they’re no longer allowed to be distinctive. But there’s no technical reason for it. Apple could, and should, once again allow icons to take on a wide variety of shapes.

Both these prompted me to think a bit of Apple’s app iconography as a system.

Let’s start with iOS:

• I believe the rigid squircle shape of app icons starting with the first iPhone was to make them look like a grid of buttons, and also to establish apps as a new primitive, particularly with the subsequent arrival of the App Store. (Similarly how over time “a face in a circle” became recognizable as a “personal avatar,” a user proxy primitive.)
• Soon, the rigid shape also helped when custom Springboard wallpapers arrived in 2010 – it reduced the likelihood of apps blending with the background.

• Recently, a new option has been added to remove names of apps, which is another way to disambiguate them.

• Also recently, Apple’s generally unpleasant-looking theming options (color tinting and glassification) reduced color coding as a way to recognize a particular icon.

At the same time, iOS is still highly spatial. Most apps have a specific physical place on a specific page of the Springboard, or inside a specific folder. I believe that this helps a lot even if shape coding, color coding, and name disambiguation are failing or turned off to begin with.

Now, for MacOS:

• The original Mac OS X followed in the footsteps of the classic Mac OS and allowed arbitrary shapes, allowing for more flexible shape coding, although with some guidance on angles and styling:

• However, more recently, the iOS squircle shape has been first strongly suggested (in 2020) and then rigidly enforced (in 2025) for macOS as well.

But then, the usage of app icons in macOS is different than in iOS.

First of all, macOS isn’t nearly as spatial as it used to be, and I would say not as spatial as iOS. Even Dock is more malleable compared to the memory palace rigidity of the Springboard, and its overflow section with suggestions and hand-off is very fluid. ⌘Tab is completely non-spatial and just like the Dock doesn’t upfront identify apps by their names. App icons also appear in more fluid contexts like Spotlight, Finder, and the right side of the menubar (I know iOS has some of those as well, but I would imagine they’re getting much less use overall). This all increases the pressure on icons to be easily distinguishable.

At the same time, there are fewer issues with custom backgrounds on macOS. Most icon surfaces have opaque backgrounds and while you can keep your apps on the desktop or put backgrounds in Finder windows, I don’t think that’s very common.

I’m probably missing some other aspects, but this would be my summary of where we’re at:

• Apple has not done a good job shepherding their app iconography system. The system feels too rigid, and some of its ostensible benefits (dark mode, color tinting, glassification) have been executed poorly. You could imagine a better tinting system that doesn’t feel like a cheap CSS filter applied to the icon, or (my dream!) a way to tint individual app icons. I personally love when apps – here Raindrop, Bear, and Retro – give you a lot of icon options in various colors, so I can invest in color coding:

• People’s trust in Apple’s skillset has deteriorated after the unveiling of horrendous icon redesigns in 2025’s Tahoe, and more recently in the abovementioned Creator Studio (the 2026 updates are nice, but very minor). This is in some contrast with other controversial visually-motivated changes appearing at the same time. Say what you want about Liquid Glass, but there are moments it looks absolutely gorgeous (see the video below for perhaps my favourite Liquid Glass surface). Forced menu icons felt similar: embarrassingly naïve as a system, but with icons themselves executed well (which you can still appreciate when perusing SF Symbols). But the app icon changes seem to have been assigned to the team that delivered on neither good visual craft, nor good systems thinking.

• I think it’s fair to look at Creator Studio specifically, and fear Apple is following in Microsoft’s and especially Adobe’s unforgivable footsteps in prioritizing abstract corporate identity goals over both functional and visual aspects of app iconography. Adobe’s product icons used to be beautiful and distinct before they got all shoved into the same “uppercase + lowercase letter” framework that became a canonical example of a system that took something away from the user but didn’t really give anything in return:

• I also feel this feeds right into another fear of Apple’s actions steamrolling over particularly indie app developers where being able to express one’s identity via the app icon feels much more important than it would be for a huge company.
• I don’t see Apple abandoning their stance on the rigid, distinctive app icon squircle shape. It’s possible that iOS apps will start appearing on touchscreen Macs outside of screen mirroring. Even without that, it just simplifies things for them, even if the jobs for macOS app icons are not the same as those for iOS app icons.
• At the same time, I could see Apple allowing the app icons to stick out of the basic squircle shape, like some macOS apps did in between 2020 and 2025; I believe it would even be possible to detect programmatically if the basic squircle shape is still there in the background. This would improve shape coding, and give icon designers some clearly much-desired flexibility. The icons below still register as squircles to me – why not allow this as an option? (For both macOS and iOS.)

• I wish Apple standardized app icon changing UI on iOS. Right now, each app offers their own interface in a different place – you could see that above – and rarely links to that place from the Springboard’s long-press menu. But imagine if you could nicely change app icons in situ in the same flow when you’re customizing the Springboard itself! (And then, the same for Dock and macOS.)
• I think it would also be a nice gesture to allow to rename iOS Springboard apps to whatever you want the same way you can rename folders, to give some users an opportunity to disambiguate by that if everything else fails.

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.

In iPhone’s accessibility settings you can choose the allowed speed of double- and triple-clicks on its side button (why is it important? we talked about it once), and the interface does something nice – after you make your choice, it shows the expected speed in the same place a sort of a preview:

To be honest with you, I was surprised that I liked it. This feels like it’d be a perfect example of cheapness, especially given the iPhone has this delightful animation that could be reused here:

But, I don’t know. Somehow, this one feels like it’d be too complicated. Maybe cheap is okay if one cannot think of a better “bespoke” interface?

Cheap here also has an added benefit of reusing existing patterns, which might feel nicer in the more utilitarian surroundings of settings.

But my favourite thing that elevated this was that with each visual blink there is also an accompanying haptic buzz. I think this is really clever. A haptic buzz is much “closer” to your fingers than onscreen blinking, and can help you feel the speed rather than just see it.

Unfortunately, the same clever preview is not present here in the otherwise very similar AirPods menu…

…and I also found myself wondering what would it take for it to make its way here as well:

This is a really nice set of transitions when pinching in and out in Photos in iOS 26.

This is trickier than it seems, because it’s not just a linear zoom (like it would be in Maps or Sketch, for example). It’s a zoom and reflow – from 3 items to 1 item per column – which makes things a lot more complicated.

Here are a few nice details about this transition:

• It reacts to your fingers rather than being a rigid transition with a fixed duration.
• It always prioritizes the photo you’re pinching in and out, assuming that’s where you look.
• It smoothly transitions the aspect ratio (from always square when the items are smaller, to native when items are bigger).
• It crossfades the other photos. Cross-fade is the “cheap” answer for transitions, but here it feels appropriate, as it happens in the periphery – actually trying to move the other items linearly between their respective positions would feel unpleasant and distracting.
• In contrast to the other transitions, these crossfades are not fully tied to fingers, meaning you cannot stop in the middle of a crossfade.

Nikita Prokopov on his blog published other examples of problematic transitions, and it seems most of them are struggle in the same way, as transitions that cannot simply be linear. The above transition in iOS shows it’s possible to do it well if you care.

And it’s not just about smoothness or nice feelings. Prokopov:

[…] Desynchronization can lead to a lot of confusion. For example, in Photos, when switching between Crop and Adjust mode, picture snaps into place immediately but the crop border is animated.

This creates a false feeling that something subtly changes when you switch between modes. And you know what? I don’t want my UI to give me false feelings. I want it to be a precise instrument, not an animated toy.

The above iOS transition feels very precise to me.

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

John Gruber on Daring Fireball:

Perhaps the worst UI crime in MacOS 26 Tahoe was the inexplicable decision to add inscrutable, distracting icons next to every item in the menu bar. You will recall Jim Nielsen writing about it, rightly describing it as exactly the sort of thing that Mac users look down upon in platforms like Google Docs and Windows. You will also recall Nikita “Tonsky” Prokopov writing about it, illustrating that the bad idea wasn’t even implemented well, with different Apple apps using entirely different icons for the same menu items. […]

Top third-party developers rightly rejected the design, adopting open source code from Brent Simmons to disable the default “icons in all standard menu items” behavior. […]

Wonderful news in MacOS 27 Golden Gate: the icons are gone. It’s like Tahoe’s menu item icons never happened.

Kudos to Nielsen and Prokopov for pushing on this and explaining the problem so well. This wasn’t about ugly icons. This was about improper use and misunderstanding of iconography.

(Also may I try to manifest something:) Looking forward to reading the oral history of macOS 26 Tahoe and Liquid Glass some time in the 2030s!

John Gruber at Daring Fireball talks about a problem in SwiftUI-based macOS and iOS apps where undo is completely broken during text editing:

Basic stuff that’s worked reliably for decades — some things that heretofore had worked forever — are dangerously broken. If you’re running MacOS 26 Tahoe, open Journal and make a new dummy entry. Type something like “The quick brown fox.” Then double-click on the word “brown” and delete it. Now invoke Undo.

What you expect is for the word “brown” to reappear. What happens is ... the whole sentence disappears. Gone. Invoke Redo and you only get back to “The quick fox.” The word “brown” is just gone forever. It’s nowhere in the Undo stack. That’s just profoundly fucked up.

I couldn’t believe it, but I reproduced it myself just now on my phone (my backup Tahoe-running Mac is in a closet not responding to pings, I am now assuming out of embarrassment):

Gruber adds:

Apple’s developer message used to be that it was not just easy to develop apps for their platforms, but that it was easy to develop good idiomatically native apps. You got the correct complex behavior — for things like Undo/​Redo — out of the box. That’s still true for AppKit and UIKit, but it’s never been true for SwiftUI, and SwiftUI is now seven years old. That’s too long for any excuses to hold water.

I don’t want to automatically assume that this problem has existed for seven years (vs. being a more recent deterioration), and I don’t know exactly which native apps use SwiftUI, but either way, this reflects very poorly on Apple.

Software engineering typically has some categories of bugs and failures that result in immediate action – a night shift, a war room, “sevs,” and so on. Those are, in my experience, things like:

• the app crashes,
• the site doesn’t load,
• there is data loss.

Depending on what you work on, this list will also likely include security problems, regulatory considerations, privacy-leaking bugs, and so on. In a more mature organization, these are all well documented, but even in early startups there is some shared understanding that some bugs are bigger than life and they take immense priority over pretty much anything else.

At any company, a version of this list needs to exist for front-end and user-experience problems, and undo should be on top of that list. If you break undo, you drop what you’re doing to fix it.

Nick Heer’s analysis of Apple’s Pages interface over time is a nice counterpart to the recent post about Sinofsky doing the same for the early years of Microsoft Office. Here is the key comparison, 2011–2025:

I’ll let you read the whole excellent analysis and Heer poking at the notion of “content over chrome” which feels dogmatically attractive, but needs deeper thinking which usually doesn’t follow.

The interesting thing to me about that last screenshot above is that the team didn’t want a toolbar separated from content – and yet, they walked themselves into recreating a de facto toolbar anyway, just uglier and with more problems. (Just like designers who use all-white for complex surfaces, and arrive at visual hierarchy challenges that now require more work.)

We’re a few hours away from WWDC. I don’t imagine we will see any direct response to the criticism of Liquid Glass as Apple doesn’t work that way, but it will be interesting to spot any indirect signs of reactions or course corrections.

★★★★☆ (as a book)
★★★☆☆ (for the purposes of this blog)

There are as many books about Steve Jobs as there were Quadra models, but they focus mostly on two phases:

• 1955–1985 – Steve Jobs befriending Wozniak, the early days of Apple, Lisa, and the Mac
• 1997–2011 – Steve Jobs’s “second act” at Apple, and the creation of the iMac, iPod, iPhone, and so on

Steve Jobs in Exile by Geoffrey Cain is a just-released, rare volume that focuses on the “in-between years” – starting with Steve Jobs founding NeXT and Pixar after his Apple ouster, and ending with him coming back to Apple under the absolutely strangest of circumstances. It’s a doubly interesting phase, both because we see Jobs maturing as a leader and actually learning from his many mistakes, and because the early technical NeXT decisions eventually became underpinnings for modern macOS and iOS.

I do not see this as a book of new immense insight, technical depth, or design details, but that doesn’t mean it doesn’t go beyond surface level. What I appreciated most was Cain not shying away from pointing at some of Steve Jobs’s mistakes: hiring wrong people he happened to like, almost driving the company to the ground through obstinance, inability to focus on things he considered uninteresting, and a profound dose of duplicity coming into the NeXT/​Apple merger.

Other things that stood out: focus on people around Jobs, spotlight on Jobs’s disappointing moral flexibility around working with government (or befriending Larry Ellison, for that matter), and a really fun pizza ordering story that serves as a prelude to the Starbucks call during the iPhone 2007 keynote.

Some learnings:

• Craft and taste alone are not enough; you can spend your talents and energy on things that don’t “matter” given some definition of the word. That could be okay if that’s a choice you make – “impact” is ill-defined and often overrated, anyway – but you need to approach it clear-eyed, which Jobs didn’t initially know how to do.
• Confidence, like everything, needs to be practiced, and focused, and influenced back by feedback and reactions. (Witness the negotiating acumen of a certain Jean-Louis Gassée!)
• It’s really hard to create a culture of hard and honest and deep conversations that’s also not a culture of abuse and toxicity.

The one thing I didn’t like about the book was that the few photos inside are only perfunctory; there’s a lot of chatter about a beautiful, symbolic NeXT lobby staircase, top-of-the-landline phones, and expensive chairs, but we never get to see them. Many of the photos are by Doug Menuez – which you can also see online – but the problem is that those photos are generally not that interesting.

That aside, it’s still a breezy and entertaining read that filled in some gaps and provoked new thoughts.

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.

Turns out that the breathing light survives, sort of, not really, in an Apple product today:

The AirPods Pro case does this when charging – right at the start, or when you tap it later. But it disappears after a while, the pace is now 28 breaths a minute (over twice as fast as the original iteration), and the light is orange.

Is it still the same thing, reflecting on how smaller organisms breathe faster? Or is it mostly an unrelated idea, with the light fading in and out indicating activity rather than lack of it? My money is on the latter – the light turns white when pairing, too, and it cycles even faster then – but it was nice to imagine the return of the old feature for a second or two… or 2.1, to be precise.

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.

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.

One of the casualties of Apple’s otherwise brilliantly executed transition to retina pixels has been the mouse pointer, which remains aligned to what “traditional pixels” used to be, rather than the retina/​physical/smaller pixels.

Turn on the zoom gesture from a few weeks ago, and you can see the challenge. The gridlines are ½ logical pixel and 1 physical pixel wide:

This limitation is inherited by most tools: Photoshop, Affinity, xScope, even the built-in Digital Color Meter. It’s not the end of the world, of course, but it can be maddening if you are trying to sample a color from a “half pixel” and the cursor stubbornly skips it no matter how delicately you move. Here it is in Figma:

Of the few tools I tested, only Pixelmator allows to sample at the correct, precise level:

I was curious how would a truly precise cursor feel in general – would there be any disadvantages? – so I built a little simulator that allows a regular arrow cursor to be aligned to “half pixels” or “retina pixels.”

In the process, I discovered that both Chrome and Firefox already receive sub-traditional-pixel measurements for mousing events, so this was even easier to build than I expected. Now, precise targeting in Chrome and Firefox becomes possible:

I don’t personally see any big difference in terms of either upsides or downsides, and I’m curious if you do. iPadOS and its Safari already seem to support the precise mouse pointer, too. That makes me curious: why isn’t it available in macOS? I imagine you could even turn it on by default for apps – or, if you want to be more conservative, make it opt-in.

Pixelmator also shows that the apps can do it without waiting for macOS as the data is already there; they would just need to render the cursor on their own with more precision.

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

In the video linked in the previous post, one of the hosts mentions at one point:

The biggest rebuttal is that the greatest audio engine of all time, the one baked into all Apple products, has 16 volume steps. And no one has ever been like, “My iPhone doesn’t have enough granularity to the volume.”

But of course they have. And the solution is easy: on both the iPhone and Mac you can grab one of the many volume sliders and immediately get a lot more precision:

(Can’t help but notice this volume control has a nice set of notches, too!)

But if I told you that you can actually also increase the precision from 16 to 64 stops using the volume up/down keys, would you know how to do it?

Occam’s Razor: it must be a modifier key. So let’s go through them all.

Pressing ⌥ and brightness up/down opens the Displays settings pane, and consequently, pressing ⌥ and any of the three volume keys gives you the Sound settings pane. (This convention, however, isn’t followed for other keys. ⌥ and Mission Control only opens top level of Settings, and ⌥ and other function keys like Spotlight, Dictation, or media transport doesn’t do anything. My guess is that someone simply forgot about this over time which is a pity, because one of the best ways to teach people about a power-user shortcut is to make it as transferrable as possible, to allow motor memory to blossom.)

So ⌥ is out. ⌃ and brightness keys changes the brightness on the external display, and even though that doesn’t really apply to volume, it’s safe to stay away.

⇧ + volume keys reverses the meaning of this toggle below, making ping sounds if the toggle is off, or suppressing them if the toggle is on. This is nice.

That only leaves Fn/Globe which already reverses top-row keys into function keys, and ⌘. But ⌘ is inert. Instead, the combination to add precision is ⌥ + ⇧ + volume keys. (Same with brightness, which can be useful e.g. on a very dark plane.)

I don’t understand this, and I wonder what is the reason it got this way. Modifier keys are generally tricky, but this doesn’t follow any of the go-to rules I would try in this situation:

• Reuse an existing convention for consistency: I don’t think anywhere else ⌥⇧ means “precision.”
• Follow naturally from existing UI building blocks: ⌥ and ⇧ do different things and this is not an intuitive combination of what they do independently.
• Use mnemonics: This doesn’t feel like it’s doing that at all.
• Failing everything else, make it pleasant to press: ⌥ and ⇧ is possibly the least ergonomic two-modifier-key combination.

This shortcut has another problem, which is that it is the only two-modifier-key option here. If you don’t use it often, you might only remember it as “two modifier keys” without further detail, which actually ends up being 10 possible combinations of keys! So if you’re like me, you always awkwardly button mash a bunch of them before rediscovering ⌥⇧.

My recommendation for a small tweak here?

• ⇧ and brightness/​volume: Secondary display/Add pings (both are most important; Shift is nice to press and the “default” modifier key).
• ⌃ and brightness/​volume: Add extra precision (as that gives you more control).
• ⌥ and brightness/​volume/other keys: Open the relevant Settings pane.

Obviously, I might not have all the information that led to the current situation (and it’s possible I don’t even understand it fully), plus changing any long-existing shortcuts is hard. But as above, ⌥⇧ is so peculiar, and it also misses out on the last important consideration: I don’t think anyone would ever discover it by mistake or out of curiosity.

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.

A thoughtful essay by Nick Heer as a sidebar to the annual Apple/Six Colors report card, in which he proposes this simple framework:

In short, the way I think about software quality is the amount of meaningful problems. […]

There are problems in Finder — resizing columns, renaming or deleting files synced with a FileProvider-based app, and different views not reflecting immediate reality. There are problems with resizing windows. AirPlay randomly drops its connection. AirDrop and other “continuity” services do not always work or, in an interesting twist I experienced a couple days ago, work fine but display an error anyway. The AirPlay and AirDrop menus shuffle options just in time for you to tap the wrong one. […]

These are the products and features I actually use. There are plenty others I do not. I assume syncing my music collection over iCloud remains untrustworthy. Shortcuts seems largely forgotten. Meanwhile, any app augmented by one of Apple’s paid services — Fitness, News, TV — has turned into an upselling experience.

As I’m reading this and thinking about my own Apple usage patterns and a similar litany of problems, I keep returning to Apple TV, which feels by far like the most stable and least troubled platform. I wish I had a better explanation for it: Is Apple magically really good at TV interfaces? Are their benefitting from it being a “hobby project”? But I think the Occam’s Razor here is this: tvOS is just a lot simpler.

And just like that, a thought appears: Is what we’re seeing overall is really just Apple losing the battle with complexity?

Apple won once, in the late 1990s, when on the hardware side all the Performas and Newtons and LaserWriters were cut ruthlessly, and on the software front Mac OS X pushed Classic away as the operating system. The situation was different then, however, because there was no other choice. Today, Apple seems successful on paper, so the pressure needs to come from inside, from someone high up enough to recognize that what Apple is doing vis-a-vis software quality is not sustainable and hasn’t been for some time now. That the bill already came due on all of the decisions where systems thinking and deep testing and focus and preventative maintenance and paying off design debt have been deprioritized in favour of another shiny launch event that stretches the teams and platforms even thinner.

When thinking about complexity, a different go-to framework I have is “can I explain a situation in a short paragraph?” This can help separate regular bugs (where the explanation is typically: I am doing the thing that used to work and it’s no longer working, so something broke), from bigger problems that require some serious long-term system-thinking approach. Off the top of my head, there are many things I can no longer explain:

• I cannot explain Apple’s widget strategy
• I cannot explain what is going on with the Fn/Globe key
• I cannot explain the long-term thinking surrounding icons in Tahoe menus

Of course, it’s not me who should be explaining those things. And I haven’t done this exercise before so I don’t know for sure if things are getting worse here. It feels like it, though. I wonder if Apple just hit a limit of some sort of being able to deal with complex things, and first course of action should be: don’t throw even more complex things on your plate.

A good thought from Dr. Drang, too:

It’s probably impossible to tell the upper echelon of Apple that it’s breaking revenue records in spite of its software design, not because of it. I hope the next regime knows better.

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.

The breathing light – officially “Sleep Indicator Light” – debuted in the iconic iBook G3 in 1999.

It was originally placed in the hinge, but soon was moved to the other side for laptops, and eventually put in desktop computers too: Power Mac, the Cube, and the iMac.

The green LED was replaced by a white one, but “pulsating light indicates that the computer is sleeping” buried the nicest part of it – the animation was designed to mimic human breathing at 12 breaths per minute, and feel comforting and soothing:

Living through that era, it was interesting to see improvements to this small detail.

The iMac G5 gained a light sensor under the edge of the display in part so that the sleep indicator light wouldn’t be too bright in a dark room (and for older iMacs, the light would just get dimmer during the night based on the internal clock).

In later MacBooks, the light didn’t even have an opening. The aluminum was thinned and perforated so it felt like the sleep light was shining through the metal:

And, for a while, Apple promoted their own display connector that bundled data and power – but also bundled a bit of data, which allowed to do this:

Back when I had a Powermac G4 plugged into an Apple Cinema Display, I noticed something that was never advertised. When the Mac went to sleep, the pulsing sleep light came on, of course, but the sleep light on the display did too... in sync with the light on the Mac. I’ve tested that so many times, and it was always the same; in sync.

Just a little detail that wouldn’t sell anything, but just because.

Even years later, some people tried to recreate it on their own:

To do this I shifted the first gaussian curve to that its domain starts at 0 and remains positive. Since the time domain is 5 seconds total and the I:E ratio is known, it was trivial to pick the split point and therefore the mean. By manipulating sigma I was able to get the desired up-take and fall-off curves; by manipulating factor “c” I was able to control for peak intensity.

But at that point, in the first half of 2010s, the breathing light was gone, victim to the same forces that removed the battery indicator and the illuminated logo on the lid.

I know each person would find themselves elsewhere on the line from “the light was overkill to begin with” to “I wished to see what they would do after they introduced that invisible metal variant.”

I know where I would place myself.

This blog is all about celebrating functional and meaningful details, and there were practical reasons for the light to be there. This was in the era where laptops often died in their sleep – so knowing your computer was actually sleeping safe and sound was important – and the first appearance of the light after closing the lid meant that the hard drives were parked and the laptop could be moved safely.

The breathing itself, however, was purely a humanistic touch, and I miss that quirkiness of this little feature. If a save icon can survive, surely so could the breathing light.

A pair of essays has been rattling in my head for a while.

First is Kyle Chayka from October, in “TextEdit and the relief of simple software”:

Over the past few years, I’ve found myself relying on TextEdit more as every other app has grown more complicated, adding cloud uploads, collaborative editing, and now generative A.I. TextEdit is not connected to the internet, like Google Docs. It is not part of a larger suite of workplace software, like Microsoft Word. You can write in TextEdit, and you can format your writing with a bare minimum of fonts and styling. […]

I trust in TextEdit. It doesn’t redesign its interface without warning, the way Spotify does; it doesn’t hawk new features, and it doesn’t demand I update the app every other week, as Google Chrome does.

John Gruber at Daring Fireball responded to it in January:

But I get the feeling that Chayka would be better served switching from TextEdit to Apple Notes for most of these things he’s creating. Saving a whole pile of notes to yourself as text files on your desktop, with no organization into sub-folders, isn’t wrong. The whole point of “just put it on the desktop” is to absolve yourself of thinking about where to file something properly. That’s friction, and if you face a bit of friction every time you want to jot something down, it increases the likelihood that you won’t jot it down because you didn’t want to deal with the friction.

Part of me agrees with this vehemently – for casual text wrangling, Notes is by far the best iteration of what both the old Stickies app and TextEdit attempted.

But Notes are still evolving. The UI keeps changing. I’ve had a note shared by a friend hanging alongside my own notes for years, without me asking for it. I remember the moment when tags were introduced, and suddenly copy/​paste from Slack started populating things in the sidebar. Then there was this scary asterisked dialog that slid so well into planned obsolescence worries that it felt like a self-own:

And the attendant warning, ostensibly well-intentioned, adorned my notes for months, just because I had an older Mac Mini I barely touch doing menial things in a dusty closet:

On top of that, the last version of Apple Notes on my macOS occasionally breaks copy/​paste (!), which led to some writing loss on my part. (If you cut from one note intending to paste in another, and realize nothing was saved in the clipboard, you lost the text forever.)

These are not show stoppers. But they too are friction that has to be juxtaposed with what Gruber lists in his essay. They’re also friction of the unexpected, new, stochastic flavour. TextEdit’s challenges, on the other hand, are known knowns. In this context, TextEdit is in that rare – and maybe increasingly treasured – place where it no longer gets updates, but it doesn’t feel abandoned, or falling apart, or at the risk of outright cancellation. (I think on the inside of tech companies this is called being “maintenanced” – not actually staffed to be improved, but still eligible for breaking bug fixes and security updates.)

A user named Millie captured this feeling recently on Mastodon:

We need to normalize declaring software as finished. Not everything needs continuous updates to function. In fact, a minority of software needs this. Most software works as it is written. The code does not run out of date. I want more projects that are actually just finished, without the need to be continuously mutated and complexified ad infinitum.

And I saw another person, JP, sharing a similar sentiment:

Personally I would be very happy to live in a postcapitalist world where it was 100% FINE that desktop operating systems had “stopped evolving” because they were good enough to meet basically everyones’ needs, and there was no stock price to crash from an old monopoly having clawed its way to the top with nowhere else to go. “Let [certain] software be finished” has always felt to me like oblique pining for humanity to outgrow our current political-economic system.

Even on my crowdsourced list of well-made apps and sites, someone mentioned Bear – interestingly enough another note-taking app – this way:

The fact that in the 10+ years I’ve been using it, there’s only been a single major overhaul update is a feature, not a bug to me.

I have seen this sentiment grow in recent years, as AI is seemingly shoved into every crevice of everything whether or not it even had crevices to begin with. Liquid Glass on the Mac side and incessant ads plus bugs on the Windows side add to the malaise.

But I’ve also been in technology so long that even outside of tensions of capitalism, it’s hard for me to imagine software not changing. Code does run out of date even if you try very hard. So I don’t know yet how to square all this.

Bear is not finished/“maintenanced,” but it seems to not be changing the same way some other software is changing, either. I’m excited reading its blog – even if there are features or updates that do not pertain to me, they don’t bother me, and make me excited for others benefitting. Its innovation feels considered, not reckless.

In a week I’m praising products I didn’t expect to praise, I feel similarly about Lightroom Classic. When Adobe in 2017 forked Lightroom Classic out of the newly-refreshed Lightroom, a lot of us got worried about the “Classic” tag having “dead man’s walking” connotations. But nine years later, and Lightroom Classic is still being lightly updated with fixes, camera presets, and – occasionally – feature changes that largely feel welcome. Lightroom Classic appears, to once again use industry jargon, “stable.”

Maybe the answers are somewhere in this post: celebrate and fund “maintenanced” apps, fork apps into “stable” and “modern” paths, or encourage and practice slow, considered growth. I bet there are other approaches and altogether new ideas to try, too. (There used to be a tradition, when software was physical, to list all the new stuff at the back of the box. What if we started writing out the things we didn’t add?) But I like at least talking about it to begin with. There are apps in my life I want to feel like TextEdit, there are apps that I want to feel like Notes, and there are ones I’m happy to put on the cutting edge/​beta/canary path, where bugs are a promise, and motor memory a distant dream.

I yearn for a software ecosystem that allows all of these types of apps to blossom.

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?

This first one – in response to pressing the volume buttons – feels world-class. Subtle responses to buttons being pressed, nice haptics, good physics:

This one – stretching of the control center – made me incredulous. The performance and physics of it all are good and fluid, but this feels like absolutely the wrong thing to do here. I think it’s as designed, but it feels buggy to me. Maybe I’m oversensitive to stretching type and shapes like this, but I can’t stand how icky it feels. I am not sure I have seen another place in iOS 26 where elements would stretch in such a cheap way:

And this one – tapping on the album cover to make it show and hide – is bad in perhaps every possible way. It feels designed poorly and engineered poorly, like an HTML approximation of a real thing. All sorts of bad curves and sudden switches, slight reorientations of UI, even some flickering of interface elements at the bottom. It feels so rough I would probably just do a hard switch, no transition, until I got this right. After all, no animation is better than bad animation, and this is not responding to fingers in real time (when the user controls the “speed,” and you absolutely need a transition):

Ultimately I don’t know if this is “as designed,” or rushed, or what are the causes. But It’s interesting and a bit hard to realize that these days even animations in iOS 26 – once, I believe, a staple of good design and execution – are all over the place.

I liked the angry website Bugs Apple Loves because it’s hitting on something that got me worried in recent months: Apple has been bad at bugs for a while now, but we might be overfocusing on giving them crap solely for some of the most visible – even visual – Tahoe stuff.

This is a condensed list at the time of writing, as the site itself doesn’t make it easy to see it:

• Mail search doesn’t work
• Autocorrect won’t take no for an answer
• Apple Pay: card icon changes address
• Google Contacts sync is a black hole
• AirDrop: Looking for devices...
• iCloud Photos: ‘Uploading X Items’
• Spotlight: ‘Indexing...’
• Personal hotspot won’t auto-connect
• Apple Watch widgets won’t let go
• iOS text selection is pure chaos
• AirDrop shuffles targets mid-tap
• macOS 26 window resizing doesn’t work

There are themes here: “the interface doesn’t remember my preference,” and “things move around as I interact with them,” and “some process gets clogged up,” and “a thing gets stuck and doesn’t respond to interface actions.”

What I appreciate about this is that none of this is very “visible” stuff, but the insidious things that add up and bother on the daily basis, chipping away at your flow first and sanity second – which the site tries to quantify via a formula:

I think this is really interesting, even as a satire.

I found it’s really hard, if not impossible, to justify design or experience bugs using the same frameworks as other engineering bugs. As Mike Swanson wrote: “You cannot easily measure the resentment. Or the rage clicks when they smash a button to dismiss another […] pop-up.”

A lot of it is utterly subjective. Various small frustrations add up in non-linear ways. A lot of it doesn’t subscribe to binary “data loss or not” or “does it function or not” classifications. A lot of it feels heavy to fix in terms of context switching, so it’s timeboxed and then discarded when the time box overflows.

I have seen engineers say “Oh, it’s a long-standing bug, it’s been like this for 3 months” as a justification to deprioritize something, while to me it feels like that should be an accelerant. The users have already been suffering for 3 months!

So maybe metrics like these could actually help? Quantifying at least the blast radius (affected users + usage per day) seems valuable, not to mention the embarrassment of seeing something like “9.1 years unfixed by Apple.” (And yes, internal embarrassment and shame should also be a metric.)

This would be harder to do for creators of the site, but easier inside Apple: I would also try to quantify vocal user frustration. One of my tricks when thinking about bugs has been “Notice when your users are really angry about invisible stuff.”

…for example someone going on and on about Finder.

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.

Found listening to this 2-hour episode of The Talk Show podcast with Daniel Jalkut very enjoyable, and more thoughtful than just “bitching about Tahoe.”

One particular thing that stood out to me was a discussion of shame and embarrassment and pride that all come with shipping software. And looking to Apple itself for direction that the company is not really providing, as many of their apps are not using the new Liquid Glass interface – or when they do, they use it in ways that are inconsistent or disappointing.

Some other good themes:

• it’s okay not to change something if the alternative is change for the sake of change, a posture Apple’s hardware team feels more comfortable with than Apple’s software team
• internal Apple politics and the story of the Control Strip
• loved this phrase from Gruber about the macOS’s Tahoe release: “they vandalized it.”

Also, this:

A fair criticism of Apple over the years is that sometimes fixing 50 little misaligned text boxes or divider bars… using your time to do that, is time better spent than adding another user feature.

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.

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.

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.

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.

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.

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.

A good post by Jim Nielsen about icons in menus (in Tahoe).

This posture lends itself to a practice where designers have an attitude of “I need an icon to fill up this space” instead of an attitude of “Does the addition of a icon here, and the cognitive load of parsing and understanding it, help or hurt how someone would use this menu system?”

It seems a necessary ingredient of introducing icons to menus is thoughtfulness and guidance around when the icons are necessary/​useful and when not.

It doesn’t help that the Tahoe icons seems to mess up indentation. (I haven’t updated to Tahoe and might skip it altogether. Even just the planetary-scale rounded corners are something that feels very broken.)

An absolutely eviscerating 18-minute walkthrough of Apple Music for macOS Catalina, from a few years ago. More funny than anything else, but a reminder to test the “boring” edges of your app – like a state with a lapsed subscription, or coming back after a few months.

There’s no way to drag and drop. […] If I want to add this to here, I have to go through this bullshit, and when I do, it takes seconds again.

Also, an ode to a well-functioning back button, and well-behaving loading states. Those things add up so quickly.

(My debugging brain understood what populated the confusing History entries – I bet it was the early play sequences that went through a bunch of stuff without playing.)

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.