Treating URL Protocol Schemes as Cruft

One of the more visible changes in last week’s iPhone OS 2.2 update is a new toolbar in Safari. Here’s the previous toolbar from Safari in iPhone OS 2.1:

It now looks like this:

The new toolbar looks much more like an iPhone-sized version of the desktop Safari toolbar, with the rectangular location text field on the left and the oval search text field on the right. But the new toolbar is functionally equivalent to the old one, with the same three tappable targets: location field, search, and reload.

I prefer the old 2.1 toolbar, but, at this point, I’m hesitant to say that the reason amounts to anything more than 17 months of (very frequent) habit. Here’s what the differences amount to:

The location field is shorter, so you see less of the URL.

The reload button seems to be a smaller target, and, because it’s so close to the search field, it seems too easy to mistakenly tap the search field when aiming for the reload button.

The search field is now a bigger target, and therefore easier to tap, but the old 2.1 search button never felt too small to me. They’ve made something bigger that was already big enough.

So two of the three items in the toolbar have been made worse at the expense of improving the other one needlessly.

But I have a theory why Apple did this anyway. My guess is that testing showed that many iPhone users didn’t know that the magnifying glass in the toolbar was a button they could tap to start a web search. The new layout makes it unambiguous what the search item in the toolbar does, and that may well make the small usability hit to the size of the location field and reload button worth it.

To make better use of the available space in the location field, Safari no longer shows the “http://” or “https://” protocol scheme. You do see the protocol scheme, however, when you tap the location field to edit the URL:

But it’s hidden, sort of like file name extensions in the Mac OS X Finder, in the normal display view.

The best argument in favor of always displaying the protocol scheme is to make it visible when you’re connected via HTTPS, but the lock icon in the location field serves the same purpose, and is almost certainly better recognized by typical users than the extra “s” in “https://”.

This is a pretty clever idea, and once seen in action, it seems so obvious that I’m now surprised that the iPhone version of Safari hasn’t been doing this all along. And it makes me wonder whether the desktop version of Safari will follow this lead — space isn’t at such a premium there, but it’s always struck me as somewhat ungraceful that we spend all day staring at dozens of URLs that all start with the same repetitive prefix.