Safari 15 isn’t bad, just misunderstood
Safari 15 isn’t bad, just misunderstood
A long time ago, back when smartphones were called Treos, I hosted a popular PalmOS podcast and was active on all the forums (this was before Twitter). I frequently got the question, “If Palm is so good, why do I see so many complaints about it on the internet?”
My answer was that people who like something or simply don’t have a problem with it don’t tend to take the trouble to post about it. You never see people post on a forum saying, “Everything’s fine! Just thought you should know!”
On a recent Connected podcast, Federico Viticci commented that he hadn’t heard a single comment in favor of the new Safari design in this summer’s Apple betas. What he’s not factoring in here is the “silent majority” who either like the new design but don’t feel compelled to hold forth online about it, or the even larger group of folks who just don’t have a strong opinion, who think it’s fine, whatever.

1 comment
•7 hours ago
Admittedly, it can be hard to keep these folks in mind when the technorati gets so salty about something, but it’s important to remember that podcasters and bloggers aren’t UI designers, are paid to have strong opinions, and might be too invested in the way things are to see what Apple is really going for here.

1 comment
•9 hours ago
What I see in Safari 15 is the first steps into a new design language for iOS, one prioritizing adaptive, contextual interfaces. Ever since the move to the new “all screen” iPhone X design, content has been king on iOS, and Apple has been removing more and more user chrome. This is the next step on that journey.
Let’s look at the iPhone first. The address bar popping up to the top of the screen in the first betas was a gaffe, and that has been fixed. It now docks itself just above the keyboard and that’s a good thing. But the floating state of it, with the drop shadow that torments Marco Arment, isn’t a mistake.
By default when you’re scrolling around in a web page, the address bar does dock itself to the bottom of the screen, and takes up absolutely minimum real estate, not even enough to show SF Symbol glyphs in a tool bar. It’s just the name of the web site above the multitasking bar. This still shows you what site you’re on, but nothing else, because you haven’t indicated to the system yet that there’s anything else to do.
When you tap the screen, scroll up or tap the minimal address bar, it pops into place as a floating UI element. There’s a couple points of interest here.
One, as soon as you start to scroll down again, it goes away. Therefore it’s a not a big deal that it obscures the text beneath it because it’s not intending that text to be readable in the first place. The text of the website is visible for context while you’re interacting with essentially a modal dialog box, just one designed to seem as transitory and organic as possible.
Secondly, you can see the address bar for the neighboring page to the left, giving you a visual affordance that you can swipe this address bar to the right and bring the next page into view. You can also reverse this to bring up a new page. Note that I’m not saying tab, I’m saying page. If you think of the address bar as the “handle” for a specific web page, the iPad and Mac interfaces make more sense.
Because it’s functionally a modal dialog, the address bar could take up the whole screen and it wouldn’t make a lick of difference. You’re not supposed to be actively reading the text that the address bar obscures when it’s visible at all. But it being relatively small does provide you as much context as possible of what you were doing on the page and where you were at. Could Apple make this rounded rectangle two rows deep, with maybe a row of toolbar icons above the text? Sure, they could do that instead of tucking those functions behind a hamburger button. But it would look a lot more cluttered, and we know how Apple feels about UI clutter.
So what do we have? A new browser UI that shows as much of the page as possible when the user is interacting with the page, and surfaces UI chrome only when the user indicates that they need to interact with the UI. Adaptive and contextual. This, Federico, is why Apple declared war on buttons. You should only see a button when you need it. The rest of the time you should see as much of your content as possible.
Now let’s look at the iPad.
The first thing I want to point out is that I have 19 pages open, and they’re not in a tab group. But I can still see almost half of them, and if I scroll from side to side the ones on the ends come into view. You can of course pinch in to see everything at once in a grid view, but you can see a couple words or so of pages near the page you’re viewing.
Again, I use the word “pages” instead of “tabs” deliberately. Federico asked why the tabs don’t look like tabs, they look like the address bar. Because that’s precisely what they are. The tabs are the address bars of other pages you have open. You’re not switching tabs, you’re switching pages. This is also why the title bar and toolbar take on the same background color as the page you’re on. The entire Safari window is the page. When you switch from one page to another, it all changes to match the new page. For example, here we go from Daring Fireball
This is why the “tabs” don’t reflect the color or other branding of the sites you’re not looking at. Because it’s all supposed to match the page you’re on, until you pick a different page.
As far as the tab crowding in the first iPad screenshot, that’s why if you’ll notice in the other two, I’ve got the tabs split out into a tab group called “Safari.” This, again, is the reason that tab groups and this new UI came out at the same time. They’re designed to be used together to prevent having too many address bars on screen at once by subdividing your pages by subject or some other logical grouping.

1 comment
•3 hours ago
This is why I’m depressed that Apple backed off of this on the Mac and from what Gruber was saying, will be backing off on the iPad as well. The new beta 3 interface on the Mac doesn’t make any sense because it has the address bar of the site you’re using on a different line from the address bars of other sites you have open. It breaks the UI logic. The first thing I did when I installed the new Monterey beta was turn that off and revert it all to one line. It’s not so much that I need the vertical space, but I think the new design makes more sense.
Near as I can tell, Apple has always used Safari as a testing ground for new UI ideas, and where they have backed down, I think they made mistakes. Apple was the first to have tabs on the top of the window, replacing the title bar, to better accord with Fitt’s Law. The user community, who saw something different than what they were used to, raised a stink and Apple backed down. But then years later Firefox, Chrome, Edge and the unwashed horde of other Chromium-based browsers all have the tabs on top of the window. Apple should have stuck to their guns.
I’m not sure what Apple is using for metrics to understand how people really feel about these UI changes. I tried to submit a Feedback to the Safari team to let them know that I liked the changes and why, and I literally couldn’t do it. The Feedback app so assumes you have a complaint that it steps you through required fields that don’t apply if you have something positive to say. So I hope Apple comes to their senses, realizes that they’re making this change for a reason and hold true to the logic of the new UI. Maybe next year we’ll see contextual UI chrome replace the toolbars in other Apple apps like Mail and Calendar.