I think a couple of recent events are worth talking about as they relate to GWT -- namely the iPhone's Safari browser and the Wii's Opera browser.
We're starting to see fully-capable modern browsers show up in some pretty interesting places. In case you missed today's Apple announcement, they will be releasing the iPhone in June, with a full version of Safari running on a 480x320 screen. It also turns out that the Nintendo Wii has a beta version of Opera embedded in it (which I assume will be automatically upgraded at some point).
Why does this matter to us? Well, 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 800x600 or 1024x768 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 480x320 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.
This is really just a brainstorm, but I wanted to throw it out there and get everyone's opinion. It's hard to say how close we are to significant penetration of these new devices, but we can use GWT's leverage to prepare ourselves for this world!
I second Joel's enthusiasm! Just to throw another candidate into the mix, Opera also has "Opera Mini" which runs on Windows Mobile. (I can't keep track of all the Opera flavors. I suspect but am not quite sure that Opera Mini is the same codebase as the Wii browser, and that both are based on "Opera for devices".)
In some ways, the restricted nature of these devices is actually a virtue for users, and an opportunity for web developers. Users will nearly always have their phones with them, but phones are still little islands unto themselves. Applications that can run the same on (or are at least compatible with) a user's desktop as well as her phone or console provide a seamless experience that increases the value of the application. (Why worry about messy PDA/phone-to-PC sync if you just use the browser on the phone to access the same apps anyway?) If GWT can make the construction of such consistent user experiences easy to do, then I think we will have done a huge service for web users everywhere.
I think this is definitely worth pursuing, even if it does sound a little wacky. In support of the effort, I point out that Google has ported GMail and Maps to phones, indicating that there is clearly demand for this type of integration. Meanwhile, as I understand it, Internet access over such devices is quite common in many parts of the world, so there may also be additional hidden demand.
That said, I'm a little unclear on the specific use of deferred binding that you are proposing. Are you suggesting that we introduce "keyboardlessness" (for example) into the deferred binding mix, as a flag to enable globally? That would immediately double the number of generated permutations. Or are you suggesting that we just add targeted browsers individually, such as "Firefox, Opera, IE, keyboardless Opera, ..."?
Meanwhile, the EntryPoints are currently essentially statically processed. Are you proposing that we have the nocache.html dynamically compute entry points along with other stuff? That affects bootstrapping (though you're already working on that anyway.)
Can you throw out a little more detail of what you had in mind?
> I think a couple of recent events are worth talking about as they relate > to GWT -- namely the iPhone's Safari browser and the Wii's Opera browser.
> We're starting to see fully-capable modern browsers show up in some pretty > interesting places. In case you missed today's Apple announcement, they will > be releasing the iPhone in June, with a full version of Safari running on a > 480x320 screen. It also turns out that the Nintendo Wii has a beta version > of Opera embedded in it (which I assume will be automatically upgraded at > some point).
> Why does this matter to us? Well, 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 800x600 or 1024x768 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 480x320 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-fre! e.
> This is really just a brainstorm, but I wanted to throw it out there and > get everyone's opinion. It's hard to say how close we are to significant > penetration of these new devices, but we can use GWT's leverage to prepare > ourselves for this world!
On 1/10/07, Dan Morrill <morri...@google.com> wrote:
> I second Joel's enthusiasm! Just to throw another candidate into the mix, > Opera also has "Opera Mini" which runs on Windows Mobile. (I can't keep > track of all the Opera flavors. I suspect but am not quite sure that Opera > Mini is the same codebase as the Wii browser, and that both are based on > "Opera for devices".)
This isn't terribly new -- browsers have been available on restricted paltforms for a long time. The JS capabilities of these have gone up over time, but still JS-capable portable browsers aren't new.
I would caution against assuming too much about the limitations of such a device. For example, my Nokia E61 has a full keyboard and a relatively large screen. Until gmail introduced the scaled-down version for mobile phones, I was able to use my full screen and the full interface and it worked reasonably well. Now, I get a restricted interface that uses a quarter of the screen -- I suppose I could find some way to hack up the user agent (perhaps having to run a proxy locally on the device), but the assumptions made definitely decreased my handheld experience.
Other non-traditional platforms that support JS-capable browsers include PSP, PS3, Nokia Symbian phones, newer Palm Treos, all the Windows Mobile phones, tablet PCs, UMPCs, and probably many more I don't know about personally.
