First Notes on Designing for iPhone's Safari

The iPhone went on sale yesterday evening. We had one in the studio by this morning. Research, we are calling it, and nobody is arguing. We have spent the first day doing what you would expect: running client sites through Safari on a three-and-a-half-inch touchscreen and taking notes.

These are those notes, published while they are fresh. First impressions with screenshots behind them, not a considered methodology. That piece comes after the novelty wears off and the data arrives.

The headline: it mostly just works

Start with what Apple got right, because it reframes everything else. Safari renders full desktop pages, really renders them, CSS and scripting and all, then lets you pinch and double-tap into the parts you want. Standards-built sites come through recognizably themselves.

Our January advice that clean markup was already iPhone preparation held up on contact with the actual device, and we will admit relief alongside the satisfaction. Text is legible after a double-tap zoom. Layouts hold. The web on a phone, for the first time in our experience, is the web.

That is exactly what makes the failures instructive. When something breaks on this device, it is rarely the rendering. It is an interaction assumption, some habit of mouse-era design that a fingertip just exposed.

The repeat offenders, in order of appearance

• Hover-dependent navigation. The big one. Dropdown menus that open on mouse-hover face a device with no hover. A finger is either touching or it is not. Safari improvises: first tap approximates hover, second tap clicks. It sort of works and wholly confuses. If your navigation’s second level is reachable only by hover, iPhone users are navigating your site through a fog. The fix is old advice with new teeth. Every hover target should also be a clickable destination, and section landing pages should carry their own sub-navigation.

• Targets sized for cursors. A mouse pointer is a pixel. A fingertip is a smudge forty pixels wide. Densely packed link lists, tiny icons, and footer link farms produce mis-taps and the small frustrations that add up to abandonment. Watching someone fat-finger the wrong department three times is a usability lesson no report conveys.

• Forms that fight the keyboard. The on-screen keyboard is decent and still a keyboard on glass. Long forms hurt. Fields that could be choices should not be typing. Every unnecessary field just got more expensive, a discipline forms deserved anyway, now enforced by hardware.

• Flash, rendering as absence. No plugin, no fallback, no error. Just empty space where the navigation or the video was. We knew this from January’s announcement. Seeing a client’s Flash homepage hero as a silent void on a premium device makes it visceral.

The five-minute fix worth doing this month

One mechanical note with outsized payoff: the viewport meta tag. By default, Safari assumes pages want a 980-pixel canvas and shrinks them to fit. Sensible for unprepared sites, comically zoomed-out for pages that would read fine at device width.

A single meta tag in your templates tells the browser your page’s intended width, and content pages snap to legibility without the pinching ritual. Apple’s developer documentation covers the syntax. Implementation is minutes per template. It is the entire distance between ‘works on iPhone’ and ‘pleasant on iPhone’ for a reading-oriented site, and we are adding it to builds as standard practice immediately.

Media, without the plugin

A note on what fills Flash’s absence, because ‘no plugin’ is not the same as ‘no video.’ The device ships with a dedicated YouTube application. Apple and Google arranged for YouTube’s catalog to be re-encoded in H.264, the format the iPhone plays natively. Video hosted on YouTube is reachable from the device even though in-page Flash players are not.

For organizations whose video already lives there, a practice universal search gave us reason to recommend last month, the iPhone story mostly takes care of itself. The embedded player on your page will not run, so provide an ordinary link to the clip alongside any embed, and the device hands it to its player gracefully.

The pattern generalizes into a rule we will apply everywhere: always provide the plain-link path to any media. Right for this device, and right for every context where plugins fail, which accessibility folks will note was already true.

Proportion, before anyone rebudgets

Now the temperature check, because launch weekends distort judgment. This is one device, on one carrier, at a premium price, with adoption entirely ahead of it. Your analytics almost certainly show a rounding error of iPhone visits today. The mistake we cautioned against in January, redesigning for a keynote, is still a mistake after the keynote ships.

But the audit is not premature, because iPhone owners are not a random sample. Early adopters skew toward exactly the audiences institutional sites court: donors, executives, journalists, and prospective students who form opinions early and loudly.

And more deeply, every flaw this device exposes is a flaw for someone. Hover-dependence has always failed keyboard users. Tiny targets have always punished anyone with less-than-perfect motor precision. Bloated forms have always leaked completions. The iPhone did not create these problems. It gave them a glamorous new witness. Fixing them serves audiences you already have.

So spend an hour with the actual device. Borrow one, since its owners love demonstrating it, and walk your own site’s top tasks. Note where you pinch, where you mis-tap, where you give up. That hour is the cheapest, most vivid usability research available this summer.

One observation keeps recurring as we pass the device around the studio: everyone who holds it immediately tries their own site first. Board members will do the same at their next dinner party. The question ‘how do we look on the iPhone?’ is coming to your inbox on a schedule set by Apple’s marketing, not your roadmap. It is worth having a good answer ready.