Jim Nielsen:

It’s extra noise to me. It’s not that I think menu items should never have icons. I think they can be incredibly useful (more on that below). It’s more that I don’t like the idea of “give each menu item an icon” being the default approach.

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 an icon here, and the cognitive load of parsing and understanding it, help or hurt how someone would use this menu system?”

The former doesn’t require thinking. It’s just templating — they all have icons, so we need to put something there. The latter requires care and thoughtfulness for each use case and its context.

To defend my point, one of the examples I always pointed to was macOS. For the longest time, Apple’s OS-level menus seemed to avoid this default approach of sticking icons in every menu item.

That is, until macOS Tahoe shipped.

Nielsen’s post on MacOS 26 Tahoe’s tragic “icons for every menu item” design edict was published a month ago, before Nikita Prokopov’s post on the same subject yesterday. Both posts are crackerjack good, and complement each other. Nielsen makes the point that the Mac stood as a counter to platforms and systems that put icons next to every menu item. Of course Google Docs has icons next to every menu item. It sucks. Google sucks at UI design. We Mac users laugh at their crappy designs.

Well, who’s laughing now? It might sound hyperbolic but this change is the reason why I’ve decided not to upgrade to MacOS 26 Tahoe. I could put up with the rest of Liquid Glass’s half-baked who-thought-this-was-OK-to-ship? nonsense, but not the whole menu bar. I can tolerate being angry about UI changes Apple makes to the Mac. But I can’t tolerate being heartbroken.

John Gruber (MacRumors): The first is an entire BlackBerry-style phone: Clicks Communicator. It runs Android but ships with a custom launcher that emphasizes messaging and notifications; it has a hardware mute switch and a side button with a color-coded alert light they call the Signal LED. […] The second is the Clicks Power Keyboard. It’s […]

Apple (Hacker News): In iOS 26.2 and later, browser engines other than WebKit can be used in two types of apps for users in Japan: Dedicated browser apps that provide a full web browser experience, and apps from browser engine stewards that provide in-app browsing experiences using an embedded browser engine. […] To help keep […]

Paul Thurrott (Slashdot): “My goal is to eliminate every line of C and C++ from Microsoft by 2030,” Microsoft Distinguished Engineer Galen Hunt writes in a post on LinkedIn. “Our strategy is to combine AI and Algorithms to rewrite Microsoft’s largest codebases. Our North Star is ‘1 engineer, 1 month, 1 million lines of code.’ […]

Jason Fried:

My folks are in town visiting us for a couple months so we rented them a house nearby.

It’s new construction. No one has lived in it yet. It’s amped up with state of the art systems. You know, the ones with touchscreens of various sizes, IoT appliances, and interfaces that try too hard.

And it’s terrible. What a regression.

Examples include: light switches that require a demo to use, a Miele dishwasher that requires the use of a companion phone app, a confusing-to-use TV (of course), inscrutable thermostats, and:

And the lag. Lag everywhere. Everything feels a beat or two behind. Everything. Lag is the giveaway that the system is working too hard for too little. Real-time must be the hardest problem.

Now look... I’m no luddite. But this experience is close to conversion therapy. Tech can make things better, but I simply can’t see in these cases. I’ve heard the pitches too — you can set up scenes and one button can change EVERYTHING. Not buying it. It actually feels primitive, like we haven’t figured out how to make things easy yet.

In this period of the computerization of everything, so many systems have lost the innate intuitiveness from their analog counterparts. Light switches were easy and obvious. Flip the switch. Thermostats were easy and obvious. Turn the dial until the indicator points to the temperature you want. Light switches and Honeywell thermostats were so simple they seemed like they weren’t “interfaces” at all, which is why they were such great interfaces. The best interfaces almost literally disappear.

One of the mottos of the Perl programming language is that easy things should be easy, and hard things should be possible. That’s the ideal when designing anything. But the more important part is keeping easy things easy. A house full of old-fashioned analog light switches is better than a house full of smart switches that need a demo to use at all, even though with the old-fashioned switches, you can’t do hard things like turn off the lights remotely, or turn off every light in the house with one action. The smart switches might seem like an improvement because they make possible hard things that were previously impossible. Making possible the impossible is surely a win, right? But not necessarily. Making possible the heretofore impossible isn’t axiomatically a win. It’s a loss if it comes at the expense of keeping the easy things easy, consistent, reliable, and intuitive. Nothing exemplifies that more than the decline in user experience of watching TV, and attempting something as previously simple as flipping between two games on two different channels.

The guiding principle when creating computerized versions of analog systems ought to be “First, do no harm.” Everything should be as easy, obvious, reliable, and intuitive as in the old system. Only add to that what doesn’t introduce any regressions on those fronts.

Alas, that’s not how the world has proceeded.