On U.S. election day last year, November 4th, I co-organized with Katrin Verclas of MobileActive a Barcamp style event we called “Mobile Tech 4 Social Change” focusing on the increasing role mobile technology is having in social activism, grass-roots organization, social development, and in the developing world. It’s possible we started a movement because MobileActive has gone on to run two more camps since then, in New York and Washington DC. Now Mobile Tech 4 Social Change is coming to London. I’ll be hosting this event on May 23rd in at Vodafone’s offices in London. For all the details and to register, go to MobileActive.org’s page on the event. If you’re interesting in helping to build a bridge between the mobile industry and the social activism / social development space then I encourage you to attend!
Betavine (Vodafone R&D’s developer community portal), with some help from the inimitable folks at Carsonified, have laucnhed a new blog dedicated to Mobile Widgets and Web Apps. The idea is to get as much information out as possible about what Betavine and Vodafone are doing in the widget space and what’s going on with the latest widget standardization efforts. We’ll also be featuring information on upcoming events, like the W3C widget camp at WWW2009 in Madrid next week and the upcoming Vodafone Mobile Widget Camp in Amsterdam on May 2nd. We’ll also be posting on Twitter on @MobileWidgets on Twitter. Stay tuned!
Carsonified built a great micro-site around their Twiggy Twitter search widget. The site also includes lots good information about mobile widget development including a step-by-step guide on the development process. Check it out (and learn how to win £20,000 in the Betavine widget contest).
One of the most interesting discussions I had in San Francisco two weeks ago (where I was co-presenting Mobile 2.0 and the Mobie Tech 4 Social Change camp) was with Brian Fling on the unlikely subject of email. We both agreed that we hate email (a common sentiment these days) and that something needed to be done. I don’t know a single person who actually doesn’t roll their eyes these days when the subject of email comes up. Kids these days already refer to email is “something I use when I want to communicate with old people.” Ouch!
Email as a medium is not keeping up with how we interact, how we do our jobs, how we live in the modern world. It’s overtaken by spam (encouraged by its nature as an open and free medium and the relatively little it costs to send out emails in bulk). It has no intrinsic trust mechanism (and developments like sender policy framework are basically a band-aid and do not address personal trust circles, only whether an email is from where it purports to come from). Email has no intrinsic semantics that allow email clients to do anything useful with them. Even advanced email clients can do little to help with this mess. Email is actually follows a typical trajectory for innovation. In the book Why Things Bite Back, Edward Tenner takes us through a history of technological innovation and why some innovations have “unintended consequences.” The unintended consequences of Email have become all-to-clear: lost time, “inbox anxiety,” spam and “BCC cultute” are only some of them. My view is that email is fundamentally mismatched with an “always connected” world – and these days we are always connected – and it’s been hopelessly outpaced by the far more powerful social paradigms of social networks. Email is a monster which has grown to enormous proportions and which we are all spending our time feeding, to the detriment of our real lives. Email can also be ambiguous. I receive so much email that I have to filter my CCs into a separate folder which I don’t look at as often – but then people will CC me on a message that requires my urgent attention and get annoyed when I don’t respond right away. Email woes are accentuated by the fact that no significant innovation has happened in the world of email clients in 10 years.
Imagine a life without Email.
Need to get in touch with a friend? Use Twitter “direct message.” It’s much more difficult for you to be spammed, because you control who connects to you. Bonus: you have to be terse. Need a longer conversation? Use Skype or another IM solution. Need to send someone a file? Again – IM. More immediate and you KNOW the recipient has received it. How about you need to arrange a meeting or a drinks out? Social networks provide all the mechanisms you need for this. Need to share a file with a large number of people? Use a Web-based sharing service like Google Docs or Zoho and then alert them using one of the means above.
Ok – technically most of the services mentioned above require access to an email account (for registration and identity verification). Zipiko is an example of one that doesn’t – you can sign up with only a mobile number.
I imagine an email-free world as a kind of utopian existence where people no longer spend hours and hours of their time each day “clearing their inbox” or methodically filing mail away into meaningless folders. Close your eyes and visualize it with me.
Crazy? Someone at IBM is already living the dream.
Since upgrading my iPhone to the 2.0 software, I’ve dived into Apple’s app store and I’ve been making a point of trying out apps from across the store but focusing on content creation tools (such as the excellent WordPress app which I’m using to write this post). At the same time, I’ve continued to make use of all the great iphone webapps and mobile Web sites I’ve come to know and love. Increasingly, across many platforms (not just iPhone) application developers and content providers will face this choice: to build a webapp or to build a native app. There are advantages to both approaches, and some work that’s just getting started that I believe will significantly change the face of mobile development over the next 2 years.
The rush of content and application developers to develop iPhone apps has been impressive and somewhat predictable. The app store is the next big thing. Google, Microsoft and others are now jumping on the bandwagon (probably much to the dismay of the folks at Handango who can rightly claim they’ve been doing an app store since before app stores were cool). Many of the apps in the Apple app store are really good and could not (currently) be written as web apps because they either take advantage of device capabilities (such a location) or because they need direct access to graphics or sound capabilities (3D gaming) not available to the browser engine. However – discounting this need to access the platform functions, there’s nothing about, say, the iPhone Facebook App that couldn’t be written as a webapp. Indeed, if you visit iphone.facebook.com, you get a webapp version that gives you more features, has better usability (in my opinion) and benefits from more frequent updates (but does not, for instance, give you access to the camera so you can automatically take pictures and upload them to your profile, because the browser doesn’t have access to the camera API). Hahlo is another good example of a Webapp that currently beats out all the native application options as a Twitter client (except for its lack of access to the address book, camera, or location). This is the crux: it’s easier to build, update and maintain a webapp than an app (for cases such as the Facebook offering) but native apps give you access to platform features (and other capabilities such as local storage) that webapps can’t.
Enter a new class of webapp: a mobile browser based application. These applications are built using Web technologies (the so-called Ajax platform), can either be deployed as a standard Web application or as a “widget,” and can advantage of platform functions through some ingenous software layers currently being built. Google’s Gears Mobile, Nokia’s Web Runtime platform and upcoming versions of Opera Mobile all are making a start of it, but right now these efforts are all highly fragmented and incompatible. The OMTP, through its BONDI initiative, is attempging to bring some focus to this area, by coming up with a common set of industry requirements for enabling secure access to platform APIs and then driving some work forward in W3C’s Web Applications working group to help to make this an industry standard.
I was interested to read that in all the discussion of the iPhone app store, Apple has also quietly made it easier to write webapps and to surface these webapps to the user as if they were native apps. Essentially, the “web clipping” mechanism allows you to put an icon on your screen to represent a webapp, and with the release of the latest firmware, it is now possible to launch these webapps without the normally associated “browser chrome” (which mirrors the approach Apple has taken with it’s latest beta of Safari on desktop). This approach further blurs the lines between webapp and native app.
In the short term, it means more confusing choices for application developers. But in the long term, at least for an increasingly large class of application (for example, social applications or any app that doesn’t require direct access to platform features like 3D accelerated graphics), it’s clear that the Web will prevail.
Zipiko Screenshot
I’ve recently been trying out Zipiko, a very simple but powerful social tool for organizing events and ad-hoc get-togethers. Zipiko has a really good mobile Web UI through which you can develop your network by inviting friends to events via their phone numbers. Your friends get an SMS which they can respond to with a simple “YES” or “NO” to let you know if they’re coming or not. Unlike some mobile Web apps comming onto the market, Zipiko seems to realize that not everyone lives in the United States and has thankfully enabled international phone numbers – thanks!
Zipiko is an example of a really great mobile Web app: it’s simple, it’s well designed, it’s well suited to the mobile use case and it integrates well with text messaging. Unfortunately it does NOT work well with low-spec browsers. I tested it on iPhone and on Windows Mobile (mobile IE) where it seemed to work well. On Blackberry (my “low bar” for mobile browsers) it was a disaster.
But what really struck me was how much better Zipiko could be if had access to device capabilities and information stored in your device. Instead of asking me to type in the phone numbers of my friends, it could simply look them up in my address book. Instead of asking me where I am, it could look up my location. It could automatically syncronize events with my device’s calendar. This is a comon theme, particularly for social web apps.
This access to device capabilities from the browser or “web runtime” environment is what I’m working on this week, in Austin at meetings of an initiative called BONDI. BONDI is attempting to drive standardization of these APIs and the security model around their use (you wouldn’t want just any Web app poking into your address book or locating you). This was also a real topic of interest for the Mobile Widget Camp which I helped to run on Sunday in collaboration with Enrique Ortiz and the Austin Technologi Incubator. More on that in a follow-up post.
After trying out Zipiko, I’m more convinced than ever that the industry needs interoperable mobile web apps and widgets that can access device capabilities.
