I've been thinking about this non-stop since Tuesday. If you haven't seen Steve Jobs' keynote at Macworld last week, you're already late to search for the video. What Apple presented is not just a phone that plays music or connects to the internet. The darn iPhone is, for all intents and purposes, a slap of reality for those of us who spend our nights writing web code and fighting with browser compatibility.

When Jobs said that line about "an iPod, a phone, and an internet communicator," the room applauded, fascinated by the gadget itself. But sitting at home, watching it, I could only think of one thing: it has no physical keyboard and no mouse. Everything relies on a full multi-touch screen. It sounds like sci-fi movie tech, but for those of us who design and program interfaces, this just opened up a technical can of worms of epic proportions.

The Death of 'Hover' and the End of the Cursor

We've spent years educating users to use the mouse. All our current interface logic assumes there's a precise pointer moving nimbly across the screen. We've gotten used to hiding information or displaying entire navigation menus based exclusively on mouse events.

Brew yourself a good coffee, because this breaks another unwritten major rule of front-end development. Look at any typical navigation menu we build today:

// El clásico menú desplegable en DHTML que hacemos todos
var menu = document.getElementById('menu-principal');

// ¿Qué va a pasar con este evento?
menu.onmouseover = function() {
    document.getElementById('submenu').style.display = 'block';
};

menu.onmouseout = function() {
    document.getElementById('submenu').style.display = 'none';
};

Stop and think about it for a moment. How on earth do you trigger an onmouseover with your fingertip on a piece of glass? Exactly, you can't. In a purely touch interface, the concept of "hovering" simply doesn't exist. You either touch the screen or you don't. This means all those super dynamic dropdown menus we've programmed in JavaScript are going straight down the drain if Apple manages to popularize these types of screens. We're going to have to go back to relying almost exclusively on the old reliable onclick event.

Full Safari in 320x480 Pixels

The other big topic of debate on the forums is the built-in browser. Jobs boasted that the iPhone brings a "full" version of Safari (none of those limited WAP pages or stripped-down Opera Mini-style versions). They claim it renders the web exactly as we see it on our shiny 1024x768 monitors.

The fundamental problem? The screen on this phone is 320x480. Apple's "magical" solution is to load the full page scaled down and allow the user to pinch-to-zoom and double-tap on a block of text to make it fit the screen width. It's undeniably ingenious at a hardware level, but at a daily usability level, it seems like a massive band-aid to me.

Imagine reading a dense phpBB forum or trying to navigate a heavy news portal, laid out with four columns full of floats. The user will spend their day zooming in, zooming out, and dragging the page from one side to the other just to read a paragraph. And let's not even talk about the drama of accurately hitting those tiny text links that designers insist on sizing at 10px with a finger—which is, at the end of the day, a fat and clumsy pointer compared to the surgical precision of a mouse pixel.

What Developers Will Have to Adapt To

Whether we like it or not, if this phone succeeds—and seeing the disproportionate level of hype right now, I'd bet it will—we're going to have to radically change our approach to the web. It's clear to me, and I'm getting ready for what's coming:

  1. Fatter Interfaces: Buttons and links will have to be substantially larger. The finger is the new mouse, and it doesn't forgive aiming errors.
  2. Less Hidden Magic: If there's no hover, critical information has to be visible right from the start or accessible via very explicit clicks.
  3. Dedicated Mobile Versions: I'm almost certain we're going to have to maintain a parallel subdomain like m.oursite.com with ultra-stripped-down CSS stylesheets and simplified linear structures just for these devices. Because sending hundreds of kilobytes of images and JavaScript over a slow GPRS or EDGE connection is going to be a real pain in the neck for the user.

It's still months away from hitting the market (and I'm sure it will cost an arm and a leg to get one in Spain), but the writing is on the wall. The monolithic, rigid desktop web, designed for sitting in front of a mouse, has its days numbered as the sole untouchable standard. We programmers better start dusting off the old onclick tag and designing interfaces that can handle greasy fingers. The future, it seems, comes without a keyboard.