27 January 2006
The day I first played with Google Local Mobile Java Midlet, I immediately recognized that it was going to be a killer application for my phone. Previously, I had to use WAP to lookup phone numbers, addresses, and directions.
Here's a little real-life test scenario and the times it took me to accomplish it (including starting the application or browser):
My wife called me for the name and number of the local bike shop. I knew the name of the place, and I was sitting at my computer, so I typed it into Firefox' Google Search bar really quickly, and found the number from their Local service. Then I proceeded to look up this information in other ways on my phone through Google's MIDlet, Google Local via WAP, and YellowPages.com via WAP.
Timings per search method. Method Time Google Local (PC) 0:20 Google Local Mobile MIDLet 0:40 Google Local WAP 1:40 YellowPages.com WAP 2:30
YellowPages.com was the old-style WAP application which requires you to select through a hierarchy of options, which reduces dreaded typing on a mobile device, but greatly increases the number of round-trips over the high-latency EDGE/GPRS network. This is the sort of thing I'd do in years past on older phones. I'd say, "Yeah, I can look that up," then struggle embarassingly for a few minutes. It's much worse when you don't know the name of a place.
Google Local Mobile remembers my location, so it saved me some keystrokes, and the interface is richer, so I don't incur the latencies of paging around the interface.
In addition to getting the phone number in record time, I had the extra information of the map at almost no extra cost in time -- it was filling in the map in the background while I looked at the little balloon of data.
I like having generic WAP interfaces to data, but some things are just much better served by a full application. I'd like to next see my bank offer a MIDlet interface in addition to their already useful (but sluggish) WAP interface.