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.
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:
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.
Also, many of us are participating in this week’s barcamp-style www.iPhoneDevCamp.com this Friday in San Francisco. We hope to see you there!
You can detect that the iPhone has been tilted:
…iPhone’s Safari really doesn’t like two things: position:fixed and overflow:auto for items with a fixed height.
position:fixed doesn’t work because there is no scrolling, per say; think of the iPhone screen as a resizable viewport that ranges over the “browser window”, which loads the whole page in one scroll-free screen no matter what the size. This is a good thing overall, as it allows for quick, smooth access to many pages that the previous standard-window-model mobile browsers made into a nightmare. However, fixed positioning is out the window for those of us who use it (I am in the same boat with an app I am working on).
My (untested) idea is that we’re going to have to target a script at iPhone similar to the one that we use to fix absolute positioning on IE 6 and earlier. Savor the irony =)
I hope I did this markdown business OK.
The position fixed issue is my biggest pet-peeve. The lack of tracking onkey events is annoying as well.
@Christopher: all that sounds great! As there are too many thousand kilometres between me and San Francisco I can’t make it on Friday, but Dan may be there.
@Mike: Cool! Thanks for the pointer. Doesn’t work on the MacBook though ;)
@Pat: Yeah such scripts crossed my mind as well, but they’re, well, not very elegant. And I frequently see short delays in the repositioning of elements on pages which use such scripts. Which I wouldn’t want to have.
The position: fixed is a real deal killer for “web apps” because they need the toolbar at the bottom (to avoid the finger shadow.) It’s pretty clear that everything else on the iPhone is not a web app because (a) they have toolbars at the bottom and (b) the toolbars don’t scroll :-)
Here is some testing I did to try and get a toolbar. The examples work fine in Safari 3, but fail in iPhone Safari:
More in-depth commentary here:
To be honest I don’t think that Safari/iPhone’s problems are accidental. They are exactly what Apple wanted. Even my opinion of Apple’s engineers isn’t so uncharitable that I’d suspect this happened by accident.
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’.
The part about overflow:auto is wrong. At first i thought the same because of the missing but expected scrollbars. But than i found out that the iphone just uses an not so obvious way to deal with that. You can scroll in the element by using two fingers.
Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.