So, as a persistent dabbler in web design, and a dude who generally has an opinion on everything, this piece on Wired got me thinking about new sites (or accessible versions of existing sites) designed specifically for the iPhone. It’s not a great article – it doesn’t attempt to justify the premise that the iPhone has caused “the creation of a subset of the mobile web that only works with the iPhone’s unique features”, or even explain it properly – but it’s an interesting thinking point. Before we launch into it, though, let’s have an over-simplified history lesson!
For anyone without a background knowledge of the famous Browser Wars™ of the early internet, it was both the best and the worst period of time the web has gone through. The best, because there were two major players driving it forward at a blistering rate of progress; the worst, because those two behemoths of the browser space were often highly incompatible. This made designing exciting, but hugely problematic.
IE 4 onwards began to become a problem, in a very Microsoftish way. Basically, they allowed a hell of a lot of hooks in web content, which could exploit proprietary, closed features of IE; and they didn’t properly support existing standards. This was dressed up as being a good thing – these were ‘additions’ to standards which made the experience better under IE, but other browsers could still display most of the content (just without IE’s embellishments). However, pages began to be designed specifically for Explorer, making other browsers distinctly second class. Suddenly, IE had a stranglehold on the market; the web came more or less under Microsoft’s control. Then… nothing. Microsoft basically abandoned IE, there was no innovation, and the web stagnated as virtually a proprietary extension to Windows.‡
So, what does this have to do with the iPhone? Well, at first glance, some of this looks awfully familiar: proprietary extensions, client-specific pages from major players… Is history really repeating itself? Let’s examine each aspect.
First, the iPhone’s hooks into web content. Now, I’m generally a “standards or death” kinda guy, very much against any vendor-specific addons; I don’t want another IE fiasco. However, I do sometimes break the rules when there’s good reason (even on this very site). I’m a bit on the fence in this case, but I think I’m gonna let it slide. Here’s why.
The hooks iPhone provides fall into two categories. The first is “enrichment”; special links for dialling a number or looking up an address in the Maps application, for example. This is fundamentally no different to the special urls instant messaging services have used for years. It’s tying into closed functionality, sure – but crucially, and unlike a decade ago with IE, it doesn’t damage the user experience on any other device. Not one jot. Not only that, but this functionality is trivial to implement in other clients if desired (though one would question the usefulness of a ‘dial’ functionality on a desktop computer, heh). I think the problem a lot of people have with this is the precedent, not the current implementation; it’s the old ‘slippery slope’ argument. Now, it’s sensible to be vigilant. We can’t give the keys to the castle to Apple any more than we should give them back to Microsoft – but we’re far from that at the moment.
The second category of hooks is subtly different. It encompasses things such as ‘viewports’ – hints to the iPhone as to how far it should be zoomed in by default, what width to set the page to by default, etc. Now, this is non-trivial in terms of implementation; but, think for a moment. Why should any other client need to implement these? No desktop client would ever need to be told how wide its ‘viewport’ is, because that viewport is a clearly defined window on the screen. No other client navigates in the way the iPhone does (by zooming on sections of text), so it doesn’t need to be given a default zoom level. This set of “compensation” extensions are only needed by the iPhone, because they solve problems the iPhone creates itself.
So, that’s the “proprietary hooks” fallacy gone. But what about the custom web pages? They’re very real indeed. Again, though, despite surface similarities there are huge differences between them and the IE-dependent pages of old. One such difference is glaringly obvious: these pages do not depend on an iPhone. They don’t utilise closed APIs, and they don’t do anything you can’t do in a standard desktop browser. They are standards-based.
Yes, such pages organise their content differently – they often have large fonts and big, touchable targets for button presses with a finger. They may even follow the iPhone design style. At the end of the day, though, these are design choices, and that’s the designer’s prerogative. In the same way that 99% of web pages have been designed with the desktop browser in mind, these pages are designed primarily for a mobile browser. Big deal. Desktop-centric sites still work on the iPhone, they’re just slightly less convenient; mobile-centric sites will still work on the desktop, they’re just slightly less convenient! If desktop users want to go cry to mummy because they’re no longer de facto top dog, fine, but don’t try to pretend this is IE 4 all over again. This is standards-based design which just happens to be aimed primarily at a different demographic.
There is one point I concede, and that is this: some frigtards have decided that it’s a good idea to use browser sniffing to only allow iPhones users access to their spiffy new mobile sites. Apple have never sanctioned this. It’s a terrible idea, highly unfair, and if I ever meet someone who’s done this I’ll severely limit his or her options for having children. Comprende?
20/08/07 – Seems John Gruber agrees that this is a steaming pile. Maybe we could get enough people together for a vigilante group? 😉
‡ Accident or evil plan? Well, it’s hardly the first time tactics like this have emerged from Redmond. I call evil plan: if you study the history of the computer industry you’ll find Microsoft strongarming itself into many different sectors in almost exactly the same way. They make it very, very easy to get your code wrapped around their closed system; your application is then reliant on Microsoft products for life. I’m an Apple geek, though, so I’m not without bias. back »