Frank R. Bentley, Senior Staff Research Engineer, Social Media Research Lab, Motorola Labs, will be presenting at the San Jose MOTODEV Summit on Truly Mobile Java ME Applications: Location, Media Capture, and Connectivity. We caught up with Frank and got the chance to ask him a few questions.

Q. Why is your session important?

A. Mobile applications have the potential to be quite different from their desktop counterparts. Mobile platforms allow for location based services, near-field device-to-device communications, rich media capture, and available-anywhere network access. Applications that take advantage of these truly mobile aspects can create unique experiences and solve critical tasks for people on the go. Whether someone is developing a game, a web 2.0 social application, mapping service, or productivity software, taking advantage of the unique characteristics of the mobile platform can take that application to a new level of interactivity.

Q. What mobility features will the next killer app have to have?

A. Everyone always says that location is the next big feature for mobile applications. While I believe that location is important, I really believe the next mobile trend will be in social applications. All of the user-generated content on the web will make its way to the mobile along with unique services that take advantage of the mobile environment. The mobile phone is the primary way that most people communicate with those in their social network today, usually via voice. However, as more people use data services and web-based social media sites they will demand the same experiences from the mobile. Location can play a part of that, especially in helping people micro-coordinate and meet up in the physical world. Media capture can help people share their experiences with each other while physically separated. The biggest challenges will be to create services and applications that fit into users' lives while they are on the go and help them manage their lives from anywhere.

Q. What are the challenges to using LBS in a mobile application?

A. The biggest challenge is that people simply aren't in GPS coverage most of the time. A recent study by Intel showed that consumers are in GPS coverage for about 3% of the day. Also, the large delay to get a first fix and the large battery drain to keep GPS active limit its use on the mobile platform. A typical phone will die in about four hours with GPS turned on and typical times-to-first-fix hover in the minute range. However, all is not lost as GSM Cell ID provides zip-code level accuracy and is always available at no start-up and no power cost. Systems like ZoneTag and Place Its are already taking advantage of this functionality and more and more applications will likely turn to Cell ID as a means of enabling LBS for the 97% of the day that people are indoors or otherwise not able to get a GPS fix.

Q. What trends so you see in consumer demand for North America?

A. As more consumers add data services to their mobile plans, a need for applications that connect users back to their world will become increasingly important. Mobile GMail and Google Local Mobile are just the start and consumers will want ubiquitous access to a variety of IM services, photo sharing, and all of the web 2.0 content that they and their friends are creating. Just porting web pages to a mobile format won't work as the mobile's interaction paradigm requires a different sort of interaction – an interaction that's easy to implement in J2ME. Google and Yahoo! are some of the first companies to realize this and make the move to J2ME, but all companies that provide content or social interactions on the web should take note. The next big demand is the demand for data and connection to others.

Q. Nearly every Motorola phone these days seems to have a camera. What can the camera be used for besides just taking pictures?

A. Cameras are an interesting tool for novel interaction techniques. Students in my class at MIT used the camera to navigate a list with gestures. If a user pointed a phone upwards, the camera could detect this and move the selection point up a list. If they moved the phone downwards, the selection moved down. Another group in my class used the camera in a game to place a user in a particular environment. If the majority of the field of view of the camera was blue, a user was transported to a water scene. If it was brown, a desert. Green, a forest. These two examples show that there are a lot of opportunities for the use of a visual sensor on a mobile device.

Besides novel interaction, cameras can also help access related content to a physical display. All over Japan, QR 2-D bar codes allow people to see movie trailers when they photograph a code on a poster on the street, find out information about bands that are performing, or even buy a soda. Cameras thus provide a simple entry point from the physical world to the digital world.

Q. Do you have any examples of applications that you believe do a good job of integrating the capabilities of a mobile phone?

A. ZoneTag is a project that Yahoo! Research Berkeley and Motorola Labs built last year. The basic premise is to take a photo on your mobile phone, tag it with location and location-derived tags, and upload it to Flickr with those tags. The J2ME application for Motorola phones integrates camera functionality, file system access, GSM Cell ID for location, and data services to get tags and upload content. It's multi-threaded so the tags for your current location are always available without waiting and it uploads photos in the background while the user is free to browse other content. Another nice touch was the way that we integrated the file system. If the user launches ZoneTag after taking a photo in the native camera, we find that recently captured photos and suggest that they be tagged and uploaded. This way, even if a user didn't have time to open up ZoneTag to take the photo, we could still get it up with limited user involvement. Finally, we created the application so that it scaled backwards to earlier phones that may not have a camera API by including this filesystem functionality. This way, the same JAD/JAR could run on multiple platforms.