Musings on Mobile Instant Messaging

I've just posted a reply to a question on ecademy Mobile Applications Club, and decided to repeat it here.

The question was more or less: "what does it take to implement an Instant Messaging client with Presence on a mobile phone?".

So here it goes:

So how could the phone improve and take on some of the characteristics of an IM program? I'd *really* like a Skype client on my phone, not for VoIP but for text and for the contacts list. This feels do-able to me mainly because the bandwidth requirements are pretty low. But of course it would cannibalise the *huge* business cash cow of SMS.

The idea is great, and the question might actually be music to operator's ears as it shows the value of enriched messaging.

What you are describing, is a PEP - Presence Enabled Phonebook integrated with Instant Messaging. Instant Messaging, Presence, and any number of combinations will be there in the nearest future as soon as Mobie Operators accept IMS and come up with IMS-enabled services, and mobile phone manufacturers will incorporate IMS platforms in their devices.

Meanwhile, there's a number of proprietary mobile messaging clients out there (e.g. Agile Mobile messenger), which will probably, to certain extent, fit the bill (not on feature phones though).

There are several obstacles in implementing mobile instant messaging.

Unless you want limited P2P application to talk with your buddies, and you know what phones they are using, the client has to be either J2ME application or Symbian application (do not forget the flavors), or both. Also the client could be browser based, but it would be awkward and will have higher overhead unless you do it using ajax, which only is available for Opera 8.6, which only is available to Symbian and Windows Mobile based devices.

Then, depending on the device, the client might not be able to run in the background, which limits usability.

The major attraction of sms is that as soon as the phone is up and running - you can have messages being pushed to you. If you build your own client - it has to be started manually and, depending on the device, might not be able to run in the background.

In any case, a client has to be optimized to major mobile phone platforms you will be using it on.

Ok, now to presence. Presence has to be a server-enabled solution to aggregate user profile and presence information. It can't be pure p2p unless some of the nodes (clients) act as intermediate nodes to broadcast this information to their local swarm (similar to p2p systems), but that will put additional resource (and traffic) burden on the client.
Presence puts also additional traffic overhead as the client has to publish its status to server during startup or status change, and then it would be getting notifications about the state (change) of buddies in the phonebook.

Then, you will have overhead on actual messaging traffic since it has to use some protocol and mostly those protocols were designed for internet without keeping in mind optimisations suitable for mobile side.

Still, it's pretty doable, though not very easy. If the messaging traffic with all overhead per message (how many characters?) is cheaper than cost per sms (15 cents outgoing, free incoming for local traffic in Canada) - then it will make sense. The only problem, like I said, would be how to keep a client running (to get notifications) and if not - then how to get message notifications.

One of the solutions would be for an application system (server) to send a wap push to the phone, but wap push is essentially just another sms (and it will cost to the system to send it).

Open source protocol for messaging (and to my understanding - de facto standard for internet systems) is XMPP.
As it is xml-based, there will be quite an overhead on the traffic.

It's funny: just looked up an example XMPP dialogue. To send a 37 character message (including subject), will require to have an approximately 736 characters (linefeeds are counted).
Well, actually it's not bad at all! I figure I'm paying 5 cents per kilobyte - so this traffic will cost me 3.6 cents, which beats the ... out of 15c per sms.


Technorati Tags: Mobile, Instant Messaging, IMS, SMS, XMPP

powered by performancing firefox

Mobile Monday - now in Canada

It was good to find out that Mobile Monday event now has a base in Toronto.

The next meeting features speakers from Google and Yahoo, who wil be focusing on (take a wild guess!) ... Mobile Search.

The write up for the next October 2-nd meeting is available here.

Very nice that things are speeding up some in Canada. Too bad nothing's happening here in Sunny Montreal.


Technorati Tags: mobile, search, canada

powered by performancing firefox

Mobile P2P around the corner?

Probably not exactly, but this would really be cool!

Swedish startup Terranet has developed mobile Peer to Peer technology.

By integrating a hardware module in the mobile phone or adding it as an add-on accessory, a direct radio communication becomes possible within approximately up to 5km range between individual mobile phones. Without base stations or any other operator infrastructure!

According to Sydsvenska Dagbladet, the price level of an extention unit (either integrated in the mobile phone or as an add-on accessory) is estimated around 500 Swedish Crowns, which translates in roughly US$69.

If I am reading the site correctly:

TerraNet integrates seamlessly with standardized wired and wireless VoIP solutions. Customers are the world's leading VoIP operators and broadband providers and developers of mobile phones and/or walkie-talkies. End users are people who would like to make free mobile phone calls locally and to the entire world.

the technology seems to be some kind of WiFi flavor.

It would be interesting to see the power consumption of the resulting unit as a mobile phone should be usable at least one day. Still, the idea is very interesting. It will allow to bypass mobile operators in some situations affecting their traffic. It definitely could hurt service like Push-to-talk over Cellular for typical use cases like a family communicating in the mall.

The technology will not always be useful, but has the potential to harm operator traffic if a peer user density is high enough, e.g. in large urban areas.

Is dotMobi a marketing exercise?

A friend called me today with a question whether he should rush to register a '.mobi' domain or not.

This prompted me to check what’s going on with the dotMobi thingy and turned out that they’ve just announced a general availability of '.mobi' domain names.

Now, I would not engage in a question of whether or not it is a scam, but what interests me is: what’s the point?

There are 3 points that dotMobi initiative is making:

1) They kinda herd the “mobile adapted” content into a separate domain
2) They develop guidelines on how this content should be developed to be optimally presented on mobile devices
3) Combination of the first two: they enforce that '.mobi' sites adhere to the guidelines

Let’s look at these points:

Point (1) – theoretically there’s nothing wrong with designating a dedicated domain for specifically designed content, except:

1) It kind of implies that all other domains will not be adapted to mobile device presentation.

While it is absolutely true that other domains do not guarantee that the content will be viewable on your mobile phone, still it could be pretty well adapted. I personally do not like this implied limitation. As everybody knows, Opera mobile browser does a pretty good job in adapting content to mobile screen. Also, there are and will be people who adapt their existing sites or applications to mobile presentation, and they probably also will not like the '.mobi' implied exclusivity.

2) There is no guarantee that sites in '.mobi' domain will come up with content compatible with all mobile devices, though the chances will be much higher. Anyone who participated in OMA test fests can attest to that. Will dotMobi verify and approve (i.e. enforce) that the sites stick to the guidelines? They mandate it, but enforcement is another matter entirely.

Point (2) – There is also nothing wrong with developing guidelines and best practices for mobile domain. My problem is that their guidelines are mostly copied from W3C Mobile Web Initiative.

Now, we already have W3C Mobile Web Initiative, W3C Device Independence, and OMA (Open Mobile Alliance) Browsing standard, which overtook the now obsolete Wap Forum. Why do we need another set of guidelines, which is basically copied from existing ones?

I would say any serious developer will probably first check the target mobile phones browsing guidelines (one for each phone manufacturer), then come up with a set of standards to adhere to (which would most likely be xHTML Mobile Profile anyway with a possible look at OMA Browsing), then look up W3C Mobile guidelines to do usability sanity check.

And now the most curious thing of all: '.mobi' does not really adhere to their own (or should I say W3C) guidelines. Specifically, in section "4.2.5 User Input" of the "dotMobi SwitchOn Guide" we read the following :

"[W3C MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum."

Ok, try to input ‘mobi’ into the browser using your mobile keyboard.

‘m’ = 6 (good), ‘o’ = 666 (not good at all), ‘b’ = 22 (also not very good), ‘i' = 444 (well …). So folks, it’s gonna be 9 strokes in all. Factor in that on majority of mobile phones, after hitting ‘m’ you will have to wait couple of seconds for the input to sink in before hitting the same key (6) again three times for ‘o’. Otherwise your initial ‘m’ will change to ‘n’ and you will have to start over.

Now, just to type in ‘.net’ will require only five strokes (66338) and ‘.tw’ only two (89).

Point (3): Also good point in itself. While the use of the guideline is mandated:

"Compliance with mandatory rules is one of the terms and conditions of using a .mobi domain"

it is not clear how this rule will be enforced and how exactly a candidate site will be verified.

So, while there are some valid points behind the dotMobi theory, it pretty much looks as a marketing excercise to me.

I personally will not be registering any .mobi domains any time soon. What about you?

go to main page