Wireless Wonders

No news, just comment about mobile phones and services, from a veteran practitioner...3G, GPRS, WAP, Bluetooth, WiFi, etc...

Saturday, February 11, 2006

SIP in my browser (idea #76)

In the world of IMS, which is SIP-based, there is a confusion over client implementations. Some companies are emerging to deliver what they call "IMS clients", which is really a strange idea, but it is easy to see why this has happened. These IMS clients are mostly a bunch of apps that will run natively on the phone and deliver some of the early "enabler services" that the IMS world touts, such as Instant Messaging, PoC and presence-enabled phone books. There are a variety of simple use cases around these themes that tend to get bundled in. Adding an SDK to the mix allows the whole solution to become a "client", as other IMS services could potentially be delivered.

Out in the web world, things are moving on in parallel, as the communications model is still firmly HTTP-centric and there is no consideration for SIP, except in some instances that utilise a network-based SIP-HTTP gateway.

However, there is no need why this should be the case. The recent excitement about AJAX in the web world could be made even more exciting by embracing SIP. There's no reason why AJAX messages coudn't run over a SIP stack. This would allow a more elegant interface into SIP-based environments. Of course, AJAX can also run over HTTP and both can take place side by side.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

Browsers versus apps...

Currently, the architecture of the two approaches is very different. With apps, all the processing logic is on the device. With browsers, especially WAP ones, only display logic is on the device - the business logic is on the server. Whilst it is tempting to think that a fast and reliable link between the client and server does away with difference, that is not the case. Apps are based around programming languages, whilst browser services are built around mark-up languages for historical reasons i.e. browsers are originally built around a document-centric model, not an app-centric model. Actually, "application" in an increasingly generic term that can cover web and embedded use cases, but let's use it in its historical sense.

The efforts of the Web Application 1.0 group recognises the limitations of the docu-centric model and are trying to introduce features into the web world that allow a richer app-centric set of use cases to be realised in the browser model. This work is the driving force behind the Opera Platform.

Now, let's not forget the main concern that the Web world has always been interested in, although we tend to forget it, which is the portability problem, which has been quite rightly pointed out is the thorn in the side of MIDP programmers. A browser is a universal client - one client for many services (i.e. Amazon, Google, etc.). This has never been the case with apps, where there is really one app per service (Excel for spreadsheets, Word for docs, etc.)

To do some really interesting stuff with mobiles, eventually one has to start playing around with the kinds of enabling services and user data that are currently tied very tightly to the device, such as the phone itself (i.e. "telephony API"), the phone book, the text messages and the "messaging API" itself, the call records, the SIM card, the calendar, the Bluetooth stack, the media player, the file system and so on.

Until now, these embedded services have been of interest to the traditional apps community, who concern themselves mostly with APIs. The browser community has not taken much notice of this, except with some vague ideas or proprietary solutions here and there.

The Opera Platform is concerned with these embedded services and has sought to abstract the native APIs from the browser via a set of Javascript APIs via an extended Document Object Model (DOM), which is perhaps now a misnoma and should be renamed POM - Phone Object Model (although people don't know what to call these personal devices anymore - see other threads in this forum).

Now, there is a bit of slight of hand with what Opera are doing, because whilst they are correctly claiming "open standards" approach - by which they mean ECMAscript, XHTML, CSS and Web Application 1.0 generally, an app programmed in this environment will only run on the Opera Platform, which is obviously what they want.

Even if this effort by Opera become successful, whether through their own efforts or by other players (because there must surely be a response, and I don't believe Opera has gone far enough yet to embrace "next gen" mobile use cases) - the progamming model is still not rich enough to support some apps like games, although it could, in principle, be made rich enough via other "open standards" that could address the rendering issues that are at the heart of any game app.

My prediction is that something like Opera platform will become standard across devices and wilfully so, as the operators eventually will seek to enforce a single "standard platform" (of course, there will always be more than one, but not the "hundreds" of variants that plague MIDP implementation). The increasing size of trans-national operators will allow this to become a reality. Operators aren't really there yet because their revenue models aren't centered upon apps, so resources simply aren't focussed on this issue.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

Monday, February 06, 2006

Cheap milk on my mobile...

Over on the Oxford Uni. next generation mobile apps forum, the question posed by Russell Buckely is what would it take to get users to sign-up for location-based ads. Some commentators think that "cheap milk here" ads from the local Tesco Metro won't ever make it. The future of loc. ads is special promos to the audience of a pop concert etc. Personally, I disagree - and if it's cheap milk versus Madonna wallpaper at her latest concert, I'll take the cheap milk....and here's why...

Firstly, a general point to make about location-enabling is that none of us has really experienced it. The reason LE apps haven't taken off, or aren't likely to, is because they're simply unusable in most networks - the accuracy is poor. I have argued since its inception that only GPS accuracy is going to work along with proximity-based services indoors. Once people become exposed to hyper-accurate services, they will not want to give them up.

By the way, I remember sitting through one of those boring operator developer forums and watching a presentation about how accurate LBS needs to be. Quite unbelievably, they did a survey and asked what kind of accuracy would you like....etc. They concluded with the answer they actually wanted, which is not to go spend money on GPS-accurate systems because no one has asked for them. That's taking paper studies too far! Sometimes you've got to give the service to the user and then ask for feedback. I am convinced that highly accurate services of all kinds will be compelling. Many LE services, including many ad-based ones, only come alive with highly accurate proximity sensing outdoors and indoors. I believe there are many compelling use cases, including "cheap milk".

So, now for the "cheap milk" argument. I believe 100% that this is the future of LE because I believe that the long-tail model fits here. It doesn't matter if there aren't 100,000 Madonna fans who want sell-off milk, just as long as there's enough. What's enough? Enough means that the price of advertising is less than the return. For example, if Tesco Metro can spend 5 pounds per store advertising day-end sell-offs and make more than 5 pounds - they're definitely going to do it because a lot of more-than-5-pounds adds up. Those of us who think "cheap milk" is spam, won't sign up. But to Tesco stores, that doesn't matter, as long as the economics still add up, which in the world of "pay per click" ads, it surely will.

That's perhaps not long-tail enough. What about the local plumber? If he can advertise that he's available in your area today (and God knows that plumbers are hard to find in any sense of the word) and he pays ("bids") 5 pounds for that hit that makes him 100, then he's going to do it too.

The problem with all this - and I've been writing reports for various customers about this for years - is that the cost and complexity of placing localised ads is currently prohibitive. There are all kinds of "messy" IT problems to solve . Take the Tesco example again. They will need to plumb their in-store inventory/EPOS system into the "ad service" and pipe that through the operator's network, including - probably - a revenue share back to the operator and so on. Average cost of such a project might be thousands of times the cheap milk sell-off margin over one year (or whatever ROI period accountants use these days).

Operator networks are by-and-large cumbersome telco networks, not nimble edge-of-network web servers and the like. However, that revolution is coming, albeit slowly. Operators are moving towards a Services Orientated Architecture (SOA) where eventually their whole business will be one big "software application" accessible via the net (web services etc) - as will Tesco and others. It is difficult to appreciate the benefits that SOA promises - and even operators don't really understand the transformative possibilities - but one of them is how previously very complex business rules and the expensive IT required to implement them will be as easy and cheap to implement as clicking a few mouse buttons. So, if the local BMW garage want to beam you an ad for a car that they already "know" you've been looking at on Froogle then they can implement that app/ad for next to nothing.

Many interesting mobile apps in the future can only come to fruition with this sort of complex multiple operation/business logic underneath. I believe that what we are headed for is a different question than the one posed by Russell. People will ask "why wouldn't I want location-based ads?" "Hello?" I suspect that Google already know this.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book