Saturday, August 19, 2006

Mobile Ajax?

For my entire life, the word Ajax meant for me either a cleaning product my mom used or a pretty good soccer team in the Netherlands. Nowadays, it means Asynchronous Javascript and XML.
As Wikipedia would describe it: "intent is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user makes a change. This is meant to increase the web page's interactivity, speed, and usability".
This week I hosted a panel at LinuxWorld, called "Got mobile?" and I invited Scott Dietzen, the CTO of Zimbra (and formerly of BEA). Zimbra is the poster child of Ajax and Web 2.0. Scott is the best person on the planet to talk about it.
When I was writing alpha Java code at HP Labs in 1995, I thought Java was going to be the language to make the browser more interactive, going beyond the concept of hypertext navigation. It did not happen, partially because Microsoft killed it (and Netscape) and partially because Sun never made true the statement "write once, run everywhere".
Many years later, DHTML and Ajax might be the way to make it happen. I still have doubts it make sense, because with Ajax you destroy the concept of hypertext navigation and the Back and Forward buttons on your browser become meaningless. However, the browser is an ubiquitous way to distribute software, people know how to use it... so I guess I can take it the drawbacks (I am a pragmatic individual).
During the panel, I asked the a couple of questions:
 - Where do you see mobile apps go, towards stored application and data with push capabilities or browser-based dynamic apps?
 - How much data would you store on the device? Is storage going to be always cheaper and bandwidth always more expensive or the trend will change?
The questions were targeted at understanding the future paradigm for mobile applications. Will we have stored apps on the device with local data or will we move the browser paradigm on devices?
I wrote time ago that I believe in the concept of mobile widgets. Maybe mobile Ajax could be the tool to make it happen. You could have applications cached on your device, that use asynchronous calls to the web, using the same tools developers utilize on desktops. Opera is already working on it. It might be what kills Java once again...
Scott did not seem much convinced we are close to mobile Ajax. He said we are not even at Web 1.0 on mobile, that the experience sucks when browsing on a device, that the devices are not powerful enough for the Ajax engine... Let alone thinking about Web 2.0 on mobile. However, he seemed quite sure it will be the way to go, eventually.
I have a doubt, which I expressed during the panel. The paradigm of browsing is user-initiated. You open the browser, you click. That works on PCs.  Your monitor is in front of you, turned on. You interact.
On mobile, it is different. In most cases, you just react. The phone is idle, then it rings: you answer. It beeps: you check the SMS your received.
You do not leave your monitor idle, but you do it with a cell phone. Actually, I would guess 90% of the time your phone is with you, it is in stand-by. Apart from people spending 4 hours a day on a train (which are the vast minority of people on the planet, let's not forget it), we use the phone to react to events. That's when it is useful. When I get off my car, I need that information right there. I turn the phone on, I read it, I do something about it (maybe just curse, if Ajax scored against Juventus).
Now, what is different? That's push. Push technology is the key for mobile applications to be useful. You need information to be pushed to you. Not just email. Everything. From weather updates to purchase orders to tickets to news to stock prices and exchange rates. You need push on devices that are mostly idle. You might not need it on your PC (remember Marimba?) because you are in front of it all the time. You react sometimes (e.g. when you get an email) but that's about it. You NEED push for mobile.
Scott, if we can mix together push and Ajax, we might be golden. Local data storage and apps plus a simple async mechanism to get updates, triggered via push. Push Ajax? PAjax? p-Ajax? Pajax? I am ready ;-)
 
 
Posted by Fabrizio at 09:31  

5 Comments:

Blogger Donald C. Kirker said...  

GAH!!! I missed your panel... Grrr. Ok, I'm done.

When my (computer programmer) friend had first asked me if I had worked with Ajax I had wondered what working with a cleaning product had to do with programming.

I like the thought. Push initiated AJAX. It could resolve cost problems (but possibly create them). We can use the pay-per-kb model here (this is why I missed your panel, I was afraid to check my email from my Treo because of the possibility that mixed with your email I would have a 100kb in spam, and I was not up to paying 1 cent/kb to read spam.... Grrrr) here since most carriers in the U.S. offer this method to customers that do not buy their (usually expensive) data plans.

The test case will be a Motorola phone with the SCREEN3 technology (a Today like screen that displays news and other Internet content pulled from the Internet, I believe it is pulled) on a Cingular plan with no data option, just pay-per-kb. Here, the Today screen has to poll the server every x interval (we'll say hour). If there is no data sitting on the server, then 10kb might have been wasted ( x $0.01 = $0.10). Great. Now say the phone is on for 12 hours in a day. That is 12 * $0.10 = $1.20. Now, a month's usage would be: $1.20 * 30 = $36 a month, just for a stupid phone to check for news. It might not even update every time!!!! That is just as bad as paying Verizon $45/month for unlimited data access on my Treo!

Ok, so, pull (or push :) ) the Pushed AJAX method into view. The user could customize the news, stocks, weather, etc. that was sent to the phone as well as the frequency of the push and maybe even a data limit and viola! Money saver! Instead of polling the server for information that might not be updated and wasting money in the transaction, the server could send the phone (in this case a sort of HTML/Browser widget on the phone's main screen) the updated news. The frequency of updates could decrease, meaning the cost would decrease.

The only thing I could see hurting this are the wireless carriers themselves. They seem to be in the business now of ripping off their customers (i.e. they want to give you the pay-per-kb data plan if you don't buy the unlimited data plan so that you might come back the next month with a $1000 phone-bill).

I love the idea. I love it so much that I think I am going to move adding JavaScript support up on the priority list for WAPUniverse (well, Universe now). I would love to work out some sort of protocol for this. Now you've got me excited.

Let's do it!!! Ajax/P (Ajax over Push, probably best pronounced Ajax P, like TCP/IP is pronounced TCPIP, yeah, just a thought) maybe?

-Donald

Comment Posted at 11:30

Blogger Donald C. Kirker said...  

Forgot to add one thing. Then, if the user sees a little news snipet that they like, or a stock that is on the rise, or something else then they could react by clicking the link to it.

Comment Posted at 11:39

Blogger Yasu said...  

Very interesting insights and conversation. Come to Japan market any time ;-)

Comment Posted at 08:33

Anonymous edschepis said...  

I love the idea too and somebody is already doing great things with Push and Ajax technologies.
Have a look at:
http://alex.dojotoolkit.org/?p=545
http://www.javalobby.org/java/forums/t77829.html
http://www.lightstreamer.com/demos.htm

Edoardo

Comment Posted at 00:13

Blogger Donald C. Kirker said...  

Hmmm, COMET, I like it! Might be really worth looking into.

Comment Posted at 17:42

Post a Comment

Links to this post:

Create a Link

Back to My Blog