Wednesday, January 10th, 2007

iPhone could change mobile browsing

Category: Editorial, GWT, iPhone, Mobile

Nokia has had a phone that supports Safari for awhile. A Nokia chap was at the first Ajax Experience in San Francisco last May showing off the phone. It had the same features that Safari on the iPhone has (zooming around web pages).

Opera Mobile is also very popular on various makes of phones. With the huge market that mobile represents, and the fact that we are still growing up wrt high speed access on these devices, it will be interesting to see the mobile browser war progress (and how it may differ: IE vs. FF on desktops, Safari vs. Opera on mobile).

We can’t simply develop Ajax apps and expect them to work great on the mobile form factor, and we have talked in the past about how Ajax could be a pain here (updating an area of the application that the mobile user can’t even see).

Joel Webber pinged the GWT google group about how GWT could help out in building applications that work across boundaries:

It’s great that these browsers are modern and fully functional, but the devices aren’t just like desktop PC’s. They have different (smaller) form factors, input methods, and (probably) use patterns. And the two browsers involved are the two that usually get supported *last* (if every) by most web developers, but that you get pretty much for free with GWT.

Perhaps what we need here is the concept of ‘device profiles’ in hosted mode, that will help you try out your applications in different scenarios, to see how different users will see and interact with your app. Let’s say the Wii has no good keyboard support (just by way of example, I have no idea whether it does or not) — if you want Wii users to use your app, it would be a really good thing to put yourself in their shoes. This would also be helpful for automatically trying out different screen sizes (a lot of people are still on 800×600 or 1024×768 screens).

One of the great things about GWT (IMHO) is that it makes it easy to switch out implementations of classes using deferred binding. I know this feature is not as fully documented as it should be (yet), but suffice it to say for the moment that it would make it really easy to precompile different versions of your app for different browsers. Imagine that you want to support the iPhone, but its 480×320 screen size really needs a different UI than the one you display to normal web users. Well, why not define two EntryPoints that use different subsets of your application’s UI, and let them be selected depending on the device running it? The beauty of this is
that, if you’ve divided your app nicely into Composites, it’s really only small amount of different code, and each device pays only for the code needed to run its UI. Formalizing the concept of device profiles and automatically integrating it with deferred binding could make this process relatively pain-free.

Fun stuff to think about.

Posted by Dion Almaer at 9:00 am

4 rating from 27 votes


Comments feed TrackBack URI

Things are complicated also by different viewing profiles on the same device. For example, in the iPhone demos you notice that by simply holding the device in portrait or landscape mode will change the resolution between 480×320 and 320×480. If you had constructed a device profile for the iPhone that works only at 480×320, you’ll only cause aggravation when users want to use the application in portrait mode.

Comment by Joeri — January 10, 2007

I think the iPhone is designed to “zoom” pages out to their full view, and the detail of the screen (dpi) may be enough that things are somewhat legible even when zoomed out. The rotation is another factor to consider.

I think for those two reasons, the phone seems to be built to display full-size, standard web designs in mind, and to adapt to the common existing web (including your typical 1024-pixel fixed-width layouts) rather than require a specific viewport if you will.

That being said, you could likely simply apply a mobile/handheld stylesheet, set smaller font sizes, widths etc. and try to “target” the iPhone and mobile devices that way.

Comment by Scott Schiller — January 10, 2007

For application development we are likely to see different data views for different devices. This will depend, however, just like website development, on the business rationale behind optimizing for many devices and browsers.

Comment by Mark Wubben — January 10, 2007

From the demos, it looks to me like the iPhone version of Safari is designed to adapt to the site, so the site doesn’t have to adapt to it. Being able to ‘zoom in’ on a certain portion of a site for example – GREAT solution to eliminating unneeded menu or ad columns from view – but leaving them there in case the user wants to use it.

Maybe we’re all starting to over-analyze already. I think Apple just might have taken the concerns over form factor and viewport optimization off our hands, and made their product work with what ALREADY EXISTS.

Now, will the iPhone move Safari up to a Tier 1 browser to consider when coding a site, for many, I believe the answer is yes. On the other hand, if folks don’t have Safari (or a Mac) available to try it out with, THAT could be the determining factor on whether or not Safari gets the same attention as FF/IE.

Comment by DigitaLink — January 10, 2007

Given the ability to run Windows browsers (including multiple versions of IE), and the native Unix, I have to wonder why anyone would do web development on anything but a Mac.

Comment by don hosek — January 10, 2007

Don, I do web development on a PC, simply because my workplace is all-windows. I don’t get to choose to have mac as my workstation.

Still, at home I do web development on a mac and I don’t find too many differences. I run apache+php both at work and at home, and I develop in firefox with firebug first, and make it compatible with other browsers later.

Comment by Joeri — January 11, 2007

I hope they support SVG in the iPhone browsers.

Comment by Venkat — January 11, 2007

Apps should be designed for the devices they are used on. Screen resolution is only a minor issue, if you are missing the basic web input devices such as keyboard and mouse. It is a great thing if existing websites are supported by phones, but the input limitations make app development much harder… Web toolkits like GWT and IT Mill Toolkit have still long way to go before truly reaching the handsets.

Comment by Jan — March 6, 2007

Best mobile phone debut by a manufacturer ever .

The iPhone is an Entirely Different Revolution

I will buy the iPhone.

Get iPhone Converter

Comment by michael — March 12, 2007

Leave a comment

You must be logged in to post a comment.