Fixing Mobile Messaging

SMS is a fantastic service for person to person communication, but just about every other aspect of it is broken. Lately I’ve been paying a lot more attention to messaging because of the mobile web. It’s a current area of drastic disparity between native apps and web apps on mobile, and something that keeps folks tied to a particular platform. SMS sucking is why we have cloud to device messaging for Android and iOS and BlackBerry specific push APIs.

First of all, I’m going to assume that we’re all in agreement that asynchronous messaging is an interesting thing and a unique value of mobile, as well as being an invaluable hook for the business end allowing us to keep users engaged and active? All in agreement? Yes. Great! Second we have to agree that SMS sucks. I’m going to assume that all the major platform providers having dreamt up their own endrun around SMS to deliver asynchronous notfications is evidence enough without having to delve into the details of the cost structure, granularity of control over who can contact you and when they can contact you, and ability to modify those setting on the fly without having to change your phone number. This, also, I’m assuming is not a huge leap of faith.

Today I was fooling around with Boxcar to send asynchronous notifications out of a web based iPad app. Hat tip to Rob for pointing it out. Boxcar is able to serve effectively as a shim app allowing you to send iOS notifications to opted-in users on behalf of any general web app, and drive the user back into your web app if they choose to follow the notification. Just sign up as a Boxcar provider and you can send iOS style popup notifications via their REST service API. Nice job Boxcar folks, slick service! There are a few clunky aspects related to user experience on the whole, like Boxcar launching into a framed browser to pop up the content and losing the redirect location if Boxcar is already open when the alert comes in (just make sure you always set source_url). It’s good enough for some prototyping however, so I’m pretty happy actually.

But then that got me thinking “Hey, wouldn’t it be nice if Apple just provided some OAuth style interface to allow iTunes accounts to opt into getting push notifications from web sites.” That one is actually pretty simple, and would be a fantastic boost for web apps. And potentially could also give us a way to get update badges updates for webclip icons, how slick would that be huh?

Then I went over to thinking “Damnit, why don’t the carriers provide some mechanism like this to allow for internet-to-mobile messaging without requiring us to go through all sorts of custom APIs?” I mean, should SMS aggregation really be a business? I don’t think so. For all the talk of evolving carriers so that they’re relevant for the next generation of mobile, I would think that figuring out how to API a base service of your network would be on the list of things to do. There’s work to be done to get it going, obviously. You need to tie in number lookup databases to find out which provider to contact, layer in an opt-in for users (just handle that via SMS too – “Reply to this message with ‘ok’ to allow rowehl.com to text you”), and some kind of messaging dashboard to allow users to tune or adjust setting on a site by site basis (at least if we’re going to bring things to some degree of parity with state of the art).

It’s certainly nothing new that I complain about messaging to devices needing a cleanup. But this time I think the folks with control over the system might have some interest in fixing it all well. Carriers/operators, I’m looking at you. Concerned that increasingly development is moving to proprietary platforms with opaque APIs and inaccessible payment methods? Hoping that now that we’ve got what increasingly looks like at least a two horse race the mobile web might start to come around? Us too. So please, help us out just a little bit, and fix at least one part of your environment so that it doesn’t “suck at the Internet”. Giving us a workable asynchronous notification mechanism for mobile devices would go a tremendous way toward helping folks trying to build businesses based on audience volume. KTHXBAI!

This entry was posted in Browser, Community, iPhone, Technology, ThisIsMobility. Bookmark the permalink.

3 Responses to Fixing Mobile Messaging

  1. Wes says:

    Great thoughts about SMS messaging. I was just thinking about the same thing and how we can use push notifications to send out messages to the people on our mobile site. I think it offers a great opportunity and messaging in a much more elegant.

  2. John Griggs says:

    Interesting post Mike. Had not heard about Boxcar’s API before (heard of them, didn’t know they had an api), but I was familiar with Notifo’s API (similar app/service but seems more developer pointed.. I think?). I wonder if in the long-run Apple/etc will make a more solid notifications management system.

  3. Russ says:

    Good toughts Mike How much of what your looking for is missing from Sprint’s service framework:
    http://developer.sprint.com/site/global/sandbox/sprint_services/sprint_services.jsp ?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">