Thursday, October 23, 2008

The Mobile Web May Be The Only Web Soon: Design For It

I was browsing Nokia's website yesterday to find out more about the upcoming 5800, which these days always involves watching some piece of Flash with whatever music some marketing exec thinks is a) hip right now and thus b) I need to have blaring at me. Unfortunately I was doing this just as Nokia's web servers were having hiccups, so every time I clicked some button in the Flash app on the page, the next Flash segment could not be loaded, and I'd get a 404 File Not Found error page. And of course, I couldn't try to just reload that segment again, because the error page had wiped out the Flash application. Flash breaks the browsing model of the browser that way. I'd have to reload the page with the Flash app, and go through the intro and the music and the posing of the phone again, before I could resume where I was. I knew that the server hiccups were temporary, and that normally the Flash segments would be loaded one after the other inside the Flash player on the page and that what I was experiencing would normally not be an issue, but then I thought, man, if I was doing some mobile browsing here, this would suck.

Mobile browsing is just like dealing with a colicky web-server: often everything goes fine, but if you are on the actual move with your mobile device, you walk into or out of WiFi range, or when using the mobile phone data networks sometimes you don't get the connection, or half of the page. It just happens. The network cloud has gaps, dead spots, and fragile pipes, whichever wireless networking standard you use.

The whole set of web browsing technologies (the 'stack' as these things get called because diagrams of them always look like stacks of blocks with names of standards in them) is pretty resilient for that. TCP/IP certainly was specified to deal with faulty or bursty connections. HTTP, the standard for the web, was designed to make the web-browsing transaction really simple: ask for a page, get one, ask for the next page, get one, and if getting one fails, it is really simple to ask again. The browsers around it will show you with simple reload buttons and error messages. Network drops? Things stop, and then you can pick up again. Except for Flash, or some AJAX apps. They often rely on perfect connectivity too much.

Which was an ok assumption for a very long time; people get broadband, they are always on, when they browse the packets arrive to their homes, so hey, as long as you request a valid file, a web designer can assume it will arrive. Well maybe if they are outside of the house things fail on their tiny screened phones, but hey, make a special mobile website for that. But here's the thing: the standard Word Wide Web and the mobile web are not diverging. They are not continuing along parallel lines. They are converging. They are becoming one.

All phones before the iPhone have demonstrated that the mobile web as conceived by WAP / OMA/ iMode is mostly a stop gap, something for emergencies, not something people look forward to using if they have an alternative. The iPhone is demonstrating that many people are just fine with carrying a huge -- well, compared to a Series 40 phone or so -- piece of glass as long as they feel the usefulness trumps being tiny. Especially if you normally already carry a handbag anyway. Or a messenger bag, or a backpack, or cargo pants. And that perceived utility? Well, before it became the portable game machine to beat (Hi Sony, hi Nintendo!) there was the music, but we had regular iPods for that. So what was it? The ease of use? The keyboard? It can't be the camera, gawd. Well, I am actually seeing an awful lot of browsing out and about. A lot. I think it is one of the things of this machine that really drives those 10 million sales.

Seems people like having the web around. Like to be connected. I am seeing the same with netbooks: people who wouldn't have dreamed of shelling out a few grand for a tiny subnotebook a few years ago, deriding them as having too small screens and keyboards are snapping up netbooks, now that they have become cheap enough to be able to run Firefox at 400 dollars, and going "Wow, I can start up and browse in 4 seconds!" The problem wasn't the screens and the keyboards, it was the cost to benefit ratio. OLPCs. Big portable media player makers like Archos are putting browsers in their flagship models. We like to have the web around. The real one.

This class of Big-Glassed Mobile Devices is a new platform, and it is changing the web. I am already seeing pages being simplified to display well on this handheld platform. It's happening because the iPhones and Androids and netbooks are becoming so ubiquitous and powerful in ways CliƩs and Palms weren't in their heyday. Color, processing, built-in networking, speed. The web adapts to what significant minorities of users use to browse. Smartphones are going there as well, Nokia's use of WebKit has always been about getting the 'real' web down.

But it does mean web designers have to design for this new mobility, just like they had to learn to design using web standards and not just IE optimized pages when hordes switched to Firefox and Opera. Design for mobility outside of their or their domains. And mobility here means not using WAP or XHTML-Mobile Profile, but just sticking to simple pages, maybe sniffing browser to send a CSS that hides or shows or re-arranges items on the page. And realizing that if your page should be suitable for 'snacking', meaning quick on and off browsing, not an immersive environment people need to spend hours in, but just another site to check and get some specifications or news from, it should degrade gracefully if the user walks into a dead spot. You know, not have the AJAX form get into some locked unrecoverable state because the right extra piece of form did not come in, and you have to reload and lose all the data you entered. Same for multi-page forms if the user can't get to the next page immediately but needs to wait to be in another Starbucks. And certainly not have Flash conk out and require the user going through your whole movie again just to get back where they were when the bus they were on gets back into network range.