Thu Mar 24 07:27:55 EST 2005
Here is yet another example of how immature the mobile space is, and unfortunately another example of how carriers and device manufacturers have made decisions for reasons that simultaneously baffle and frustrate the developers who will be making the very mobile applications that will drive the sales of devices and data services. I can’t leave the J2ME standards body out of this equation either, as I feel that they also have a role in making standards that insulate developers from things like this.

Somewhere after the V600, Motorola decided to almost completely change the numeric keycodes that its handsets generate for keypress events in J2ME. Here are the keycodes generated by Motorola J2ME handsets prior to and including the v600, versus the keycodes for all handsets produced after the v600:

At first glance, it may seem fairly insignificant that they simply changed all the signs from positive to negative but this creates several significant problems for developers who are trying to realize the (admittedly near-impossible) promise of write-once-run-anywhere code.

First of all, it means that code written for previous generations of Motorola handsets will no longer function properly on their new handsets. This requires developers to make changes to their code and re-test on both new and old handsets just to ensure compatibility with Motorola devices.

Second, and worse yet, Motorola’s new keycodes actually conflict with the keycodes used by other device manufacturers. For example, here is a subset of the current keycodes used by Nokia Series 40 and 60 handsets:

Notice anything alarming? The new keycodes chosen by Motorola actually conflict with those used by Nokia Series 40 and 60 devices! In the previous example, it was still actually possible to write a single switch statement that would correctly handle both old and new Motorola keycodes (via absolute value or simply hardcoding both sets of keycodes into the switch statement). However, given that the keycodes from Motorola and Nokia now conflict, it is impossible to write a single switch statement. As a developer, you must now build into your application additional knowledge about the device on which it will run, or build a mechanism that allows your application to determine this at runtime and use the appropriate keycode set. In my opinion, this is an incredibly irresponsible choice by Motorola, and makes a statement about their attitude toward developers, but also points to weaknesses in the J2ME standard.

Third, building on the two points above, the lax J2ME standard coupled with decisions like this made by carriers and device manufacturers further erode any hope of write-once-run-anywhere, and force developers to spend time and resources to engineer solutions that will insulate them from seemingly arbitrary changes such as this. Instead of simply coding to a J2ME-defined set of constants, developers have to concoct additions to their build scripts, or create inheritance abstractions to deal with the would-be simple problem of descriminating user key presses.

Let’s close our eyes, and visualize a world where we can actually imagine what “Emerging Technology” is in the mobile space. This is a world where developers focus on the ways that a mobile phone is changing the patterns of socialization, play and communication. This is a world where we enhance, not burden.

The mobile space is excited when we read things like this from Pew Internet Research:

“The proliferation of cell phones and the spread of text messaging are changing patterns of commuication for many Americans — espeically younger ones,” said Lee Rainie, Director of the Pew Internet & American Life Project.

I spent a great couple of days last week down at the O’Reilly Emerging Technology Conference. Despite being impressed by many of the presentations and the great people (Coverage here.), I walked away with a clearer understanding of the challenges that are facing the mobile industry, and what’s keeping us from focusing on the excitement and opportunity of mobility.

Here’s my list of challenges:

Network
All of us trying to develop in the mobile space right now are very aware of the fact that US carriers, and carriers in general, are keeping network access under tight control, either through tight technical controls like port blocking, or through high data rates. There’s a lot of good reasons for this: mobile spam and untested application crashing phones come to mind immediately. The downside is obvious, a great idea might bubble up, but who among us afford the cost of network access across all the carriers to actually implement the idea? Who can even swallow the cost of network access for testing across all the various handsets? Not even WAP browser implementation is consistent across devices.

Were you thinking about connecting your phone to your PC to use as an SMS gateway? The SMS aggregator Clickatell recently released this regarding US carrier policies for SMS.

US carriers are saying:

All messages being sent to the USA will now need to have a registered shortcode as the Sender ID.

What does this mean if you just want to “release” an application for mobile phones that has an SMS component?

Distribution
With all of the challenges of getting connected to the mobile “network”, it’s no surprise that another bottleneck is distribution. Once you have a great product, and you’ve spent all your money on testing the application, how do you get in touch with your users? Can’t they just download your application? Maybe not. Carriers and their publishers have the keys to the getting your application on a list where your users can see it. I have great hope that Ringtone portals will start to put pressure on Carriers in other ways. WAP might provide an opportunity to get around the carrier control of the deck, but how long does your URL have to be before people start being fustrated about typing it on their phone? Nokia phones have support for Python, but Carriers are still in a position to isolate those applications to your phone, and prevent you from sharing.

Demographic is Everyone
This is a design challenge, pure and simple. This issue highlights the challenges of designing applications for people who are used to just opening a phone and making a phone call. How do you design for a device that is as intimate as a mobile device, a device used to play and communicate? Everyone talks about casual games, but the industry is still excited about mobile 3D games?! We are only starting to understand what mobile design means: Chris Heathcote and Matt D. Jones from Nokia both spoke of “social legibility” as one of their goals.

It’s hard to imagine that network and distribution challenges will be around forever, but these hurdles add up to provide significant barriers now. How can we over come these distribution and network hurdles for effective application development up through a product launch and support?

Oz Communications demonstrated picture messaging through their mobile IM client at CTIA in New Orleans. According to the businesswire press release:

The OZ Mobile IM Client with AOL’s new Instant Pictures feature enables AOL(R) members and AIM(R) users to use their mobile AIM service to send instant pictures to friends and family members using mobile devices by simply inserting an image into the AIM(R) conversation. Recipients see a thumbnail image on their mobile AIM(R) screen that they can click to expand. They can then reply with their own mobile Instant Picture for a fun picture sharing experience with anyone and everyone on their AIM(R) Buddy List(R) feature

It seems that T-Mobile, Cingular and Sprint in the US are customers of theirs. Given that, we have email and IM that can easily deliver pictures across carriers. Plus, I’m assuming you can send the same pics to IM users logged in from their desktops.

Where does this leave MMS, which can’t operate cross-carrier at all now?

Yes, MMS has sound and animation. But I think the tedious process of composing a fully animated and sound-enabled MMS outweighs the draw. However, the process of sending a picture through IM could actually be easier than sending one to flickr or textamerica if you already have a chat session open. No email address to fumble with.

Perhaps the moblogging sites could use IM as a new input mechanism?

Like most other people in my demographic, I’m seriously excited by the Sony PSP. But that’s no big shocker.

If you read most other enthusiast sites, you’ll come across mentions of the PSP enabling MMORPGs played from coffee shops - persistent, console-quality online worlds you can access anywhere wirelessly. It almost harkens back to the old-skool Gibson cyberpunk style of “jacking-in” to a virtual reality representation of a world wide communications network. Yeah, we still don’t have that neuro-silicon linkage yet (though MEMS research is starting to get somewhere). But at least the PSP brings the ability to represent an artificial reality in a convincing way.

In the meantime, where do mobile phones fit in with this? They are our persistent connectivity devices, and they are now trying to catch up with the power of the PSP. Some are getting close. But will these 2 classes of devices merge together as PDAs and mobile phones are well on their way to doing, or will they remain separate? Regardless, the big question I want to figure out the answer to is:

What types of games and applications best serve each class of device (handheld console and mobile phone) now that have the ability to evolve and thrive in both the case where the classes merge and where they do not?

No doubt the PSP is going to blow cell phones away in game quality and technical complexity for the medium-term. However, ponder this: Rumors have been around stating that the PSP will receive a web browser and email client in a future firmware upgrade. If this happens, mobile phones and PSPs will share these capabilities, and developers could use this to their advantage. Sure, these display mechanisms can’t shake a fist to a native PSP 3D application, but sometimes you don’t need fancy graphics to make a very compelling product.

I’ve got my product ideas, do you have yours?