Nick Heer has published another very good piece, The Window Chrome of Our Discontent, analysing how Apple over the years has progressively done away with the chrome in application windows, in an attempt to prioritise content over the rest of an application’s user interface. A goal that has been repeatedly stated since OS X 10.7 Lion; a redesign whose execution, iterated a few times since then, has been overall increasingly poorer.
Heer shows this in a series of screenshots of Apple Pages’ interface, focusing on how the window chrome and toolbar have changed over time and pointing out what works and what doesn’t. Yes, not everything introduced in a subsequent redesign iteration has been for the worse but, as Heer rightly observes:
Overall, however, what Apple has done to Pages over this period of time is representative of a broader trend of minimizing the delineation of user interface elements from each other and the document itself. This is the only tool in the toolbox, and I am skeptical it achieves what Apple intends.
Compare again the two more recent screenshots against the ones that came before, and focus on the toolbar at the top of each. In the older two, there is a well-defined separation between the toolbar — the window itself — and the document. In the Big Sur visual language, however, the toolbar is the same bright white as the document. By Tahoe and the Liquid Glass language, there is barely a distinction; the buttons simply float over the document. And, bizarrely, that degrades further with the “Reduce Transparency” accessibility preference enabled […]
For me, this means a constant distraction from my document because the whole window has a similar visual language. As the toolbar and its buttons become one with the document, they lose their ability to fade into the background. In the two older examples, the contrast of the well-defined toolbar allows me to treat them as an entirely separate thing I do not need to pay attention to.
Heer’s analysis focuses on the visual aspects of this general regression, and is spot-on. The only thing I feel like adding is that this regression also appears semantical to me (for lack of a better term). Let’s take that last screenshot of Apple Pages’ top window/toolbar and do a quick thought experiment: suppose you’re not familiar with this application. Suppose you’ve never used it before or used it too sporadically to memorise its interface and commands. Look at that toolbar:
Can you tell me what all those toolbar buttons do? Can you guess their function by looking at them? Can you guess why some of those controls are grouped and some are not? Can you establish whether there’s a difference in their prominence? I showed this toolbar to a couple of people who primarily use Windows, and they were both fairly puzzled.
What’s the difference between (1) and (2)? They both seem to add or insert something, but what exactly? What does (3) do? Or (5) for that matter. Or (6). Why are (4) and (6) in a different colour than the rest of the buttons? The icons for (7), (8), and (9) are still familiar enough, so one can easily guess they are used to insert a table, a graph, and some shape, respectively. (10) is already more ambiguous. If this were an email client, this would be the button to add an attachment to an email message, but this is not an email client. Could it still be referring to some kind of attachment? (11) too is a bit vague, but you can ultimately guess it’s about inserting a comment… Not to open a chat window between collaborators, right? (13) is misleading if you don’t already know Pages. A paintbrush? Could it refer to pasting something? But if it were a Paste command, where are Cut and Copy? And is (14) used to add a page or change the page layout? Maybe?
Toolbars like this work much better with an icons + text view and a much clearer distinction between their function, if they’re direct commands or if they just open inspectors or additional tools. I don’t have Mac OS 26 installed, so I don’t know whether Pages’ toolbar now comes in icon view only or not. If it does, then this is a rather cryptic toolbar for novice users. If you design for purely icon-based toolbars, then you must do additional work to make those icons as clear and unambiguous as possible. If your toolbar has multiple views and can be displayed as icons + text or even text-only buttons, then you can afford to have a couple of icons that aren’t very immediate at first glance, because when you have such multiple view options in toolbars (as Mac OS historically has had), they usually default to an icons + text view. Once you got familiar with what all the buttons do, you can save some application window real estate by switching to an icon-only view.
And what’s amazing is that, if you go back to Heer’s article and look at Pages’ toolbar under OS X Lion, all those icons are rather self-explanatory when you look at them without their labels. That happens thanks to the icons being more colourful, detailed and descriptive. Of course the Comment button is a Post-It note. Of course the Media button is instantly recognisable. Of course all the buttons that open a menu instead of triggering a direct action do feature a small expansion triangle next to them. They all have these little visual cues that you consistently see in other places of the operating system’s UI. But this, of course, only works if you have a consistent operating system’s UI, and not a patchwork of different ideas assembled by different committees.