Get Developing - iPhone Browser Interaction (Prerelease)
Apps June 17th, 2007Update 6/30/07: We’ve added a new article in this series that has observations based on spending a day testing the iPhone in person.
As hordes of developers scramble to get web apps developed for the iPhone prior to the June 29 launch, many developers (and would-be developers) are realizing several potential interaction issues with their applications.
Multi-Touch Minefield
First and foremost: while drag and drop-style AJAX-y goodness would be ideal to interact with web apps due to economy of clicks/movement, it’s very likely that dragging and hovering won’t function as expected on the phone due to the built in scrolling/zooming gestures.
Have a look at Apple’s screen capacitance tech demo here.
What does this mean? Well, for starters, drilldown menus that work onMouseover (or CSS hover) instead of onClick probably won’t work properly.
Resolution Issues
As has been widely publicized, the iPhone’s resolution is 320×480 pixels. Based on examination of tons of PR photos and tech demos, we’ve found that the likely live browser area is 320×420 (without the address bar overlay) and 320×360 (with the address bar overlay).The topmost menubar (the one with signal strength, time and AT&T) is almost assuredly 320×20, and the bottom navigation menubar should be 320×40.Again, these are guesses based on available material at hand, but I’m reasonably certain that they’re good guesses.
So… Ajax and Javascript, but what flavors?
Another really good question. We can be reasonably certain that if a site functions properly in Safari without hover-drilling menus, it should work pretty well in the iPhone. Whether performance will be acceptable is another issue entirely, however.
Apple’s recent site redesign yields a couple of clues.
They’ve begun using the scriptaculous library really extensively for demos and menu items. If Apple just rolled out their first major site revamp in five years in anticipation of the iPhone, we can rest pretty easy about scriptaculous’s performance.
In addition, I’d wager heavily that Spry framework widgets will work well and seriously help economize browser space, however I’m hesitant about how well the animated effects will perform in-browser. Granted, there are far fewer pixels to push around on the iPhone’s screen, but we’re not using a desktop-class CPU.
Multiple Sites?
Most developers are designing a single site with two separate stylesheet layouts for actual web applications. Sure, Safari will read in any site at any resolution, but there’s something geeky about designing a stylesheet specifically for the phone to help with legibility at 100% scaling. Not to mention the positive karma.I have doubts that the media type “mobile” will affect mobile Safari’s choice of stylesheet (”it’s not the mobile internet…”), so how do we switch CSS? (update: media=”mobile” will be supported per the leaked developer’s notes.)
We know that the iPhone identity string will come up under the user agent request information, so I’ve written a quick, easy function to determine if the site’s being browsed via an iPhone.
<?php//is_iphone function written by Trey Harrell | iPhone-geek.com//usage: if (is_iphone()) { echo "<link rel=\"stylesheet\" href=\"/_css/iphone.css\"// type=\"text/css\" media=\"screen\" />"; }function is_iphone() {$clientagent=$_SERVER["HTTP_USER_AGENT"];if (ereg("iPhone",$clientagent)) {return true; }else {return false; }}?>
Updated 6/19/07:
The following information recently came to light regarding Safari’s behavior on the iPhone:
Flash and Java will not be supported by Safari at launch
The device width reads as 480px, not the 320 that most developers have been assuming.
Media = “mobile” will be supported in the CSS spec
HTML5 is supported
Javascript is limited to 5 seconds’ runtime before (we assume) the process is killed in order to keep the iPhone responsive.
Quicktime will be used, and the optimized setting for video on the iPhone is H.264 baseline profile 3.0 up to 640×480.
I hope that some budding developers will find this information handy. We’ll be updating the site with the latest information as it becomes available and it will all be compiled into a single-page iPhone developer’s guide.If you have any other tips or hints, please share them in the comments below.
9 Responses to “Get Developing - iPhone Browser Interaction (Prerelease)”
Leave a Reply
You must be logged in to post a comment.
June 19th, 2007 at 5:32 pm
Updated with leaked Safari specs. Can’t say I’m surprised about the Flash support (Flash makes for lazy AJAX devs, and uses a ton of CPU), but the 480px thing got me.
June 19th, 2007 at 6:25 pm
One thing many developers are failing to take into consideration is the fact that the phone’s display can and will flip sideways according to user need - this is why the width reads as 480px. And - don’t forget zooming!
June 19th, 2007 at 6:30 pm
I’m inclined to agree with you. Almost every app I’ve seen so far seems to be formatted for vertical/”Palm Pilot” orientation — and that’s probably not the best way to make blocks of text readable (horizontal wins here)… for density of information on the screen, I think the vertical orientation probably works better.
But there’s the catch! Users are free to make up their minds, although it would be fantastic if the browser at least supports 320 pixel wide designs @ 100%
June 25th, 2007 at 9:16 am
[…] that the advent of a finger control interface would spark so much debate? Others have debated at length on the implications of finger browsing, but the main conclusions may be summarized as […]
June 30th, 2007 at 1:58 am
Your spry framework link is broken…
June 30th, 2007 at 2:04 am
Thanks for the note, it’s now updated.
June 30th, 2007 at 2:14 am
Also, for the record, both Scriptaculous and Spry bells & whistles are working on the iPhone here at the evil lair (now that AT&T has recovered from meltdown). Spry transitions, fades and collapse effects are actually reasonably snappy.
As predicted, hover menus don’t work for drilldowns, however onclick/active graphics display during loading for a longer period of time than on desktop machines.
I’ll be taking a good hard look at specifics regarding the browser’s support over the next day or two, but I’ve been pretty impressed with how well it handles just about anything I’ve thrown at it so far.
Edge is a little pokey (Jacksonville, FL area) but not horrible by any means. For browsing and mail, it’s perfectly fine… not like I’m going to be playing WoW over it or anything.
June 30th, 2007 at 2:24 am
A couple more notes: landscape mode is already my preferred orientation for browsing on iPhone, mostly because site text is generally legible without a zoom immediately, and text is just generally easier to read that way. It feels more natural to me as well.
Body text seems to be about 200% larger than specced in the style sheets, relative to navigation/captions/LI items. It doesn’t render exactly like Mac Safari does. Seems to be “smart” about figuring out what blocks are body copy and enlarging them for legibility.
Google analytics mostly works (!!) in it as well, except for some of the more involved scripting on the dashboard (date range being one piece), and that’s a seriously crazy lot of javascript/ajaxy goodness. Have the feeling that the load time may have exceeded the “5 second” javascript rule.
More Saturday in a new article once I get some details and comparisons down.
July 7th, 2007 at 7:11 am
[…] Most web sites are designed for a screen that is wider than it is tall, i.e. a landscape or horizontal layout. With more desktops and laptops coming with widescreen displays these days, this design principle is likely to become more extreme. However, because PDA-phones need to work when held as a phone, i.e. vertically, so that there is sufficient distance from the ear to the mouth, most mobile devices attempt to display web pages on a screen that is taller than it is wide. When web pages designed for a PC are shown on such devices, the browser either has to (i) shrink the font size so that it becomes unreadable, and needs to support some kind of zooming in-and-out, or (ii) reformat the web page so that it is laid out in a column, which is almost certainly not what the web page designer intended. The iPhone supports vertical display, but also horizontal display; all the user has to do is tip the device sideways. In horizontal display, standard web pages are apparently quite readable. […]