iPhone Web Design¶
847 words on Web Design
The big disappointment at Apple’s recent developer conference was that they announced web applications as the way to develop applications for their new iPhone. I don’t think people seriously expected a full-blown SDK at this early point of the iPhone’s existence, but people were a bit annoyed by Apple pretending that web applications could compete with actual – presumably Cocoa based – applications.
While it is true, and proven over and over again by companies like Google or parts of the ‘web 2’ crowd, that you can do amazing things inside a web browser using JavaScript today, this still falls short of what native applications can do. The finer points of a good user interface are frequently lost when HTML and JavaScript are all people can use for their interfaces. Mac users need to look no further than their Dashboard to understand that. Dashboard widgets frequently don’t fit in with the system’s user interface standards. And don’t even get me started on how they quite reliably disappoint when it comes to aspects like localisation or number formats which are just taken as a given in ‘real’ Cocoa programming. I am sure that many of those aspects can be handled in web applications as well but doing so will require considerably effort.
And yet, I recently got the opportunity to help out with some CSS aspects of Karelia’s TeleMoose (née amaphone) iPhone web application. It delivers an iPhone optimised experience of amazon shopping: straightforward searches, usage optimised for the iPhone screen and – crucially – much shorter load times with the site coming in at 10-20% of the download size of the usual amazon site.
My first remark on this is that it is a joy. A joy to do CSS work without the what will IE6 do to this?
question haunting you all the time and being able to use all the great stuff that WebKit supports – right down to rounded corners. That was quite cool.
Until Dan got to try things out on his iPhone fo real. Which revealed that iPhone’s Safari really doesn’t like two things: position:fixed and overflow:auto for items with a fixed height. With ‘doesn’t like’ essentially meaning ‘ignores’. And as the site was developed in the ‘Safari is your SDK’ spirit and was supposed to have elements fixed at the top or bottom of the screen with the page content scrolling above or below them, these CSS features were essential for making things work. Without them it’s not clear to either of us how we can display something like a search field or a button at a fixed position on the screen.
I ended up wondering what exactly Apple were thinking. As our knowledge is today – and it seems to be even richer than what Apple themselves now reveal about the iPhone’s browser – Apple didn’t just decide/manage to not have a SDK for the iPhone ready and allow third party applications. They furthermore seem to have disabled the very features in their web browser which could have enabled a web application (that is non-trivial / wants to display more than a single screenful of text) to create a decent UI.
With Apple presenting the web browser as the development environment for the iPhone I had fully expected a bit more commitment to that. All I can see is a tag to tell the iPhone to not render pages at the insanely wide width of 980px (a width which may be great for Apple’s recent redesign but which I usually find by far too wide for comfortable reading – particularly on sites with a fluid layout) and a few other simple display tweaks.
What I don’t see is a way to do anything that may make a web page seem worthy of a ‘designed for iPhone’ label. Like access to the orientation sensor say: most likely you don’t want to display a list vertically when the screen is in landscape mode – just as the iPhone’s iPod switches to CoverFlow mode on rotation because the list wouldn’t work well in landscape mode and CoverFlow wouldn’t work well in portrait mode.
Of course precise positioning of buttons at the bottom of the screen would be necessary for a good application, if only because it’s the only place where you can reach for buttons without covering other parts of the screen up with your fingers. But exactly that doesn’t seem to be possible. Ideally, I think, the iPhone should also allow ‘applications’ to replace or hide some of its browser UI chrome. Its screen may be large for a mobile device but it’s still quite small.
Have you done your own iPhone work? And discovered anything interesting or even solutions to these problems? Then please leave a comment!
And believe it or not, my cuddly elk Kalle has been all enthusiastic about the site’s name change. He ordered an iPhone, just so he can use it all day. Rumours go that he’s the one who pressured Karelia into altering the name.
