It can't be written down as code, that's the point.
I am more familiar with taste in coding and it can at best be described—that the resulting code is too subtly different from something else in the codebase, that you're masking a different bug, that you're not following what the code tells you. The good part is that while this cannot be unit tested, you can write documentation and code comments about it that tell people what they need to know.
But for taste of the kind described in the article there's not even a definition. The logic ended up being "trust a bunch of opaque weights the most"
Apple's human interface guidelines says that some things can be written down though. It's a very thurough look at UX and while they don't adhere to them perfectly themselves, it's very much a north star to a some ideals. You can't unit test for taste, but you can integration test that bad tastes haven't happened.
.... and ensuring the entire UI did not require right click to function. Everything was visible to click.
The usability of iPhones and iPads is a great example of how he was right. They're very easy to use and no functionality was hidden in a right click menu: it had to be visible somewhere.
Right click was still always available as a shortcut for advanced users.
Yeah, I think people who didn't use Macs at the time misunderstand the whole "second mouse button"/"context menu" thing. If you were on Windows, you literally couldn't use the computer without context menus. But Mac OS at the time was designed such that every action the user could access was visible in the regular UI, either through a button or through the menubar.
When the context menu was introduced, it was initially designed as a shortcut to actions that were already available elsewhere in the UI.
I've been able to plug in any two buttoned mouse for the 22 years since I first used a Mac. Their own trackpads and mice allow two finger tap to be enabled for advanced users (but on a laptop one finger can press ctrl while the other taps). I don't know how far back you're talking about when you imply no support for them.
But I remember noticing years ago a large room of tech professionals and 100% of the Windows users had mice plugged into their laptops, and zero percent of Mac users did. It was a failure of the Windows ecosystem that people needed those imho.
> I don't know how far back you're talking about when you imply no support for them.
It's not 'no support', it was an insane default. For all the talk of 'easy to use', there's a reason context menus exist. You can't just cram every context-specific interaction into an omnibar or a leftclick. Non-trivial software is complicated. Adding that friction to its use does nobody any favours.
Yes, in the decades since... Trackpads have gotten a lot better, but at the time Jobs was pushing for that nonsense, they simply weren't good enough. (And didn't exist at all for non-laptop computers.)
Defaults are for the normal consumer, non trivial software is not, I think? What's something you think must only exist in a context menu?
Note that in non-trivial or professional software it's typical to have a hand on the keyboard, because not even a second mouse button is enough. Hold 'q' while dragging to adjust exposure in capture one, etc. Or they have dedicated input hardware like mixing consoles. Or they plug in a speciality mouse.
This is only because IMHO, the trackpad is something you can "live with" (edit: on a Mac) temporarily. It beats carrying a mouse around. Having said that, I know a UX designer that only uses the trackpad. Boggles my mind.
Wasn’t it introduced on Tahoe? (Perhaps my memory is failing me here.) Do you mean it still persists on Golden Gate? They seem to have addressed the majority of issues I heard about - unless you mean the issue is that rounded corners exist at all.
I am more familiar with taste in coding and it can at best be described—that the resulting code is too subtly different from something else in the codebase, that you're masking a different bug, that you're not following what the code tells you. The good part is that while this cannot be unit tested, you can write documentation and code comments about it that tell people what they need to know.
But for taste of the kind described in the article there's not even a definition. The logic ended up being "trust a bunch of opaque weights the most"