I recently finished the next edition of my book ‘Next Generation Wireless Applications’. It’s a fairly major upgrade and now has a sub-title - ‘in a Web 2.0 and Mobile 2.0 world’. When I first wrote the book, which has become a best seller in its category, Web 2.0 didn’t exist. In the index to the new edition, Web 2.0 has one of the highest entries. It’s fairly easy to write about Web 2.0 and its intersection with mobile, both in real terms and speculatively. However, Mobile 2.0 is still a more elusive concept. I recently suggested to Ajit Jaokar, one of the thought leaders in Mobile Web 2.0, that we really need a conference to brainstorm this more thoroughly with the right mix of mobilists in the room. He says he’s planning something around the new release of his book, so I look forward to that. Meanwhile, here are some of my thoughts. I’ve mostly blogged about them before, but like all things in mobile tech, it seems that we have to keep throwing spaghetti at the wall until some of it sticks (my preferred metaphor to talking about tipping points, which sound so statistician like).

I wonder if we need a new protocol and, in some ways, a new applications paradigm for the mobile in order to solve some current problems and reap the benefits of a Web 2.0-type ecosystem applied to mobile comms. The HTTP/HTML link-fetch-response paradigm has given us a revolution in software services. Where would we be today without the browser as universal client? The bulk of web-based apps have been human-to-content (H2C). However, in the mobile world, the dominant paradigm is distinctly real-time voice and messaging, supporting a predominantly human-to-human (H2H) mode of interaction. It is within this rubric that the browser model suffers.

For those not aware, in the mobile world operators are busy either deploying or thinking of moving to a new paradigm for the future of mobile communications. This is called IP Multimedia Subsystem (IMS). It is essentially a SIP network with extensions to accommodate centralised (and inter-roaming) security and charging models. We can think of SIP as a universal protocol for establishing almost any type of session between two end-points in an IP network. However, unlike the Web, there is no equivalent of the browser. SIP works to control communications, not to present them to the user. It is not intimately linked to a UI model to present the result of SIP communications to the user.

In my view, this is where innovation is needed, to pave the way to a more flexible and powerful platform for mobile in the future, one that blends the best of SIP and the Web in a meaningful way that is truly integrated. It is already possible to create services based on a synthesis of SIP and Web, but these are usually a messy affair programmed on clunky platforms called Service Delivery Platforms (SDPs) and other names. I’m talking about something more agile and open to the garage developer.

New platforms continue to arrive on the mobile scene, such as Android, iPhone, OpenMoko, JavaFX Mobile and many others. Existing platforms, such as J2ME and Symbian continue to add new features, which usually means new APIs. The question we have to ask is where is the value in having so many platforms and disparate device APIs. I’m hoping that Brough Turner will pose this question to the various platform representatives at the forthcoming debate on what drives wireless innovation. It certainly doesn’t make life any easier for mobile apps developers to have a very fragmented ecosystem in which to deliver apps. However, within the current conversation, this type of platform innovation is largely in the wrong direction. Sure, we most certainly needed the breakthrough of the iPhone to show us how well the Web can work on small devices, although we should still note that despite its ability to enhance the Web experience, the best sites - including Apple’s own apps - are still designed specifically for the iPhone.

So where should the locus of innovation lie? As I have mentioned already, it needs to be in the direction of synthesizing H2H communication with Web apps, particularly Web 2.0. I initiated several such projects whilst Chief Applications Architect at Motorola, which got me really excited that there is huge room for innovation in this area. When you start to dig deep around the idea of combining SIP with Web, it isn’t long before an attempt is made to formulate a suitable programming model. For example, do we think of Web apps as becoming ‘SIP aware’ or of SIP sessions becoming ‘Web aware’?

Given that any app will need a container around which we wrap our UI, then the browser is the obvious starting point. In which case, we can begin by making the browser SIP aware. What does this mean in programming terms? Again, we can propose a variety of approaches. To me, it seems more useful not to think of SIP at all, but to think in terms of sessions. For example, what if each SIP session is available as an object accessible via the scripting engine in the browser? This will allow new types of application to be created, although it doesn’t go far enough. The standard link-fetch-response model for the browser will only get us so far in this arrangement because we will presumably have to rely on an asynchronous SIP event as being meaningful within the current Web session. But, what if we add Web events to the new session object model? In other words, I can register a URI(s) with a particular session and trigger Web events from SIP events (and vice versa), all within the browser where I can also create a UI in XHTML, Flash etc.

For this to work, sessions objects must be persistent and have global scope (i.e. across any Web apps that might run in the browser). Session objects could even have a local UI, which means XHTML stored locally. This blends with the idea of widgets and AJAX and there is lots of room for innovation here.

In some ways, what we are talking about here is a mash-up architecture that blends SIP sessions with Web sessions, but allows the mash-up point to be the browser (with its enlarged container to store and manage session objects). Client-side mashing is really inevitable if we want to work with a protocol like SIP, which is by its nature about negotiation at the end-points, which is where our new session-aware apps will have to reside.

This is just one line that the locus of innovation could take. There are plenty of others. For example, when thinking about where the innovation should be from a strategic point of view, then one has to take seriously the H2H nature of the beast. Mobile comms is, and probably always will be, a fundamentally H2H-centric experience. Thus, we should start to think of the programming model and APIs as being person-centric. This could align nicely with the buddy-list concept. There has been a lot of talk in the IMS world about ‘active contact lists’ where the otherwise mundane, but vastly important, contact list becomes the focal point of the user experience. To me, it remains baffling why devices haven’t gone down this route already. In the speculation around the iPhone, I was hoping for a person-centric interface, but this didn’t happen. The UI is fantastically beautiful and efficient, but still follows the old paradigms (i.e. it’s a phone + iPod + browser, which is how Jobs presented it).

Perhaps what we have been waiting for is the current revolution in social networking services. The revolution isn’t that they exist and are now incredibly popular. After all, they’ve been around since the beginning of the Web in one form or another. The revolution is really in the evolution towards platforms, like Facebook and the fledgling Facebook apps ecosystem growing up around it. Operators, it seems, have already lost the race towards becoming the defacto platform for storing, managing and creating social networks, even though they have been doing this for decades, but locked away in our address books and in their call records. They’ve missed a huge opportunity. That’s what happens when you think of youself as being in the ‘phone call and texting’ business and not in the ’social/business networking’ business, which is really what mobile comms is all about, isn’t it?

So, following this particular locus of innovation, we could jump off the session object programming model and go straight to a person object programming model. After all, isn’t most of what we do on our mobiles and on the Web about me or you? This reminds me of the famous ‘me factor’ in Tomi Ahonen’s 5 Ms - Me, Moment, Movement, Money and Machines (which later I extended, with Tomi’s blessing, to 6 M’s to include Multi-user, or Multi-player - take your pick really). In other words, instead of people being represented by passive records in an address book (or in a SIM card), they become active objects in our extended browser container. Now, whenever any Web or SIP event happens on my device that can be related to a person, I can modify my set of person-objects accordingly and trigger a browser-based mash-up to play out, whatever that might be. In this regard, network APIs, like Google’s OpenSocial, is to me a far more interesting development from the Big G than their Android platform. Clearly though, there is potential to link the two in the way that I’ve been suggesting above. In fact, people objects could become a ‘people protocol’ - just a thought! After all, we have file protocols, web-page protocols and so on - why not a people protocol?

The movement of the fulcrum of social power away from the address book and towards the network was inevitable in mobile comms, even though operators will probably continue to battle against it, which is essentially part of the IMS play - all the people stuff is centralised up in the operator’s distinctly un-open platforms. Historically, such control has been administered through their ownership of our telephone numbers, but in a Web world, these are increasingly irrelevant, as Tony Fish and Ajit Jaokar have argued in the ‘I’m not a number, I’m a tag’ thread of their Mobile Web 2.0 book. What we need now is a paradigm to enable our mobile services to combine with all this fantastic social power building in the Web. What I’ve outlined above are just some of the ways we could think about solving this problem.

I hope that the developer community out there can pick these ideas up and I’d certainly be interested to work with anyone on this problem, at least from an architectural point of view, which is my area. With a little programming resource, it is relatively easy to create some proof points around these concepts. In the lab in Motorola, we had conference calls being driven by Google Calendar and video calls mashed with maps, but this only went so far. The problem was the need, as ever, to justify such developments with revenue models, which in this context (big equipment vendor) stifled the innovation. However, very little of the Web innovation has come out of a business model. Tech ideas solve problems, mostly (and create them too). Plenty of commentators, developers and the like think that there is a problem with mobile. It can be summed up by the sentiment that the mobile has so far failed to give us the kind of innovation bubble that we’ve seen on desktops since the browser arrived, notwithstanding the very real usability problems, but iPhone has given us new hope. I don’t think that the latest swatch of mobile platforms is going to solve this problem, nor is hoping that somehow Web 2.0 will do it once we have AJAX and widgets running on our ‘phone tops’. As I’ve tried to argue here, the innovation must incorporate real-time person-centric communications into the Web model. Does this require a new approach? Yes, I think it does. How far does that have to go? This remains to be seen. Do we need a new browser model, a new scripting language, a new protocol? Perhaps. It’s up to the innovators among us to go find out.

Technorati Tags: Web 2.0, Mobile 2.0, IMS, SIP, Android, iPhone, OpenMoko, JavaFX Mobile, social networking, Facebook

[This blog has moved to here]