Stephen Hackett, Six Colors:
Apple seems to be unhappy with the traditional browser design that includes navigation tools at the top, with websites being forced to live in their own view down below, and with Safari 15, it has blurred the line between browser and web content. This goes far beyond the mere splashes of color that Safari users may be used to seeing behind their navigation controls when scrolling a long webpage.
Now, the new tab bar takes on the color of the website, letting the entire window take on the personality of whatever website is visible. Apple says that this lets browsing feel more expansive, as the browser’s UI is now yielding to the content.
If you are running Big Sur, you can get the same UI experience in the latest version of Safari Technology Preview. It is a very big change.
Before I begin with a few high-level criticisms, I should say that this is an early preview that may change significantly or, like the tabs above the address bar in Safari 4, be scrapped altogether. That said, Apple is marketing the new design heavily, so if you are not a fan of this change, don’t get your hopes up. I should also say that I think I use the web differently than many people. As John Gruber and Ben Thompson said on a recent episode of “Dithering”, there are two types of people in the world: those who know that Safari on iPhone has a limit of five hundred open tabs, and those who do not. I am the former.
I am not a fan of the new Safari design. I am not sure I hate it, and I think I get what Apple is trying to do by combining the tab and address bar into a single element and allowing it to inherit the colour of the page. But I do not think it makes sense yet and, worse, I am concerned about some bad design patterns that are emerging. Before I get into that, I wanted to start with the tab bar backdrop colour.
Hackett:
The color the tab bar takes on can be manually set by including setting a meta tag named
theme-colorin the head of the webpage. (Optionally, different values can be set for light and dark modes.) If this value isn’t set, Safari will choose its own color from the website’s background color or header image. Thankfully, Safari is smart enough to not use colors that interfere with UI elements like standard window controls in macOS.
This meta tag might be familiar to anyone who has built websites with specific support for Android.
This background colour only applies to the currently open tab; it does not persist when switching tabs. If you are on CNet — which has a red accent colour — and then switch to this website, which has a white accent, the CNet tab does not stay red. There is an obvious reason for this: it would become messy and hard to read with many tabs open. But you could make a similar argument if CNet were the only open tab — the red backdrop is jarring and difficult to read in every context.
It also is not a consistent browsing experience if the theme-color is not defined for a website. For example, at the top scroll position of a Markup article, the tab bar backdrop will be a deep blue, selected automatically by the browser. But if you scroll the page a little, the tab will turn grey. Surely it should select a colour and maintain it. And, while Safari is smart enough not to automatically select colours that will make it hard to see window controls, it will accept theme-colors that do. An article page at Rest of World will turn the tab bar a shade of green that is very close to that used for the expand window control in the Aqua MacOS theme.
Condensing the address bar into each tab is also irksome. It is a clever idea, but it means that everything moves around because tabs move. They scroll left to right; they change size as you open and close other tabs.
The small size of a browser tab also means that many controls are hidden by default, including the reload and share buttons. They are all buried into one of those vague “⋯” controls that Apple is obsessed with these days. If you share web links a lot, there is not even a way to add the button back to the toolbar in a more permanent state. This, I think, continues a worrying pattern of bad UI habits.
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.
I just want something in the middle of that continuum. That goes for Safari, but it could just as easily be applied to UI elements that are slowly being hidden behind menus and mouseovers across MacOS like the progress time in Music, the invisible access to Notification Centre, the invisible controls on notifications themselves, and, yes, the proxy icon in document-based applications. These details matter. It is one thing to have a few onscreen elements that have functionality most users are largely unaware of, but it is quite another to hide them with the assumption that if you know, you know.
My opinion might change as I spend more time with this version of Safari on my Mac and iPad, where it is basically the same. But I am adding the “⋯” button to my UI element enemies list. Like the back button, it is a vague excuse to avoid making decisions. It makes application interfaces worse, and the more often I see it, the more concerned I am about Apple’s human interface direction.