GSMA ONE

First up was Kevin Smith from Vodafone to tell us about the GSMA ONE Web API (also via here). ONE means 'Open Network Enablers'. It seems quite similar to the Web21C initiative by BT, led by my good friend Paul Downey, but which was unfortunately set aside in favour of Ribbit.

You can send an SMS, get a user's location and access billing and connection info. All through a scary STREST interface.

Scary because it looks like you can send a text using a GET... The documentation here [PDF] does suggest using POST, but even so, the design fundamentally wants Resource-Orientation in place of Service Orientation:

The message appears to be tacked on to the URL as an argument. There are references to 'soapUI', endpoints, etc. An SMS message doesn't appear to have its own URL, just an internal message ID. There are 'exceptions thrown', all with a 400 code, even for internal platform and integration faults. And so-on - in classic STREST style!

Still, nothing that can't be fixed with a little help from a REST dude, or a read of "RESTful Web Services".

OMTP BONDI and Ikivo

Next, Nick Allot told us all about OMTP BONDI, which is an attempt to ameliorate fragmentation in the mobile Web and widget space - the one which allows access to parts of the phone not normally reached in a browser: PIM, SMS, camera, GPS, etc.

Their big thing is security: take widgets out of the safety of the browser and give them access to the phone via APIs, and you have a potential security nightmare.

Seems BONDI will let you do most Mobile 2.0 native-like applets, such as LBS, photo-sharing, etc. There's a reference implementation for sad, clunky old Windows Mobile, and both Opera and LiMo are jumping aboard, too.

BONDI aims to be W3C compatible where possible. Not HTML5, mind, but rather a works-now, fit-for-purpose solution to the fragmentation problem, that includes widgets and may later converge with HTML5. There's an excellent discussion about this on WAP Review.

This was followed by a talk by Samuel Sweet from Ikivo. It seems that, starting with their successful Samsung T*Omnia widget interface, Ikivo have been overcome with standards love, and are going BONDI as well as W3C compliant, especially with SVG as a rendering technology.

Firefox for Mobile

Christian Sejersen of Mozilla gave a good intro to what is currently called Fennec - Alpha 2, but will soon be renamed the more grown-up 'Firefox'. It's got the same code in it after all: and APIs such as camera and location that get added to the common codebase will be accessible via both mobile and desktop.

Looks very swishy and touchy and in sync with the times. Available now on Maemo (and Moblin) and soon on sad, clunky old Windows Mobile. Then later this year on Symbian. Codebase is C, so no Java or Javascript phones supported, of course. Or closed walled-garden proprietary locked-down phones like, um, the iPhone. It seems that the add-on community is already fixing up their plugins for this mobile version without even being prompted. No news on the Prism widget-alike system, to compete with BONDI or Opera. It's "still in the labs"...

Panel

Then the panel session started, with the best questions from the excellent host, Dan Appelquist of Vodafone, and some good ones from the audience.

There was much elaboration and clarification on the presentations (thus included above instead), and an interesting conversation around monetisation: how do widgets make money? Three suggestions: adverts, selling widgets on an app(let) store and micro-payments. Graham Thomas of T-Mobile appeared to be happy just to get more Internet traffic for now..

There was also confirmation from Graham that Web'n'Walk 4.0 will major on widgets, but he didn't say what flavour. More hot journalism uncovers this confirmation [PDF] (page 29) that it's still going to be tied in with Opera.

The outstanding revelation of the evening (sorry Ikivo!) came when someone told us that the Palm Pre's widget system is not only proprietary, but uses tables for layout! The horror! Lots of tutting and W3C-like smugness around the room.

Following Open W3C Standards can still break the Web

The goal of all this standard widget aspiration, apart from the obvious motivation of being able to compete with the iPhone, is to allow everyone to write widgets, and for those widgets to work on all our phones.

However, just because everyone does what the W3C thinks they should do doesn't mean you automatically get interoperability. Most importantly, doing what the W3C wants doesn't mean you won't break the Web!

The W3C, don't forget, also brings you 'Web' Services - those mis-named standards responsible for much Web-breaking, including inspiring a whole generation of Web-breakers with their STREST interfaces.

Interoperability on the Web is about state transfer, content types, URLs, hypertext. No amount of API and widget standardisation will give classic Web interoperability as long as they ignore these Web basics.

A widget is an applet is an application. It's a closed structure whose data interoperability has to be hard coded each time, and whose imperative Javascript naturally wants to make function calls back on the server - probably through HTTP.

And you run either this application or that, each having its own way of pushing or pulling data around, or even the same data presented in much the same way all over again.

In the Web you run one browser application and everything is mashed within - data interoperability.

The U-Web gives us the best of both worlds

Admittedly, the basic Web isn't good enough by itself when seeking an architecture for Mobile 2.0's essential personalisation, interactivity and usability.

But that doesn't mean that we should throw away the Web's hard-won advantages of interoperability and scalability, that we perhaps take too much for granted.

Enter the U-Web! The U-Web "puts the Web back into Web 2.0 and Mobile 2.0".

It takes the best of the Web's one-way static document publishing model, and extends it to a two-way dynamic data exchange model, while keeping the interoperability and scalability of the Web.

Instead of working on widget standards that break the Web, let's standardise a fully Web-compatible Mobile 2.0 architecture that delivers the same rich, personal functionality, but adds back the seamless mashability of ever-changing people and their ever-changing stuff. Oh, and promises scalability and rapid, easy development.

I've kicked off the project with the U-Web proposal - perhaps you'd like to jump in and help? Email me (see left bar) or leave a comment.

Mobile 2.0 should be about effortless delivery of dynamic data such as local weather, personalised news feeds, timelines off Facebook and feeds off Twitter, messages, notes, videos, photos, calendar entries, map locations and meetup plans.

Mobile 2.0 should easily allow us to two-way-share this dynamic data with family, friends, contacts, third parties and the world.

People don't actually want applications on their mobiles!

What Mobile 2.0 does not need is traditional applications, because applications just get in the way of this sharing, mashing and updating of live and personal data. What most people want on their mobiles is not the applications, but the stuff they animate.

People only accept the concept of applications (whether a native app or a Web app) because that's all they've been offered, and it's largely good enough. But no-one actually wants to download and launch and register and log in to a local find-your-friends application - they just want to find their friends in the area - now! And they shouldn't then have to flip between the find-your-friends map owned by that application and the restaurant review map owned by another.

They don't want Facebook videos and YouTube videos and phone videos. They just want to share videos. They shouldn't have to think about whether to send a picture by MMS or to use an upload app, after remembering the login. They don't want multiple ways of sending messages: IM, SMS, Twitter, Facebook, etc. They shouldn't have to think about how to tell their friends about some news item - whether to post a TinyURL link on Twitter or copy the text manually into Facebook.

They only want one shared calendar, not the phone calendar and a Google calendar and events on Upcoming.org, that need two more logins. They shouldn't have to think about how to synchronise music or contacts lists on the phone, the iPod, the PC, some memory card and online.

Applications - both native and Web, and including Applets and Widgets - just get in the way of life! They try to own or control our People, Things, Times and Places, breaking them up with arbitrary application boundaries and making things unnecessarily hard to do.

People just want to share new stuff through their mobiles

What most people would prefer is for their friends and messages from their phonebook, their Facebook, their Twitter, their IM, plus their Flickr photos, their Facebook photos, their restaurant and film reviews and their meeting places all to appear on the same map or in the same calendar... along with the local weather forecast for now and for any dates being planned.

And for that map or calendar, those photos, messages, interesting news, etc., to be actively shared amongst those friends, or even the entire world, simply by flicking the 'share with friends' or the 'make public' switch. Any member of a group should be able to post photos into a shared gallery, or scribble onto a shared whiteboard.

The Killer App for Mobile 2.0 is the sharer, masher and updater of People, Things, Times and Places. This Mobile 2.0 platform would seamlessly merge, update, synchronise, upload, download and save your latest life stuff, including that of your friends and family, so that you no longer have to think about doing it yourself.

Your identity and your stuff would be owned and controlled by you through your personal handset. They would not be merely transferrable - they'd simply be transferred, to where they're needed, when they're needed, using an open Internet protocol and standard formats.

What this Mobile 2.0 platform must do

This platform will have a tactile 3D interface, with touchable, draggable areas for People (friends, family, organisations), Things (photos, videos, messages, feeds, news, notes), Times (appointments, plans, weather) and Places (maps, galleries). It will seamlessly access and present this interactive content from the phone itself - representing you - from friends, and from third parties.

This interactive content will be findable by tags, geo-tags and timestamps - it's semantic data, not document text. You'll be able to pick a Person, then see their related Things, Times and Places; or pick a Thing, to see it's associated People, Times and Places. Stuff will also be findable by recommendation and trust, or at worst by well-targetted advertising.

Loss of Internet will be handled gracefully - stuff from others will still be visible, but simply not updated. There are no central servers, so loss of a server only affects the particular content it sources and 'animates' for you.

Third parties will easily be able to add functionality and interactive content such as map overlays, media, news feeds, etc.. They just expose them using the open protocol and notation - they won't have to ask anyone in order to do so. Some contributors can adapt the Facebook, Flickr, Twitter and various IM APIs in the same way. This will require a system for reconciling the multiple identities of users and their contacts.

There will need to be a virtual property system backed up by crypto keys and supporting payment - just because we don't have an App Store, doesn't mean we can't charge for interactive content! It will also be possible to charge for premium services, such as remote storage space for over-enthusiastic photo-snappers.

Blueprint for the Mobile 2.0 Killer Application

Right, we need to describe some more important things with capital letters, because we're going to talk about the best open notation and Internet protocol for sharing, mashing and updating...

We've already introduced People, Things, Times and Places. Call these Entities. Entities are open data - they have a current State. We'll use a text-based notation to describe their public State, because it's easy to read and write. Each Entity will conform to an open standard public schema or syntax.

Entities can Link up because they will each have a UID (unique identifier). Some friends-People met at the last-week-Time and the Tower-of-London-Place and took these photo-Things. I have a collection Thing of People and both personal and public collection Things of photo-Things. You get the idea. That's a form of mashing. Oh - photos on the Web can be wrapped in Entities that pull out their metadata, and Web URLs are valid Links.

Any Entity can Observe another. Well, it's mostly People Entities doing the Observing and being Observed, via the mobile device: my Person Observes your Person to see what you're up to, then Observes your collection Thing of latest photos and may watch you on the map Place as you head towards me snapping more. Sharing and updating.

But some Things can be Observers, too; the more interactive ones that are affected by Entities around them. A simple example may be a restaurant review summarising Thing, that Observes and averages the scores off several reviewers' submission Things. Each time a score is added or changed, the final score adjusts accordingly. That's sharing and updating, too, and Entities that depend on other Entities is another form of mashing.

Entities have read permissions, which control which People and other Entities can see their State. Crypto tech may be needed to support this in some cases. Entities don't have write permissions as such, because they control their own State as a result of what they Observe.

Of course, these Observations occur over the Internet. This will use an open standard publish-subscribe, peer-to-peer protocol. An Internet packet will subscribe to an Entity's Link, another packet will return current Entity State, subsequent packets will broadcast State updates to current subscribers. State is transferred into servers and handsets as required, by a combination of pull and push - sharing and updating. The protocol will ultimately also have to support things like streaming and real-time media; over Wifi at least, so as not to scare off the carriers...

The U-Web Mobile 2.0 platform

This Mobile 2.0 Killer Application for sharing, mashing and updating People, Things, Times and Places ... will have a shorter name! I'm calling it the 'U-Web' Mobile 2.0 platform at the moment, reflecting its affinity to the Universe Web I described before. The U-Web platform application will be free and the protocols and formats outlined above will be open.

The typical handset specification and APIs we're aiming for are: at least 320x320 touch screen with Embedded 3D; GPS, Wifi and good 3G; front- and back-facing cameras.

There's a large number of Windows Mobile devices that match this, including phones from HTC, Sony-Ericsson, Samsung, etc. There's currently one Symbian (the Nokia 5800/Tube with the N97 to come next year). One iPhone. One Android. One Blackberry without Wifi (the Storm).

Although Nokia's plans are somewhat unclear, their S60v5/Qt/Ovi offering looks like it may preclude the U-Web, especially since the U-Web wants to be the top app... The U-Web certainly wouldn't be allowed onto the Apple App Store - the clue is in the name! Writing it in C also rules out Java phones, such as Android - which in any case is another app-oriented platform - and any Blackberry handsets.

The U-Web should thus be written for Windows Mobile 6+ Professional handsets. At least their users will have a ready appetite for anything integrated and easy to use, that keeps them clear of the .. clumsy .. operating system. It will also be worth keeping an eye on the various Linux MID (Mobile Internet Device) platforms, including OpenMoko, Maemo and Moblin, and maybe LiMo. Similarly, we should write for Windows and Linux on the server side - the code will be essentially the same. It'll need to be written in C as the lowest common denominator, most efficient language.

The U-Web will be the top or idle application: on Windows Mobile it would replace the Today screen, or more likely TouchFLO 3D or Spb Mobile Shell. Else it could be an Xperia X1 Panel. Like these, it will give access to phone functions such as calls, texts, camera, speaker mute, Bluetooth and Wifi enable, lock screen, brightness, etc.

Of course, it won't actually be the only application while it is in its beta phase - people may still want to access a browser, email and various settings and utilities. The need for browser and email should reduce significantly when functions such as Web 2.0, messaging and file sharing are drawn up into the mobile-native U-Web, leaving just actual documents fitting awkwardly.

Opportunity

It is a mistake to see Mobile as just a second-class computing platform or as a miniature office desktop onto which you must squeeze applications and documents.

Mobile represents a whole different world of personal interaction and almost 100% presence - especially now that mobiles are becoming Internet-connected and location-aware and are being furnished with top-quality cameras and touch screens. The mobile device represents you, here, now; what you're seeing and doing, to your social network.

A Mobile 2.0 platform needs to drop closed applications and go instead with the flow of People, Things, Times and Places. It needs to transparently share, mash and update people and their stuff.

The U-Web Mobile 2.0 platform described here is designed to seamlessly merge your real and virtual lives, starting with intuitive, 3D touch interfaces that give an almost tangible feel to virtual property, then expanding out to touch the 3D lives of others.

If you take a photo, your friends can instantly 'join you on the map' where you stand and chat about it - and the weather conditions you're experiencing. No need to upload to photo sharing sites with logins, or to launch isolated chat, map and weather apps.

The opportunity is billion-scale - increasingly capable mobile devices will become the world's primary connected computing device, outstripping PCs and making current Internet and Web usage look like just a warm-up.

We should be in there with appropriate software when that happens. We can stumble into this step-by-painful-step via applications and browsers, or we can just let go and meet the actual requirements - with a platform for mashing dynamic, shared data.

I'd be delighted to hear from you if you're interested in helping or getting involved in any way with building this platform! Email me - link's on the left - or leave a comment.