Mobile: Getting an application on a phone, mobile code scanning implications

One of the biggest challenges that mobile application developers face is to get the application onto people's phones. There is a lot of value in doing that because (to mention some):

• In most cases, the user experience can be much more friendly, flexible and robust (you can take local actions on the phone), and can be tailored to the particular phone
• The applications doesn't necessarily depend on external resources (such as web access or SMS, which may or may not be available) for its core functionality
• The presence and availability of the application on the phone provides better chances of usage than if it would be remote on the web or available through SMS

However, getting an application onto subscribers phones is challenging:

• Reach: to become successful, the application needs to function and have an acceptable user interface on every phone you may want to launch on. Since in most cases applications are subscriber-facing, that means that you want it available on virtually any phone model available. This is particularly true if this is a social application. If all the phones in the world would have been the same, or at least conforming to the same API, that would have not have been an issue. But, just to give you an idea, every single J2ME phone is different. every single one. That means time, effort, cost to procure all the phones and test them (or get access through remote testing services like Mobile Complete and their service Device Anywhere) etc.
• Go off-deck: "Off deck" means that you do not have relationships with mobile operators to promote your application from their "deck" of services/applications/content (which they heavily promote to their subscribers through their channels). Off deck means you're on your own and you got to figure out the following:
  • Marketing and Subscriber Education: Making subscribers aware of the application/service and motivating them to try it, educating them about the value and how to use it
  • Distribution mechanisms: Enabling subscribers to easily obtain the application. That includes creating a WAP portal that will identify each different phone and provide the correct application for that phone. That also includes creating distribution channels like short codes (a bit of ahead ache if you're thinking globally...short codes are different in different geographies), near-range bluetooth is possible etc. you might also consider embedding into your application a "Tell-A-Friend" option so that users can virally spread the word
  • Download and Installation: As mentioned, you will need to build a WAP portal that will identify the particular phone model and provide the right application to download. That WAP site would typically also contain informational pages like extended help content beyond what's immediately available on the application on the phone, supported devices etc. The installation is a key part that needs to go 200% smoothly for subscribers. If you think people are paranoid about installing stuff on their PCs, triple that for phones
    
  One might think that going "off-deck" has the advantage of speeding programs into launch because you don't need to establish relationships with operators. That's not exactly true: you are making use of the operator's services, at least to distribute the application. In some geographies, you will find that operators charge a premium (beyond the standard data or messaging cost) for delivering content or applications, even if those are provided for free
• Go "On-Dec" means that you establish relationships with operator(s) in the targeted geographies. That will simplify your life in terms of marketing, distribution, subscriber education and other aspects of getting the application out there because the operator would typically already have the solutions to do that anyway. An operator would also have the power to pre-install the application on new phones, which removes the application distribution barrier completely. That said, getting an operator to be interested in your application to the point you have commercial relationship is not a trivial task

Once all of those systems are in place one would hope that subscribers would be motivated enough to obtain the application, install it and try it for the first time. The motivation should be very high for a subscriber to go through all these loops...If there was a way to get your application pre-installed on the phone or somehow avoid that step then your life might get simpler.
The bottom line here, I think, is that careful consideration is recommended when deciding whether your application strategy is to be installed on phones.

As an example, for LocaModa, a very interesting startup in the mobile space, some of these considerations guided their product strategy: getting an application on the phone is just too big of a barrier these days. They use the existing SMS channel, that everyone uses and is familiar with to deliver their cool service.

Let's take a look at the implications on mobile code scanning. A solution could be either a local application on the phone, with the capabilities of making use of local resources and applications on the phone to enhance the immediacy, flexibility and robustness of the application. Another way to provide code scanning solution is to have the code decoded remotely. There are several different mechanisms to do that:

• 3G video call: create a video call to a decoder server that will decode images sampled from the stream and will (in different ways) inform you of the result. One company that does that is DSPV
• MMS: take a picture of a code and send it over MMS, the server will reply with a response over SMS, for example, with a link. One company that does that is Mobot. When coming to MMS, one needs to keep in mind that the destination for the MMS requires, again, keying in. In some geographies, operators made MMS-to-shortcode available, however elsewhere the user experience would be to type in an email address when sending the code, and that in itself invalidates the whole usability issue that code scanning is trying to solve. So look for MMS-To-Shortcode functionality in those solutions

Interestingly enough, some companies can provide both services (local application or server based decoder).
There are several pros and cons for going the remote decoding route:

• No need for local application on the phone: removes all the hurdles mentioned earlier, but, also looses the advantages of having a local application (compelling use cases, flexibility, immediacy etc...)
• Campaigns aren't restricted to codes only: Since it is a remote powerful server that decodes data incoming, it could also correlate the incoming images with logos and other marketing material. therefore, you could send in a picture of a Nike shoe and the server may come back to you with a link to that shoe WAP site
• The technology to send an MMS is pretty much available on every phone, and people generally know how to send an SMS (not the same, but similar), hence easier learning curve
  

When considering code-scanning opportunities with brands and ad agencies in a very early market, where not all phones support access to the camera, there are reach and education issues, it may be viable to consider remote decoding options. Sure, this is not the optimal route, but it is an entry point for early adopter brands to get their feet wet and gain innovation recognition. It is an excellent way for players in the space to learn what works and what doesn't for consumers, and for the brands. When the technology will satisfy the reach challenge and other challenges mentioned, the on-phone application strategy would be widely accepted because people used codes and they are comfortable with the idea. Further, they would be happy with the better user experience and new features that will come with it.

Hope that was useful, thanks for reading!