New Mobile Tech Reviews & tidbits

A couple of interesting posts reviewing new mobile technologies:

• (From MobHappy) Strand Consulting is one of the analysts who really get mobile, so it was interesting to read over at 160 Characters their take on the current 7 most overhyped mobile technologies. I found the comments on UMA, mobile advertising, mobile interenet really interesting. Further isn't it interesting that IMS didn't make it to the list? is it not overhyped anymore or was it never overhyped (back in 2004?) :-)
  

• Check out this LinkedIn survey on "The next 'Killer App' in the Cellular World". It is by no means a comprehensive survey, but many people there think that location aware services are a good candidate. I personally think that like UMA and other services it is still too complex for developers and subscribers and people would still rather get the dashboard GPS unit than figure out the on-phone service
  

• Throwing tidbits, I was really happy for RIM with this recent ABI Research that reported RIM's Blackberry Smartphone market share increased to 44%. To those who were quick a year or so ago to call the Blackjack, Moto Q and others 'Blackberry killers', I said (and still do): the Canadian folks are just so talented, they will leave everyone else in the dust. Just think of the recent devices: the dual-mode 8830 that does so well to the US operators with business users who so far had to exchange phones on travel; the WiFi enabled consumer-features-loaded 8820, and soon to come Pearl 2 ('Komet')...BTW, knowing RIM from when their stock was in the one-digit range, I can only congratulate my friends over there on the unbelievable stock performance

Mobile Code Scanning stuff:

• Gregory Ng, writer of iPhone Matters, has an interesting post on iPhone Mobile Code Scanning. I wonder where this could go: iPhone does not exactly follow all other vendors rules in that it could set the tone for which technology to use, and what might be good use cases. I suppose Apple started receiving emails from code scanning players :-) Good luck Apple!
  

• Last tidbit, the pondering primate reports a new player in the mobile code scanning scene named Mova Media. It wasn't apparent immediately what is the symbology they've chosen to use (I admit I've not spent too much time researching) but what I like about their approach is that it seems to be services-oriented rather than technology oriented. I very much support the approach that useful, valuable services drive adoption as opposed to technology
  

Mobile Code Scanning: Planning (an operator) launch

I've now written a number of posts on mobile code scanning, explaining the factors that make a difference as one is planning their preferred solution.
In this post, probably the last in the series, I will make a couple of points that I think are important to keep in mind as an operator is readying to launch their code scanning campaign.

BTW, if anyone thinks there's a topic or question that you would like some coverage on, let me know and if I can, I'll be happy to take a shot at it.

So looking at the launch, here are a few factors that I'd recommend keeping in mind as you ready to launch the service:

• Demonstrate Value: The one most critical factor is what will drive people to try this new service. In most cases (see later) people will need to go as far as getting the reader application onto their phones. Make sure the offering is compelling and is NOT code scanning in itself ("nobody wakes up in the morning to scan codes"). Whether it's linking to a cool youTube video, participating in a contest or whatever, make it compelling
• Surprise, don't overwhelm: You will want to demonstrate how code scanning is easy and useful. That's what will drive future compelling use cases. But for now, keep it simple: choose a service everyone is familiar with (for example: consuming content using short code SMS) and demonstrate how easy it is to do with code scanning. Alternatively, choose an "obvious" use case: connecting to content on the web ("would you type that URL otherwise?") and use that. The greatness of simplicity
• Large audience: Make sure you enable as many people as you can on launch. Every user who will see their friends using it and won't be able to might not be as friendly anymore. Perhaps they will upgrade their phone but don't count on that being the common case. If possible, provide an alternative to the unsupported audience so you can keep them as your allies. The large community feel about it has its positive implications
• Make it easily available: Especially on the days of the launch, increase the code reader distribution efforts: enable short codes, have an effective WAP distribution site, remove barriers to get the reader. if possible have representatives (in events, see later) helping people get the reader and get to use it
• Promote it: This one is not code scanning specific, but every new service justifies good PR, putting together the web site that promotes the service (and people can create their own codes), 'tipping' press about it beforehand, a very important feature is to create a high-profile event to launch the service etc.
  

I think that keeping these factors in mind will help subscribers understand, get excited and adopt code scanning as means to connect to services and content. Hopefully there will be so many code scanning programs that we will not remember how life was before it, that the web will be present on our mobile phones (in a positive way) ubiquitously.

I hope you found reading this post useful, thanks for reading and I await your comments.

Mobile Codes Motivation

The email briefs on wireless are reported today that Sprint will spend $5B on WiMAX "buildout"($2.5B in '08!).
Hearing such a number I halt for a second: $5B... Not that it is so dissimilar from other infrastructure investments like IMS, 3G, LBS and many more, but still an impressive number. Specifically in this case, they are building the wireless IP network for services and content, which will require further development and marketing budgets. You would find all over the web different quotes on the (lack of) returns on wireless IP network investments because there weren't enough compelling services and content to drive subscriber adoption: "The Current State Of The Mobile Internet Is Disappointing For All Stakeholders" (Source).
(As a side, with a promise of "Sprint has stated that it intends to deliver service at 2 Mbps to 4 Mbps to its customers with Mobile WiMAX." (Source), we can begin thinking of WVOIP, but lets leave that aside, I can't believe Sprint are making the investment based on WVOIP alone).

So the network will be available, the pipes will be wide enough, and the NFL games will just be waiting to be seen. What would motivate subscribers to actually consume the services? or rather, what would change things from the subscriber standpoint??
I suggest that what could change is the accessibility to those services and content, simplified by mobile code scanning. These can bring the returns on the investment this time around. Let people connect in a click to content, to their bank account, to mobile purchasing, coupons, loyalty, ticketing, networking its all doable. Make code scanning happen and it will show the returns you were hoping for. Here's a great article that speaks to the potential of mobile advertising and state of things.

Mobile Codes Blogsphere

In addition to the great market news and vendor list provided by the pondering primate, Jump! Mobile in his blog has a post with all the blogs that discuss mobile code scanning. there are vendors, marketers, mobile social networkers and much more. Excellent stuff from Jump! Mobile.

Let me quickly repeat the list of mobile code blogs for convenience (from Jump! Mobile):
Rex's blah blah blah (Chinese) - One of the most informative introductions to 2D barcodes and with great industry insight.

The Pondering Primate - Probably the blog that coined the term "physical world connection", always up to date on the latest developments on mobile barcodes.

QR Code Blog (Japanese) - Though discontinued, the blog's attempt at blogging with QR Codes is still quite interesting to see.

All About Mobile Life - Kaywa expert's blog always has something nice to share.

Bar code Insight (Chinese) - Observes the mobile barcode developments happening in Mainland China.

Tommi's S60 applications blog - Developer at Nokia shares views on mobile barcode applications.

GSMBLOG.net - Has an in depth review and comparison of various 2D barcode readers.

David Harper's Different Things - WinkSite founder introduces QR Codes.

BeeTagg Mobile Tagging Blog (Swiss) - BeeTagg's official blog.

streetstylz - NeoMedia's official blog, I think.

Make a Difference - Blog by NextCode's director of product management .

ShotCode Blog - ShotCode's official blog.

http://semacode.org/weblog/ - Semacode blog

http://www.semapedia.org/wordpress/ - Semapedia blog

http://barcode20.blogspot.com/ - Olivier Attia blog - Founder of Scanbuy

http://blog.announcemobile.com/ - Jeff Mould blog - Founder of Announce Mobile


Enjoy!

On Mobile Codes Standardization

I am being asked about how can vendors contribute to the standardization initiative, the new Mobile Code Consortium (MC2) .

For starters, I believe everyone identifies the threat, being that the market becomes fragmented by numerous code formats. Recognizing that brands and advertisers will drive this market, that fragmenting this market by code formats would prevent them from engaging this space is essential. Anything other than a ubiquitous user experience, regardless of codes and hardware will be unacceptable. I strongly recommend reading through Publicis presentation here.

Let me add a quick note here that I will avoid the discussion of whether MC2 is appropriate or not (as can be found in numerous places on the web).

In consensus that the MC2 initiative is essential and everyone in the space should support it,
the question becomes (IMHO): what are the issues that are realistic & appropriate for discussion and agreement in this context? Reading through the Mission Statement and the Standards Discussion here are the 3 issues MC2 is proposing to deal with:

• Visual and Encoding Aspects (essentially dealing with the code format)
• Data Aspects: Formatting the code content
• Behavioral Aspects (The code reader UI behavior)

I would suggest that at least for now, the symbology itself should not be on this list. The reason being is that there has not been enough evidence from the market place as to code-format related factors that drive adoption. The argument that standard codes have reach challenges because of optics issues on out-of-Japan phones is a temporary one. With that in mind, trying to define the new standard symbology will be based on vendors making the case for their proprietary code format based on their vision, experience and ego. That's not very effective. The market needs a prompt definition and there are two appropriate, well defined solutions out there, we should be using them (at least as V1.0).
In the same spirit, I think that the last issue on the MC2 initiative list, dealing with the code reader UI behavior, is to be left to the vendors to design and differentiate. MC2 should be able to define the functional behavior the reader once it scans a particular code but when it comes to UI, vendor should have the freedom to differentiate through a nicer screen and more flexible options menu.

Let me propose a few ideas that I think would be useful for MC2 members to make progress on:

• Ubiquitous standard symbologies support with optional proprietary codes: Agree that the industry needs a standard that every code reader will support. Those codes should be QR, DM or both. No point in arguing the code formats issue. All vendors that want to be considered need to support standard codes, and can add support for more codes, like their own proprietary format and maybe others. Operators and brands can then choose the solutions they prefer. Consumers will have the ability to decode the codes and use them regardless of the code reader they are using
  
• Define templates for the code content: This is, IMHO, the space at which MC2 can contribute the most. Assume a vendor supports QR, there is no definition today to what might be the code content, it could be anything. By defining the templates, MC2 would enable a structure that would provide acceptable, expected user experience, flexible use cases and the grounds for operators and brands to monetize on. MC2 can make this along term initiative such that defines the formatting for new use cases
  
• Data Aspects of more complex usage: This is an advanced discussion of the previous point but equally important: some use cases would require extra control and flexibility, that should be supported by the code content. For example, in the case of direct mobile payments, some fraud detection and prevention data might be embedded into the code and should stay hidden from the user. MC2 can make this happen by defining the structure of those codes generally, and then vendors or operators can go in and refine the details in their specific solution
• Introduce "licensed" codes schemes: one of the bigger issues of using standard codes for B2B, for example, is that anyone can read and reproduce their codes. In similar to IP address allocation, MC2 can take the initiative of allocation certain 'address space' for specific usage such as privately licensed prefixes
• Standard Symbology V2: by the time MC2 was able to facilitate all of the above, there will be as many members and activities in the marketplace to suggest what factors in the symbology drive adoption. At that time MC2 can begin defining future ("V2") symbologies and facilitate standardization process and encouraging vendors to adopt them

In viewing this list, I think that one of the strengths of it is that these all are achievable items in a measurable time frame. There is not much room for subjective arguments in any of them and so the process could be very effective.
By moderating an effective discussion MC2 could become the parallel to other centralized bodies like OMA (Open Mobile Alliance) and in that attract various players from the space to join.

I hope that was useful, thanks for reading.

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!