Archive for the ‘mobile’ Category

Let your readers subscribe to your RSS via SMS

Wednesday, January 9th, 2008

As a blog reader, one thing I’d love to do is to subscribe to my favorite blogs via SMS. And by “subscribing”, I do not mean simply getting an SMS alert telling me to “check it out on your PC”. I want the full post to be delivered to my phone — so that I can read it while I am driving (kidding!).

Well, thanks to the good folks at textmarks and mowser, I just did exactly that for my own wordpress blog (See how it works). As promised, I am releasing my little wordpress plugin here. Here is what you need to do to mobilize your blog:

1. Sign up for a free keyword at textmarks. This is the keyword people will text in to subscribe to your blog.

2. Request for a free API key from textmarks. This key is needed to broadcast SMS messages.

3. Get my plugin here, unzip it and drop the textmarks_alerts.php file in your wp-content/plugins directory, and then activate the plugin from your wordpress admin console.

4. Go to the Options –> Textmarks Options tab, and fill in your account and keyword information from textmarks. You will also need to fill in the root URL of your wordpress blog. You can choose to use Google or Moswer to adapt your blog pages for mobile screen viewing. Choose “none” if you already have Andy Moore’s wordpress mobile plugin installed. See more explanation on the plugin options page.

Picture 24.png

That’s it folks! Your readers can simply subscribe your blog by texting in your keyword to short number 41411. The subscribers will get a mobile web link for every new post from now on!

Okay, if all those sound too complicated but you still want to use the plugin. Send me $100 and I will take care of everything for ya. ;)

cheers
Michael

PS. The scripts uses Binny V A’s free PHP load() function (from bin-co.com) to make make network connections. It is gets around the sometimes blocked file_get_content() call. Thanks Binny!

Develop compelling iphone applications with JSF + Facelets + Seam

Tuesday, January 8th, 2008

I recently had the pleasure to write an iphone application using JSF + Facelets + Seam. It is mostly a smooth experience but there are also some gotchas I'd like to share with the Seam community.

Okay, first things first, what is an "iphone application", you ask? The iphone SDK has not been released yet! Well, I am referring to a web application that simulates iphone's native look-and-feel via JavaScript and special Safari markups. In particular, I am using the iui library. It works great on an iphone (or even in a desktop browser -- try the official iui demo here)!

So, what are the issues using the iui library with JSF + Facelets + Seam?

The first and biggest issue is that iui and Safari expects the page to be in text/html while Facelets + Seam renders text/xhtml. For some obscure reason (a bug in Safari as Firefox does not display the same issue), this really messes up the navigation. To fix that, you can put the page content inside a pair of <f:view> tags to set the content type properly. Your page will look something like this:

XML:
  1. <html xmlns="http://www.w3.org/1999/xhtml"
  2.       xmlns:s="http://jboss.com/products/seam/taglib"
  3.       xmlns:h="http://java.sun.com/jsf/html"
  4.       xmlns:f="http://java.sun.com/jsf/core"
  5.       xmlns:ui="http://java.sun.com/jsf/facelets">
  6. <f:view contentType="text/html">
  7.    
  8.     <head>
  9.         <title>Your Title</title>
  10.         <meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;"/>
  11.         <link href="iui/iui.css" rel="stylesheet" type="text/css"/>
  12.         <script type="application/x-javascript" src="iui/iui.js"></script>
  13.     </head>
  14.  
  15.     <body>
  16.         <!-- ul and div elements as required by iui -->
  17.     </body>
  18.  
  19. </f:view>
  20. </html>

Notice that the viewport meta data is very useful in iphone development. By default, iphone displays the "thumbnail view" of most web pages when the page is loaded. The words on the page are unreadable in the thumbnail mode. The user is expected to zoom in to read via finger gestures. That works for most large web pages designed for deskto browsers. But you do not want this if your site is optimized for the iphone -- you want the site to display as it is from start up. The viewport element allows you to specify the zooming behavior for this page.

The second issue is that when iui loads pages, it tries to load page fragments via Ajax to provide nice page transition visual effects, as well as nice navigation buttons. To do that some of your dynamic web pages must be provided without the <html> or <body> tags. The facelets <ui:composition> is ideal for this. Here is how one of my pages look like

XML:
  1. <ui:composition xmlns="http://www.w3.org/1999/xhtml"
  2.                 xmlns:ui="http://java.sun.com/jsf/facelets"
  3.                 xmlns:h="http://java.sun.com/jsf/html"
  4.                 xmlns:f="http://java.sun.com/jsf/core"
  5.                 xmlns:s="http://jboss.com/products/seam/taglib">
  6.    
  7.     <ul id="#{siteSearchAction.tag}" title="#{siteSearchAction.tag}">
  8.         <ui:repeat value="#{siteSearchAction.sitesByTag}" var="site">
  9.             <li><a href="view.html?siteId=#{site.id}" target="_self">#{site.name}</a></li>
  10.         </ui:repeat>
  11.     </ul>
  12.  
  13. </ui:composition>

When the user clicks a link to this page, the dynamically generated <ul> list will be rendered according to iui stylesheet, with all the bells and whistles of the "wait" animation and "sliding door" page transition in effect.

Anyway, aside from those two issues, developing for the iphone is really a breeze. What is the application I am writing? Well, you will know in a few days! Subscribe to this blog via SMS! :)

Subscribe to this blog via SMS!

Friday, January 4th, 2008

My little holiday project was to write a very simple wordpress plugin that allows people to get SMS notifications, along with "mobile web links", whenever a wordpress blog is updated. I just tried it on my own blog and it worked like a charm:

1. You can subscribe to my blog feed by entering your phone number below. Or, you can text in word yuan to short number 41411 to subscribe.

2. When I post a new blog entry, you will get a SMS message on your phone with a link to the post, which you can open directly on your phone's web browser (if you have a mobile data plan, as all iphone users, all blackberry users, and many smartphone users do)

That is it! Have fun guys! In the next post (probably on Monday), I will release the wordpress plugin and explain how to use it. Stay tuned! (Actually, subscribe now so that you do not miss my next post! ;))

Here is how the service works on a real phone:

1. Get a SMS link when the blog is updated

Screenshot0092.jpg

2. Open the link in the SMS

Screenshot0093.jpg Screenshot0094.jpg

3. See the page in action on the phone!

Screenshot0095.jpg Screenshot0096.jpg

Courtesy to Textmarks for providing the SMS services (including the short number 41411), and Mowser for providing transcoding services to re-format my blog pages for better display on small phone screens.

PS. This service only works on US phone numbers. Sorry guys, but if you find an equivalent to textmarks in Europe or Asia, please please let me know! Thanks.

Opera Mini 4 rocks

Tuesday, December 11th, 2007

Opera Mini 4 is a web browser for mobile phones. I have been using it for a couple of days now, and in terms of usability, Opera Mini beats the Webkit-based browser on my Nokia N80 -- It is a "desktop fidelity" browser that delivers "iphone-like" user experience. (Actually, the iphone browser itself is webkit-based too.) And the best of all: Opera Mini is a Java ME application (with a significant server side component). It is one of the most polished Java ME applications I had used.

A "desktop fidelity" browser renders web pages just as they are -- there is no attempt to "re-format" a wide web page into a single column (or into WML markup) for mobile display. Reformatting web pages to mobile often renders the page un-readable since the transcoder is not intelligent enough to distinguish important content from the noise (e.g., the ads and long navigation menus etc.) So, a "desktop fidelity" mobile browser first displays the entire width of a web page as a thumbnail on the screen. You can still scroll vertically as you would do in a desktop browser. Here is how the New York Times home page looks like in the Opera Mini 4 browser:

Picture 11.png

Picture 19.png

Notice that there is a small box that you can move around on the page. When you clicks on the keypad, the display zooms into the box and you can now view the page content, click on the links etc. Once roomed in, you can also scroll around to see the rest of the page, and/or zoom out to see the page overview.

Picture 17.png

Picture 18.png

Of course, the "zoom and view" idea itself is not new. The webkit browser shipped with my Nokia N80 can do this almost one year before the Apple iphone. What make the Opera Mini rock are the implementation details:

* Opera Mini 4 supports the landscape mode as you can see from the above screen shots. That is a huge plus for "zoom and view" browsing since it minimizes the "un-natural" horizontal scrolling when you are zoomed in.

* Opera Mini 4 is backed by a proxy server. When you request a web page, the proxy server goes out to fetch the page first, and it resizes all images before sending them to the phone. That not only makes those images display better on the phone screen, but also saves preciously bandwidth and reduces page load time.

* Opera Mini 4 runs CSS and JavaScript very well. Google ads, ajax data fields, complex CSS-based designs all show up very well in the browser. That is pretty crucial for accessing web 2.0 sites.

* Opera Mini 4 provides an intuitive and very configurable set of keypad shortcuts to access core features and your own bookmarks (it is called "speed dial"). Just dial *1 and watch your favorite web site come up. Very useful for the phone.

* Opera Mini 4 has a very good bookmaking system. You can easily go back and forward in your browsing history and bookmark any page you have accessed. You can even share bookmarks with your Opera browser on the PC.

* Opera Mini 4 provides the iphone-like "slide-out" visual effects when the web page changes. This is a small feature but makes the browser pleasant to use.

All in all, Opera Mini 4 is a very solid mobile browser. Its "desktop fidelity" browsing is a significant improvement over Opera Mini 3, which mostly reformat web pages to a single column mobile page. Having used many Java ME applications and wrote a couple of my own, I am very impressed by the quality of overall user experience delivered by Opera Mini 4. Try it out on your Java phone!

The GPS-less location accuracy in the new Google Mobile Maps

Friday, November 30th, 2007

I just upgraded Google Mobile Maps application on my Nokia N80 to the latest v2.0. The biggest feature in v2.0 is that it can now automatically locate yourself on the map. If the phone has GPS (integrated or bluetooth-based), it will obviously use the GPS location data. But if the phone does not have GPS, or if the GPS signal is not available (e.g., inside a building), it can figure out your appropriate location via the ID of the cell tower nearby. I tried out the GPS-less location from my house and my office:

The the green arrow is my house and the blue dot is the location Google gave when I am in the house. The blue circle is the estimated location uncertainty provided by Google. The radius of the circle is around one mile. As you can see the actual location is well within the uncertainty.

Screenshot0084.jpg

Here is a closeup.

Screenshot0085.jpg

This is the result from my office. The building in the middle of parking lot is my office where I ran the test.

Screenshot0083.jpg

The location is not super accurate, and it is certainly not goo enough for driving directions. But for everything else (e.g., search for businesses around you, quickly load maps around you etc), it is more than sufficient.

Nominate your products / projects for the 18th Jolts Award

Tuesday, October 23rd, 2007

Dr Dobb's Journal's Jolt award is one of the longest running and most prestigious awards in the software industry. The 18th Jolt Award is now open for nominations:

http://www.joltnominations.com/Jolt/

Hint: If you develop tools for mobile applications, Jolt does have a category for mobile tools. I will participate in this category heavily this year.

To be qualified for Jolts, you have to submit your own product -- there is a small submission fee ($50 for open source projects) to cover admin costs. As a Jolt judge for the past several years, I can tell you that none of the judges is paid. We are all volunteers contributing our time for free to go through the complicated software evaluation process. What do we get out of it? Well, we get exposure to the latest happenings in the industry and get to put "Jolts Judge" on our name cards. ;)

What do you get out of it? Well, if your product wins Jolts, that gives you some major bragging right! Even if your product does not win, by participating in the process, you get Jolt judges (most of them are consultants influencing purchasing decisions) to look carefully at your product. If some of the judges like your product, they might blog about it or recommend it in their consulting work.

In the past several years, we got an overwhelming number of submissions every year. It is nearly impossible to evaluate each of them in detail, if the judges are not already using the product in his/her daily work. So, it will be enormously helpful if you can prepare a flash or live demo of your product to illustrate the key features that differentiates your product from the rest.

JSF and Mobile Web Applications — Part 2: The ServletFilter approach

Wednesday, September 26th, 2007

The challenges to develop a mobile web application are two-folds:

  1. The application needs to generate different page layout and markups for different devices. This is not just about using wider layout for wider screens -- it also includes using table / CSS / JavaScript for devices that support those features.
  2. The content (e.g., image, media, and text) also need to be customized and transformed for each device.

The web server can tell the client device type from the user agent header in the incoming HTTP request. The question now is how we integrate the user agent header information into the web framework and generate the right web page. The JSF renderkit approach we discussed earlier is not practical since we are not going to go through the trouble to write our own JSF renderkit.

One potential choice is to use the WURFL WALL JSP tag library, which can generate WML / CHTML / XHTML MP markups from the same JSP page based on the user agent. But the WALL tag library is difficult to integrate with modern web frameworks: it requires you to construct your page in WALL tags completely, while frameworks like JSF requires you to use its own component tags on the page. The WALL tag library also only deal with markup transformation. It does not provide different page layouts for different devices / screen sizes (except for the most basic customization hardcoded into the tag library), and does not deal with content transformation / management. We need a more flexible solution.

Don Kittle and Frank Carver mentioned in the comments to my previous blog entry that they use a JSTL servlet filter to transform the rendered XHTML content into WML / XHTML MP, and use special markups on the view template to progressively select content fragments for the target device. Those solutions are very good but they generally break the JSF component model, and to me, they are not generic enough.

So, here is what I think we could do (please let me know if I am missing something!): We can use a URL re-writing servlet filter to check the user agent of the incoming request, figure out the device attributes (e.g., screen sizes, whether CSS is supported etc.), and dispatch the request to the correct template for rendering based on the device attributes. For instance, a request from Nokia 6600 will be dispatched to the 176x208 XHTML MP with CSS template. For most current mobile device, I think the following 10 templates (in 5 groups) will suffice:

* Basic XHTML MP without CSS or table for small screens (width <= 128)
* Basic XHTML MP without CSS or table for medium screens (128 < width <= 176)

* Basic XHTML with table support for small screens (width < 128)
* Basic XHTML with table support for medium screens (128 < width <= 176)

* XHTML MP with CSS for small screens (width <= 128)
* XHTML MP with CSS for medium screens (128 < width <= 176)
* XHTML MP with CSS for large screens (176 < width <= 320, i.e., iphone-like)

* XHTML MP with CSS and JavaScript for medium screens (128 < width <= 176)
* XHTML MP with CSS and JavaScript for large screens (176 < width <= 320, i.e., iphone-like)

* Regular full blown XHTML with JavaScript for PC screens

The filter also saves the device attribute in the HttpSession object. When backing beans render content for the page, they can use the device attributes from the session to retrieve the right content for the device. For instance, the backing bean would retrieve a 176x10 banner image for the Nokia 6600, and limit the dynamic text to less than 250 chars (more or less one screen).

In the context of JBoss Seam, it would be great if we can make the filter a Seam component so that the user can configure it (e.g., URL rewriting rules for template locations) in components.xml. We can also make the device attribute object available as a Seam component so that all JSF beans can inject it as needed. Maybe this will be my next contribution to Seam. :)

Now, there are some potential issues with this approach. Let me explain why they do not matter in most cases ...

  • There are some repetition to write different templates for the same content. But it improves the usability of both the mobile and PC web pages, and that is all that matters. Also, the clarity of XHTML MP/HTML/WML-based design is far better than the opaque JSF tag-based design.
  • The standard JSF renderer cannot generate WML markup for JSF input/form tags. That needs to be corrected by developing a set of WML-specific JSF form tags. That is much simpler than meddling with the renderkit. And frankly, there are not many WML devices out there! The vast majority of mobile phones today are XHTML MP-compliant and works perfectly with standard JSF tags.
  • Some JSF implementations (e.g., MyFaces) use JavaScript to trigger button click actions. That will not work on some lower end devices. Fortunately, JavaScript-free high-quality JSF implementations (e.g., the RI) are readily available.

All in all, I believe the servlet filter approach is the right way to go for most mobile web applications. It allows web pages to be optimized for a variety of devices from the PC to iphone to PDAs to small mobile phones. And it can be used in any web framework since there is really nothing specific to JSF here!

In the next post, I will discuss how to map user agent strings to device capabilities (e.g., supported markups and screen sizes) in the filter, as well as exactly how many different view templates you will need in a typical mobile web application.

JSF and Mobile Web Applications — Part 1: What looks good on paper doesn’t always work out

Tuesday, September 25th, 2007

Update: Please see Dan Allen's comment below for an alternative view. I do agree with him that component level multi-rendering makes sense. But without a good, production ready renderkit, all the practical problems listed in this blog post still exist. The bottom line is that we need a renderkit that can dynamically detect the device, dispatch to different page templates based on the device, render standard JSF components into multiple markups, and generate customized content for the device. That far exceeds the capability of any renderkit out there ...


One of the much touted benefits of JavaServer Faces (JSF) is its capability to render multiple outputs from the same view page. For instance, in theory, the same JSP page can be rendered into WML/CHTML/XHTML MP for mobile phone browsers and regular HTML for PC browsers. However, no one uses that in the real world for a couple of very good reasons. The static JSF renderkit for "mobile content" just does not cut it:

  1. The mobile phones and PCs have very different screen sizes and media capabilities. It would be silly to assume that you can use the same page layout and display the same type of contents for both use cases. If forced to do, the developer will just have to use the lowest common denominator and ruin the user experience. More than likely, you will need different view templates for phones and PCs. Hence the entire point of "reuse the view page" is moot.
  2. Even if it is possible to reuse the page, the price you pay is to write the page entirely in JSF tags. There must be no regular XHTML/HTML/WML tags in the page for this to work. That does not bode well with almost all web page authoring tools. The rendered page is opaque to page designers. As we have seen many times, web developers prefer to construct the page template primarily in "regular" markups and only use JSF tags for specific input / data components.
  3. Since the JSF renderkit is statically configured in faces-config.xml, you cannot have mobile web pages and regular PC web pages co-exist in the same web application. That is really silly and very limiting -- what is the point of page reuse if you have to deploy two web applications to serve those pages?
  4. While JSF can generate WML/XHTML tags from the same page, it does not address deeper content transformation issues. For instance, you will probably need to display different images on different devices based on the target screen size.
  5. Finally, probably because of the above, there is really no production quality mobile renderkit out there for JSF. MyFaces has a basic WML renderkit. But it is just for demo and has not been updated in a long time. There is no renderkit for XHTML MP.

One way to address issues #3 and #4 is to build some user agent detection logic into the renderkit. The renderkit figures out the device type of the incoming request and generate the right tag / image for it. For instance, the following user agent indicates that the request comes from a Nokia 6600.

Nokia6600/1.0 (5.27.0) SymbianOS/7.0s Series60/2.0
Profile/MIDP-2.0 Configuration/CLDC-1

This user agent causes the renderkit to generate XHTML MP tags with all images on the page resized to below 240 pixels wide. The down side, however, is that renderkits are pretty complex to develop and we still have not addressed issues #1 and #2.

In the next post later this week, I will propose a better solution to develop mobile web applications with JSF and potentially other web frameworks. Stay tuned!

The Value of “Technology Incubator”

Sunday, September 16th, 2007

At eZee, the founders made a conscious decision to start our company in University of Texas's Austin Technology Incubator (ATI). To be honest, I did not really know what ATI does when I joined eZee a couple of weeks ago. Okay, I knew that it provides its portfolio companies very cheap office space at prime locations, offers low-cost shared admin / IT / legal services, and provides access to technology investors. But still, while those offerings are nice to have, they do not seem to be strategically important to us -- we are not some cash-strapped no-name startup (actually, the ATI would not admit no-name startups to begin with). ATI gets part ownership of the companies in its portfolio. If all ATI offers is operational help, even one percent ownership would seem a very steep price to pay.

Now, two weeks into my startup life, I finally begin to understand the value of ATI. The "access to UT's brain trust" sounds very abstract, but it is in fact very valuable to any startup. How? Let me explain ...

Most technology startup companies are built on a specific business idea and a specific piece of technology to give them an "edge" in that business. However, as they'd like to say, good ideas are a dime a dozen. It is pretty much guaranteed that someone else is already trying the very same thing. While the business and technical leaders of the startups are probably familiar with the competitors, and have general confidence that "we can execute better." Very few people actually have the time to go through the quantitative exercise to determine exactly how much better we need to be in order to not only beat the competition but also reach our own goals of valuation / market penetration etc. That is especially true for a company like eZee, since we have entering a very big landscape where virtually all ideas have been tried, and many companies have failed or succeeded to various degrees. The founders of eZee would have to do quantitative research on hundreds of mobile-related companies -- including to analyze their execution strategy, financial statements, and finer details of their products / marketing. That is certainly not possible for our busy CEO / CFO / CTO, and beyond the capabilities of technologists like myself.

So, here is where UT and its highly trained MBAs can really help out. They not only study the products and strategies of our potential competitors, but also analyze their financial to determine what our valuation will be if we are in the same space. They help us understand how the market is segmented, and the key differentiating points our company should focus on. That has turned out be to very helpful to the eZee management team, and trickled down to the techies as new product requirements and new delivery timelines etc. I believe that eZee will have a much better chance of success if we go through the analytical studies with ATI on a regular basis.

As we build our product, we can also expect ATI to help out with consumer behavior research, target custom surveys and focus groups etc. All those researches are crucial for the success of the consumer mobile product we are building. They require a lot of specialized expertise and man-power that we cannot possibly deliver on our own as a young startup.

Okay, so much for the ATI's benefit to startup companies. How about the employees in those companies? What are we personally getting from working in an ATI company (well, aside from getting rich from the success of the company as a whole!)? The answer is networking. The ATI building is like a little silicon valley of its own. You can walk around the hall, wonder into other startups, learn what they are working on, and even discuss collaboration opportunities. That is very different from the working-in-my-own-basement startup experience. In the long run, this kind of networking will help us individuals to advance our careers, come up with new ideas, and even assemble teams later to implement those ideas.

All in all, even from my casual observation point, I am now convinced of the value of ATI (and by extension, the MBA education). I hope that we also get to work with those guys on the technical front (EE/CS graduate students?) besides the business front!

com.sun.robot.humanoid — the Office Toy in JBoss/RedHat Austin

Friday, May 18th, 2007

Phillip and I bought the "Java robot" from JavaOne, and decided to keep it in the office as an "office toy". This is easily the coolest geek toy I have seen in years. It can walk around, sit / get up, pick up stuff with its hands, speak / sing (plays any MP3), play video / games on its LCD screen, and even take pictures. It detects and responds to sound, visual objects, and colors. It can even automatically recognize and follow humans. Of course, it can be remotely controlled as well.

Picture 7.png

But the best feature of all is that the robot runs Linux and can be programmed via a simple Java API! There is a simple Java wrapper class that allows your application to interact with all sensors and motors on the robot. You typically run your application in a loop, and try to make the robot respond to events coming in from the sensors. I have not tried but here is some sample code from the SDK. You are smarter than the robot and can figure out what it is supposed to do. :) Isn't that COOL!

JAVA:
  1. Humanoid humanoid = Humanoid.getInstance();
  2.  
  3. ... ...
  4.  
  5. while (true) {
  6.   // Turn off the bright LED in the eyes.
  7.   humanoid.enableLED(false);
  8.            
  9.   // Look around.
  10.   humanoid.VISION.track();
  11.            
  12.   // Check for color red in vision field. Run to red.
  13.   if (humanoid.VISION.getTarget(Vision.RED)) {
  14.     // Turn on the LED in eyes to signal that it sees RED
  15.     humanoid.enableLED(true);
  16.                
  17.     // Advance on target.
  18.     humanoid.WALK.walk(Walk.FORWARD_GAIT1, 10);   
  19.                
  20.     // Are we at the bump?
  21.     If (humanoid.TOUCH_LEFT_FOOT_FRONT.isTriggered()||
  22.               (humanoid.TOUCH_RIGHT_FOOT_FRONT.isTriggered()) {
  23.       // We are done.
  24.       break;
  25.     }
  26.   } else {
  27.     // Do not see RED in current vision field -- so the robot moves around to search for RED
  28.     boolean wanderLeft = 1 != rand.nextInt(1);
  29.              
  30.     // Wander left or right
  31.     if( wanderLeft ) {
  32.       humanoid.WALK.turnRight(2);
  33.     } else {
  34.       humanoid.WALK.turnRight(2);
  35.     }
  36.              
  37.     // Walk forward a bit
  38.     humanoid.WALK.walk(Walk.FORWARD_GAITFAST, rand.nextInt(3) + 3);
  39.   }
  40. }
  41.  
  42. // Raise the arm to declare victory
  43. humanoid.SHOULDER_LEFT_SERVO.moveToPosition(
  44.   humanoid.SHOULDER_LEFT_SERVO.maxPosition() / 4,
  45.   humanoid.SHOULDER_LEFT_SERVO.maxSpeed());
  46.  
  47. // Take a picture of the RED target and display it on the LCD
  48. String pictureFile = humanoid.CAMERA.takePhoto(0);
  49. humanoid.CAMERA.displayImage(pictureFile, 5000);
  50.  
  51. // Say something
  52. humanoid.AUDIO.playClip(mission_accomplished.mp3);
  53. ... ...

The robot is BIG -- it was a challenge to bring it back from San Francisco. :) Just notice how big it is compared with Phillip's 19" monitor in the background.

Picture 6.png

Anyway, we have not officially started playing with it yet (product release deadlines! ;)). I will continue to blog about it here in this blog as we discover its features. If you have ideas on applications, leave a comment -- we might implement it and post a video!

Google Mobile Maps versus Yahoo! Go

Wednesday, April 25th, 2007

Mobile local search is obviously one of the biggest opportunities for Internet search companies like Google, Yahoo, and Microsoft. According to this New York Times article:

“The biggest growth areas are clearly going to be in the mobile space,” Eric E. Schmidt, chief executive of Google, said when asked about new opportunities at a conference here this week. In case his point wasn’t clear, Mr. Schmidt drove it home: “Mobile, mobile, mobile.”

Well, I have been using both Google Maps and Yahoo! Go for some time. They are both excellent J2ME applications. Here are some of my thoughts:

What I like about both apps

Both Google Maps and Yahoo! Go are very usable mapping applications. They can find locations by address or business names (even incomplete ones), display area map, support multiple levels of zooming, and support easy scrolling / panning. Leveraging the multi-thread mobile application runtime, they both fetch new map images tiles in background -- and hence they are much more usable than displaying static maps on a mobile web page.

Local business search is built into both applications. When you enter a search phase, the application searches for businesses in the vicinity of your current location and marks the business locations on the current map. You can then access information of those businesses by pressing the corresponding number key. You can call any business from the app if it has a phone number listed. You can get driving directions to/from that location. You can also see reviews and ratings in Yahoo! Go.

The turn-by-turn driving directions are handled very well on both applications. You can view each turn instruction with its corresponding map like a slide show -- using your keypad to navigate to the next/prev turn. The experience is quite like having a real GPS in your hand.

Screenshot0061.jpgScreenshot0060.jpg

What I like about Google

While Google Maps is not full screen (this seems to be a big oversight), it manages to display maps in finer details than Yahoo (see below). I think high map resolution is crucial for mobile phones -- it reduces the need to zoom in and out just to see a street name. Somehow, the maps from Yahoo! Go look very clumsy on the mobile and there are too few street names on the Yahoo Map -- you have to zoom really close to see the street name and then zoom back out to see the overall area.

Typical Google Maps:
Screenshot0055.jpgScreenshot0054.jpg

A typical Yahoo map:
Screenshot0051.jpg

Google Maps is more stable than Yahoo! Go. The Yahoo application occasionally freezes if you try to do too many things too quickly (it even freezes if you try to zoom too quickly). That is highly annoying on a mobile phone. I almost never encountered a freeze on the Google application.

The overall workflow of Google Maps is also more efficient than Yahoo! Go due to the support for "saved" locations. In Google, you can save any address (or search result) in a "favorite" list. You can then go to any saved point directly to view its surrounding map, get driving directions to/from it, and search businesses / locations around it. When you select a search result anywhere on the map, you can also easily choose a location from the favorite list to calculate the driving directions. It is very useful if your trip has several stops. Yahoo, on the other hand, do not provide an easy mechanism to save locations temporarily. You can only save Yahoo locations on the Yahoo web site and then access the saved list from the phone. That quite severely limits the usefulness of the mobile client. Of course, Yahoo has a very nice "auto-completion" feature in its input box that makes finding previous locations a little easier (see more on this later).

Google Maps makes better use of the numeric keypad to provide quick access to saved address lists, search results, driving directions, zooming, and other important menu functions. Yahoo! Go requires you to use the softkeys (or the joystick) to navigate, which is just a lot slower than shortcut numerical keys.

Google Maps provides satellite images as well as street maps. I find that quite useful when the streets are confusing. Yahoo does not offer that feature.

Screenshot0062.jpg

Mapping applications are bandwidth intensive. I can easily consumer more than 1 MB of data in one day while I am on a trip. The kilobytes gauge on Google Maps is useful when you are on a metered Internet connection. It allows you to see how much bandwidth you have consumed in the current session. It would be nicer if the bandwidth gauge is saved in a persistence storage and collect data across different sessions.

What I like about Yahoo

Now, you might think that I like Google Maps much more than Yahoo! Go. But that is far from the truth. ;) Mobile applications are like icebergs -- they are 10% mobile UI and 90% server support. IMO, the strong point of Yahoo! Go is its tight integration server services. In contrast, Google leverages little server services other than geo-coding, map rendering, and local business searching.

Yahoo! Go incorporates a complete Yahoo search engine. You can search any term and get a list of businesses / locations back. You can view the details of each search result including its ratings, reviews, or even go to its web site -- Yahoo! Go reformats the web site and fits it into your mobile screen. Google, on the other hand, offers a much less sophisticated local search engine. When you enter a search term in Google, it just marks the returned locations on the map. Each Google location only has an one-line title. It is sometimes woefully inadequate -- I tried to search for USPS post offices on Google Local Mobile: it returns some shipping supply shops and USPS pickup locations, but gives me no way to tell which one is the real post office.

Screenshot0058.jpgScreenshot0059.jpg

In addition, Yahoo! Go integrates personalized news, stock quote, email etc. from your Yahoo account all into one application. Of course, that is beyond the scope of a "mobile map" application but I find the highly integrated user experience very appealing.

Besides tight server integration, Yahoo! Go also offers several mobile UI features Google lacks: The Yaoo app is full screen -- very important for mobile phone apps. The text input box in Yahoo! Go remembers all the phrases you typed in the past and offers auto-completion suggestions as you type.

The verdict

I guess the bottom line is that I liked both applications. I find myself using Google Maps more often while I am driving / walking around since it has better maps. But when I am at a place and try to plan the next destination, I almost always use Yahoo! Go to take advantage of its better search features.

The missed opportunities with Yahoo! Go

Tuesday, April 24th, 2007

Yahoo! Go is a mobile application that I use every day. It integrates with my personal online Yahoo account to provide mobile access to Yahoo email, customized news and RSS feeds, stock quotes, local maps, flickr photos from friends, and local search. It has a very slick mac-like UI that allows me to thumb through the screens quickly. Overall, the Yahoo! Go rich client user experience is much much better than the Yahoo Mobile thin client web site.

Screenshot0063.jpg

Yahoo! Go is only available on a selected list of Java devices -- the idea is that the application will be "ported" and customized for each device for the best user experience. For instance, on my Nokia N80, the application graphics are optimized to look good on the large screen. However, IMHO, Yahoo! Go's device-specific port is superficial at best. It misses some real opportunities to take advantage of what the device has to offer.

For instance, my Nokia N80 supports the J2ME File Connection and PIM API. That means the Java app will have permission to write to the local file system. Then, why on earth did the N80 version of Yahoo! Go NOT offer an option to save a Flickr image to the device gallery? If the image could be saved to device gallery, I would have been able to use it as the wallpaper or do any number of cool things with it.

Screenshot0065.jpg

Instead, Yahoo! Go took a "lowest common denominator" approach with the application -- it only provides features that are common to all the phones it support and focuses the porting effort on polishing the UI. I believe that is the wrong approach. If we are porting a J2ME app to multiple devices, we should take max advantage of the device's built-in features.

Photo-realistic 3D driving games on Java mobile phones

Monday, April 23rd, 2007

It seems that all major game developers have ported their best 3D driving games from consoles to Java handsets in the past couple of months. For less than $10 / game, you can now enjoy "Project Gotham Racing", "Need for Speed: Carbon", "Asphalt Street Rules" and more on your mobile phone -- all in stunning 3D graphics.

NFSCarbon_176x208_anim.gif pgr3D-s5.jpg asphalt-street-rules-anim.gif

I have tried a couple of them on my Nokia N80, and have to say that they are exceeding all my expectations. In terms of graphics, well, they rival the original games on my XBOX. Of course, the keypad controls on the phone are not as good as the Xbox controller, the phone CPU is occasionally slow to render complex 3D scenes (i.e., buildings pop up ahead of you as you drive), the frame rate is probably low at less than 10 frames / second, and battery life is a concern if you play the game for a couple of hours a day. However, the ability to play photo-realistic driving games while you are in a boring meeting is priceless. :)

Now some people might ask: how is it possible to run photo-realistic 3D video games on a mobile phone? Isn't the screen too small for that? Well, the mobile phone screen may be small but it certain has enough pixels to render complex graphics. My Nokia N80 has a resolution of 352x416 pixels -- that is significantly greater than the resolution of standard TV signals. If you can play video game on your standard big screen TV, you can certainly play it on the high end phone! The screen shots shown above are at the lower 176x208 resolution.

With new devices like the Nokia N95, which provides hardware 3D acceleration support, Java 3D experience can only get better on mobile phones!

If you have a highend Nokia / Sony Ericsson phone and not done mobile gaming, you need to check out those games. They are truly eye openers.

Appforge and Oracle?

Monday, April 16th, 2007

Appforge is a mobile application tool developer that provides an IDE to cross-compile VB/C# code for Windows Mobile, Symbian, and Palm devices. It is a very nice cross-platform mobile app development tool. I reviewed it for the Jolts award in recent years.

Recently, it seems that Appforge is bought by Oracle and Oracle apparently decided to ditch the AppForge product -- leaving a lot of unhappy customers. It is especially troubling since applications developed in Appforge need a CLIENT license to run (e.g., think of the JVM license in the Java world). If Oracle decides not to sell Appforge CLIENT licenses anymore, that would mean all Appforge applications in development would have to be abandoned. If I had built my mobile app development skills around the Appforge platform, I'd be very frustrated. Fortunately, Java ME is not going away anytime soon.

One thing Oracle can really do to help the Appforge community is to open source it. It does not cost Oracle anything since it does not plan to sell any more copies or support. But Oracle has been given more lip service to open source than to actually contribute anything. Will they do the right thing this time?

The return of mobile browser (Nokia N80 screenshots)

Wednesday, February 21st, 2007

As a Java (J2ME) guy, I have always been bullish on the "rich/smart" client when it comes to mobile applications. I have seen the rise and fall of WAP. The poor usability of WAP browsers and the lack of WAP content has nearly killed the platform. I have used Opera browser on my Nokia 6600 to access "regular" web sites. But it works unreliablly with T-Mobile's $5/mo all-you-can-eat data plan (t-zones), and frankly, the web pages do not look very good when they are "reformatted" by Opera to fit the small screen. In real life, I do not know anyone who uses a phone-based browser on a regular basis. People use voice, messaging, audio/video players, and specialized rich apps such as Google Local Mobile and Yahoo! Go, but not the browser. Given the vast amount of content available on the web, it seems like a huge waste ...

However, just as we are about to give up mobile browsers, two new phones changed my mind. First, of course, is the Apple iphone. It has a really impressive Safari-based browser. We all saw the demo and I will not bore you with the details. But then, I got a new Nokia N80 and tried out its browser. I have to say that it completely blown me away. I have been getting my usual news update (digg / slashdot / cnn / nytimes / dzones / theserverside / infoq / javablogs etc.) almost exclusively on this phone in the past week and the user experience has been supurb. So, what makes the web browser on Nokia N80 so great? Well, here are some of things I liked ...

* Renders all web sites with complex CSS and JavaScript. Well, a browser would not be very useful if it cannot render most of the web pages out there. This browser renders nearly all web sites I visited including this blog and most of the CSS/JavaScript heavy web 2.0 sites. The visual elements and layout of the site is rendered almost exactly as how they would appear on a desktop browser. It does not, however, work with heavy AJAX sites like the Google Map (but that is what Google Local Mobile is for :)), or flash heavy sites like YouTube.

Digg home page (notice the visual elements and JavaScript-based ads are rendered)
Screenshot0007.jpg

New York Times home page (notice the layout is rendered correctly)
Screenshot0016.jpg

* Provides a thumbnail view of the entire page with one keystroke or while you are scrolling. Since most web sites are not designed for small mobile phone screens. A fair amount of scrolling with the joystick is typically needed to view the entire page. The browser has a very nice feature to display the whole page in thumbnail and show the region that is currently visible on the screen. This is especially useful if you are already familiar with the site and know what information you are looking for.

Scrolling view of this blog
Screenshot0006.jpg

New York Times scrolling view
Screenshot0014.jpg

* High fidelity screen. The screen resolution on the Nokia N80 is 352x418. It is incrediblly bright and crisp -- you can see tiny letters on it. Just checkout the above screen shots. That really helps viewing text intensive web pages. Yet, the screen size is just the regular mobile phone screen size. Actually, the phone is one of the smallest I have owned.

* Reformat text columns. Even the high resolution screen cannot accomodate large text columns on some web sites. Instead of requiring the user to scroll left and right to finish long lines of text, the browser reformats large text columns to fit inside the screen. That is very useful when you read news articles or blogs.

Read a story on New York Times
Screenshot0015.jpg

Read a discussion thread on digg
Screenshot0010.jpg

* Quick zoom in and zoom out. If you think the text letters are too small to see, you can quick zoom in and zoom out on any part of the page with few keystrokes.

Zoom out and move around on the digg home page
Screenshot0041.jpg

* Supports WiFi as well as GPRS/EDGE/3G. The browser works reliablly with my home WiFi and my t-zones GPRS service. To be able to use the fast WiFi network on my coach while I am watching TV is an important feature to me.

Select my home WiFi as the access point
Screenshot0013.jpg

* Deep integration with the phone. A big advantage of the built-in browser on the phone is that it integrates directly with other software components on the phone. For instance, if you open a picture in the browser, it would provide an option to save it as use as the phone's wallpaperl; if you open a MP3 file, the phone's built in MP3 player would kick in to play it and offer you a choice to use it as ringtone etc. I really miss this level of native integration when developing apps in the J2ME sandbox!

Download and play a MP3 file
Screenshot0017.jpg

Anyway, I just think that the Nokia NSeries phones have done some great innovation when it comes to mobile browsers. It is rumored that this browser is also based Safari (like iphone) and will be open sourced soon. I think that would be really exicting times ahead of us. :)