By John Gruber
Git + Finder = GitFinder:
a perfect integration. Use code DFPROMO for 20% off.
“You should only see a button when you need it” seems to explain many of Apple’s recent UI directions. File proxy icons in MacOS document windows, for example, disappeared last year in MacOS 11 Big Sur — or rather, were hidden until you moused over them. This post from Michael Tsai has documented reactions and tips regarding this change over the last year — including the fact that in the MacOS 12 Monterey betas, proxy icons can be turned back on using an Accessibility setting in System Preferences. (If you think Accessibility is just for people with vision or motor skill problems, you’ve been missing out on some great system-wide settings for tweaking both MacOS and iOS.)
Does removing proxy icons from document window title bars reduce “clutter”? I can only assume that’s what Apple’s HI team was thinking. But I’d argue strenuously that proxy icons aren’t needless clutter — they’re useful, and showing them by default made them discoverable. Keeping them visible reminds you that they’re there. There’s a one-to-one relationship between a document icon in the Finder and the open application window for that document; showing the document icon in the window title bar reinforced that concept. This hidden Finder preference for MacOS 11 Big Sur delights me, because in addition to showing proxy icons, it also restores grabbable title bars in MacOS 11.
In a sense, no personal computer interface can out-minimalize an old terminal command line — just a blinking cursor on a black screen, awaiting your commands. The Mac’s breakthrough was establishing an interface where you could see — and thus discover through visual exploration — not just what you had done, but what you could do. Proxy icons in title bars weren’t added to classic Mac OS until version 8.5 in 1998, but they exemplified that philosophy. They said: Even though this document is open in an editing window, you can still do things with the file — here it is.
It’s devilishly hard work deciding what to expose at the top level of a user interface. Microsoft went overboard for decades of versions of Windows with way too many inscrutable tiny toolbar icons. But like almost every design challenge, it’s a Goldilocks problem — you can go too far in the other direction, and there is no “just right” that will please everyone. ★
A good mid-summer silly story from earlier today. Chaim Gartenberg, writing at The Verge, “Apple’s Weather App Won’t Say It’s 69 Degrees”:
If you’re an iPhone user, the weather is always a particularly nice 70 degrees. Or 68 degrees. Any temperature but 69 degrees, actually, because it turns out that the built-in weather app on some versions of iOS — including the current version, iOS 14.6 — will refuse to display the internet’s favorite number, even if the actual temperature in a given location is, in fact, 69 degrees, along with several other (less meme-able) numerals like 65 and 71 degrees.
It’s not clear if this is a bug or an intentional attempt from Apple to cut down on 69-related humor. The rounding is only visible in the weather app itself: clicking through to Apple’s source data from Weather.com will show the proper temperature, as do Apple’s home screen widgets. But the iOS weather app will refuse to show 69 degrees anywhere in the forecast, whether it’s for the current temperature, the hourly forecast for the day, or the extended forecast.
Marques Brownlee followed with a quick side-by-side demo with an Android phone. But it was soon pointed out by commenters on Twitter that while true for the Weather app in iOS 14.6, it’s not the case in the current betas for iOS 15. (It’s also not the case for iOS 13, which I still have running on a spare phone.) Gartenberg soon updated his story at The Verge with the following:
A possible explanation for the issue (as pointed out by several people on Twitter) is that Apple may be sourcing data for its iOS Weather app in Celsius and then converting it to Fahrenheit. For example, 20 degrees Celsius converts to 68 degrees Fahrenheit, while 21 degrees Celsius converts to 69.8 degrees Fahrenheit — which rounds up to 70 degrees Fahrenheit. The app appears to have similar issues with temperatures like 65 degrees (where 18 degrees Celsius converts to 64.4 degrees Fahrenheit, while 19 degrees Celsius is 66.2 degrees Fahrenheit).
This theory that it’s a side effect of converting Celsius integer values to Fahrenheit integer values strikes me as almost certainly correct — especially considering that it affects un-notable values like “65”. Or that even in iOS 14.6, negative 69°F displays just fine. But it’s amusing to me that so many people bought into the possibility that someone at Apple thought it was a good idea to avoid showing 69° as a temperature.
Apple’s Compass app will show you 69°. The Finder will tell you if you have 69 files in a folder. Once you start down this path it’s hard to find an app from Apple that won’t display “69” some how, some way, if that’s the value that ought to be displayed. Apple even has products that cost $69.
But Apple’s reputation for prudishness precedes it.
What didn’t pass the sniff test for me with this “won’t show 69°F” idea is that it would cross the line into losing integrity, or at least losing accuracy. Can I imagine a third-party weather app being rejected from the App Store because its screenshots show a big “69°F” current temperature? Yes. But to program the iPhone Weather app to avoid displaying 69°F when it really is 69°F? (Or to demand a third-party weather app not show “69°F” in the app?) No.
Sometimes a cigar is just an integer math conversion glitch.
I’m reminded of the spate of articles a few years ago, when Apple’s original TV+ titles were ramping up production, that Apple executives were squeamish about R-rated content. E.g. this widely-cited report by Tripp Mickle and Joe Flint for The Wall Street Journal in September 2018, which claimed, “The tech giant wants to make scripted shows for streaming, only without violence, politics and risqué story lines.” It didn’t seem preposterous in the least that Apple might have been looking for a Disney-esque “family-friendly only” image for its original content.
Problem is: it wasn’t true. Ted Lasso sure is a feel-good show, but Apple’s acclaimed The Morning Show is just as surely not. Servant is R-rated horror (or pretty close to R-rated). See was a show about a future world where everyone is blind and they pray to their god by masturbating. Disney+ probably wasn’t bidding on that. ★
I think I like the changes for iPhone. The controls are easier to reach at the bottom of the screen, and it’s quicker to switch between tabs.
I get the move to the bottom, in theory — clearly this is about reachability. But I use Safari on my iPhone a lot and I have never minded using a second hand to get to the controls that, heretofore, were at the top: the “ᴀA” menu, the location field, and the reload/stop button.
Here are screenshots from Safari on iOS 14.6:
and iOS 15 beta 2:
Both the old and new designs put these controls one tap away: back/forward, location field, and the tabs button.
The only other one-tap control in the new design is the “···”
junk drawer menu button, which can be long-pressed to toggle Reader Mode. All the other controls are inside the “···” popover menu.
The old design has no “···” menu because it doesn’t need one. It has an “ᴀA” button at the top which can be long-pressed to toggle Reader Mode and when tapped shows a popover menu of site-specific viewing options. At the bottom it has one-tap buttons for Share and Bookmarks. I use the Share and Bookmarks buttons all the time on my iPhone.
The system-wide standard iOS/iPadOS Share popover menu is one of the best UIs Apple has come up with in the last decade. It is extremely useful, very well supported by both first- and third-party apps, and extraordinarily consistent across the entire system. Because it is widely supported and very consistent, it is well understood by users. I realize that the nature of my work is such that I deal with URLs more frequently than most people, but sharing URLs is really common.
I also think the “ᴀA” button is a much better idea than putting all the options previously contained therein in the catch-all “···” menu. Long-pressing “ᴀA” to toggle Reader Mode feels intuitive; long-pressing “···” to toggle Reader Mode feels like they just didn’t know where else to put it. The new iOS Safari “···” menu could have been a “here’s what not to do” example from Apple’s own WWDC session this year on “Discoverable Design”.
Bookmarks are almost completely lost in the new design, and unless I’m missing something, there’s no longer any way to run bookmarklets. I know bookmarklets are an old-school web nerd thing, but I have a few I use frequently, which, if Apple sticks with this design for the next year, I guess I’ll have to rewrite as Shortcuts shortcuts or something.1
The only new thing the new iOS Safari design has going for it is that you can swipe side-to-side on the floating browser chrome at the bottom to switch between tabs. I don’t think that is significantly more convenient than tapping the Tabs buttons to switch tabs. How often you want to swipe through tabs one at a time rather than see your tabs and select one in particular? And if you swipe just a little bit too low, you wind up switching between apps, not tabs.
All that said, I agree with Tsai that the new Safari for Mac is even worse:
For Mac, the new design makes no sense to me, and I’ll likely switch to Chrome if it can’t be disabled:
- Not only does the location bar move when you change tabs, but, because it changes width, all the other tabs move, too. It feels disorienting.
- With everything on one line, there’s less space for tab text than before.
- It’s harder to get at buttons and extensions hidden under the … menu.
- There’s less empty space where it’s safe for me to click in order to drag the window.
- Having the page background color bleed into the tab area makes it harder to read, and it feels weird for the current page’s color to affect the way other tabs look. It also works inconsistently, even on the same pages on Apple’s site. At least there’s a preference to turn it off.
You don’t have to install MacOS 12 Monterey to use the new Safari design; the latest versions of Safari Technology Preview have it too, and Safari Technology Preview is installed as a separate app, not a replacement for the current version of Safari.
Tabs in Safari on Mac (and, in my opinion, iPad) were a solved problem. The new Safari tab UI strikes me as being different for the sake of being different, not different for the sake of being better. The new design certainly makes Safari look distinctive. But is it more usable or discoverable in any way? I honestly can’t think of a single problem the new design solves other than saving about 30 points (60 @2× pixels) of vertical screen space by omitting a dedicated tab bar. But I think the tab bar was space put to good, obvious use with traditional tabs. Matt Birchler points out that horizontally, the new tab design uses space less efficiently. Good luck convincing Chrome users to switch to Safari with this design. Not to mention that every other tabbed app in MacOS 12 still uses a traditional tab bar. It’s consistent neither with other popular web browsers nor with the rest of MacOS 12.
Over the past several releases of MacOS and iOS, Apple has experimented with hiding controls until users hover their cursor overtop, click, tap, or swipe. I see it as an extension of what Maciej Cegłowski memorably called “chickenshit minimalism”. He defined it as “the illusion of simplicity backed by megabytes of cruft”; I see parallels in a “junk drawer” approach that prioritizes the appearance of simplicity over functional clarity. It adds complexity because it reduces clutter, and it allows UI designers to avoid making choices about interface hierarchy by burying everything but the most critical elements behind vague controls.
If UI density is a continuum, the other side of chickenshit minimalism might be something like Microsoft’s “ribbon” toolbar. Dozens of controls of various sizes and types, loosely grouped by function, and separated by a tabbed UI creates a confusing mess. But being unnecessarily reductionist with onscreen controls also creates confusion. I do not want every web browser control available at all times, but I cannot see what users gain by making it harder to find the reload button in Safari.
There’s an axiom widely (but alas, probably spuriously) attributed to Albert Einstein: “Everything should be as simple as possible, but not simpler.” But I don’t even think that applies to this new Safari design. It’s worse. It just looks simpler. All the old functionality remains — it’s just harder to access, harder to discover intuitively, and more distracting. One can only presume that Apple’s HI team thinks they’re reducing needless “clutter”, but what they’re doing is systematically removing the coherence between what apps look like and the functionality they offer.
Here’s another axiom, whose attribution is certain: “Most people make the mistake of thinking design is what it looks like. People think it’s this veneer — that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.” ★
“AppleScript scripts” has always felt a little repetitively awkward, but talking about shortcuts in Shortcuts is worse. I wish Apple had called them “workflows” or something instead. I might use that here at DF when I’d otherwise write “Shortcuts shortcuts” though. ↩︎