By Dr Paddy Byers

PS: This is the biggest post on the OpenGardens blog. We debated if we should split it – but we think reads best as one document

I attended the Mobile2.0 event in San Francisco on Monday. The first reviews of the event ranged from Mike Rowehl’s harshly self-critical review to many more upbeat comments including those from Dan Appelquist. Interesting how two key organisers can come away with such differing views.

Personally, I was inspired by the event and felt privileged to be there. It was deliberately aimed to get grassroots attendance by being staged at cost and by being advertised widely in the blogosphere.

The attendees were a mix of technologists (from both large companies and startups), independent developers, and some bloggers including respected commentators; as such it was quite different from many conferences which are largely attended by consultants touting for work (I know – I used to be one of them).

There was an extremely vibrant atmosphere and lots of discussion in the margins. Most people I spoke to felt that they were witnessing the beginning of a new era of mobile services – there was a clear consensus that mobile will drive the future usage models for web businesses and it makes no sense to discuss one without discussing the other.

The other big difference between this and mainstream conferences is that the latter are sponsored by big corporates for whom the deal is straightforward – you pay your sponsorship and then get a speaking slot in which you get to advertise your company. Most of the speakers at Mobile2.0 resisted this temptation (but not all, which was a shame). I agree with Mike’s comment that there was too much time on slide presentations and not enough debate but I think that it was also due in part to having an extremely aggressive agenda, which packed in more speakers and sessions than I’ve ever seen before at a one-day event.

In fact the Microsoft panellist (Aron Holzman from Windows Live Mobile) volunteered to forego his slide pitch in order to give more time for panel discussion. It’s great that he respected the nature of the event and did that – but personally I would have preferred to have heard at least something about what Live Mobile is doing and planning to do. After all, you can only have informed debate once the participants are sufficiently clued up to begin analysing the issues rather than just trade facts.

That, in a way, summarises my main conclusions about the event; the community is still at the stage of understanding what’s happening in mobile, the degree to which regular web technologies apply, and starting to learn about the barriers and opportunities there are. Ask two people what they think Mobile2.0 means and you will get different answers. The event did a great job of exposing what’s going on, but there wasn’t enough time to take the next step. Many of the issues raised are things we’ve already discussed in this blog so, the discussions will be familiar to readers of our work.

Key themes

Through the presentations and discussion sessions a number of issues surfaced a number of times.

Service diversity

You only have to read Mashable! for a couple of weeks to see how much similarity there is between many of the web 2.0 businesses that are starting up, with the same themes coming up time and time again. The examples discussed at this event showed how mobile is quite different. I expected there to be lots of discussion about applications being built with the same concepts and technologies – especially browser-based applications and AJAX – but the reality quite the reverse. The key takeaway for me was the diversity of the things people are doing, to adapt to the constraints of the mobile platform, but also to exploit its unique capabilities. One example given by Peter Vesterbacka was the service in townships in Africa which allowed schoolchildren to submit Wikipedia queries by SMS and to get results as audio clips (ie an audio rendition of the Wikipedia text by a text-to-speech robot). This way, an web-capable phone wasn’t required and the audio clips could be used in turn by the students within their projects (as audio podcasts). Other examples well away from the browser domain were discussed in the launchpad (see below). Conclusion: the successful apps will be the ones that make best use of the mobile as a platform with all of its diverse capabilities.

Platform diversity

The next big issue that everyone’s grappling with is platform diversity. In this I’m not just talking about a lack of interoperability – which is where devices offer broadly equivalent functionality but in slightly incompatible ways – but outright differences in capability between low end phones and smartphones.

At the low end there might be no browser, and for those phones with browsers there are huge differences in browser functionality (eg based XHTML vs high-end with DOM/AJAX) and in connection speeds. The challenge is to create services that are accessible on as many devices as possible, but also to take advantage of features on the high-end devices. Martin Frid-Nielsen (SoonR) told us how they have approached the problem by designing for XHTML first, then look at the areas that would benefit from enhanced interactivity with AJAX on those browsers can support it. With Opera, SoonR has really tried to push the envelope to get the best possible interactivity and platform integration on each device. Opera themselves have done something similar with their two-pronged Opera Mobile/Mini combination. Conclusion: your targetable community will be inherently limited as it is, and you can’t afford to be choosy in terms of the platforms you support.

Thick vs thin application environments

This topic kept raising its head and there were good contributions on both sides. By thick (or fat?) application environments I mean those that require some software to be installed on the phone (whether a java MIDlet or a native app on Symbian) – even though the service itself might nonetheless be inherently server-based. (Examples of apps I would classify as thick are the J2ME Gmail client and the J2ME Google Maps client, which are the mobile variants of AJAX applications on the desktop. We also heard from Kaj Haggman about Widsets, a java app that delivers a service which, on the desktop, would be a pure web app.) Thin apps are those that require no user-install, typically browser-based, but also including those based exclusively on SMS.

The issues themselves won’t be new to readers of this blog – see for example here – but the arguments were brought out strongly by real examples on each side. The thin apps proponents cited the critical factors as being:

• Barriers caused by user-install. Most users simply won’t. Downloading the app is only the start – you also have to set up security permissions on many java apps, for example. Precious few users use their browser but fewer than that install software. If you take games out of the equation, the uptake of user-installable apps is tiny. Martin Frid-Nielsen said (I’m paraphrasing here) “Thin apps are a huge deal. Each day you can improve the user experience. Tied to that. there is flexibility on the business model: browser-based apps don’t have same restrictions, you have more scope as a service provider to develop the business model yourself. You can Set up multiple services globally without carrier intervention.” You only benefit from the “end of the software release cycle” if you have thin apps.

• More rapid development. Conventional web development methodologies which are now proving exceptionally productive can also be used to develop mobile apps, especially where the applications are inherently server-based. Note that this isn’t particularly tied to the idea that mobile and desktop variants benefit from common implementation, although there were also some advocates of that. (There’s mention later of how standards initiatives are driving to support this.)

• Scalability and dealing with the long tail. Installed apps consume space on the device permanently and only a certain number of apps fit on a device. When a user wants to use an app that is used infrequently, it doesn’t work to have to discard another installed app (especially if it has been paid for).

The thick apps proponents cited other issues:

• Insufficient access to platform functionality. From within a browser application, there’s no standardised way to get access to the platform functionality on which most mobile services depend – whether SSM/MMS, camera, etc. Location was the feature that was most missed by the application developers I heard from. Arun Ranganathan (AOL) discussed this as a problem and called for a process for standardization similar to the Java Community Process. (Personally I don’t think this is the right way as I’ve argued in What mobile AJAX can learn from the fragmentation of Java Me ; but I agree about the need for platform access to deliver meaningful services.)

• Ability to target broad range of devices. If an application requires a certain level of interactivity that would necessitate AJAX in a browser-based implementation, then you can get the same level of interactivity and target more devices with a java application.

• Performance. Ultimately, native or java applications installed locally are capable of better performance than browser-based applications. If performance matters, then thick apps definitely win. Hetal Patel (Symbian) cited some concrete examples of this. Sumit Aragwal (Google) reinforced this with Google’s own experience, that response times on a web site translate directly into the proportion of users that will return to that site. (The rapidity with which Google Maps displaced the non-AJAX Mapquest as a direct result of its performance; so Google’s mobile equivalent is implemented in java.)

• Avoidance of need to repeatedly download common data or functionality. Browser proponents did point out that some progress was being made on this in the browser community.

Interestingly, nobody mentioned the monetisation potential of getting users to pay for the downloaded apps. This model seems to be disappearing other than in specific markets such as games.

These issues were discussed a few times without any firm conclusions. The current state of affairs is that different apps are best suited to different implementation approaches. Broadly, I would say the consensus was that most would prefer to use a browser implementation approach and look forward to a time when the current shortcomings (particularly lack of access to platform features) are no longer an issue. There was a clear consensus that both approaches can validly be considered to belong to Mobile 2.0.

Browser fragmentation

One the desktop there are really two browser families: IE and the browsers derived from Mozilla. Developers understand what to do to make apps portable across these browsers. On phones, it’s a big mess, with multiple browser manufacturers, multiple incompatible carrier specifications, disparate device capabilities, etc. The standards compliance of XHTML mobile browsers is improving interoperability but, as mobile AJAX gets introduced, interoperability will probably get worse before it gets any better. We’ve mentioned some of the business model and ecosystem issues that exacerbate this in Mobile phones features: who is the customer for service enablers?.

At the event we got more insight to the landscape of mobile browsers. The AJAX leader is Opera mobile, but we also heard from Chris Hoffman about Minimo (the mobile version of Firefox) and other AJAX-capable browsers are in the pipeline, notably from Nokia and Access. Access themselves were not represented in the speakers or panellists but they were vocally supported by their delegate (more of this below). Developers were obviously concerned about the impact on development cost of fragmentation, and there was discussion about the standards initiatives to address this from Steve Bratt of W3C and other panellists. Related topics discussed were unreliable user agent strings and the .mobi work (see below). Conclusion: fragmentation will continue to be a big issue; new features will continue to be added while standards are developed to deal with the features we have today.

User engagement

We saw lots of statistics about numbers of devices, numbers with browsers, numbers of browsers in use, etc. Hetal Patel (Symbian) cited some pretty telling statistics: despite big improvements in network speed, device input, screen sizes, a wider range of services being available and reductions in data charges, mobile browser usage is still not growing appreciably. This, he argued, points to fundamental problems with user experience. Related topics discussed were adoption of mobile apps relative to doing the same thing on a PC; the role of mobile as consumer vs PC as creator; the prevalence of mobile as the preferred device in the under-developed world and among youth.

I think the strongest theme that related to user engagement was this: users will expect to gain access to the services that they want on mobile. Many of the services they are given aren’t the ones they want but the ones that the carriers thought they could monetise. For many social media and related services there is already a user expectation that they will be extended to mobile. Martin Frid-Nielsen complained about all the “crappy apps out there” and explained that the user experience is currently so poor for many that users simply aren’t motivated to use the services on the majority of devices. Conclusion: uptake of services on mobile will definitely come and in the future it will be totally alien to think of web applications without the mobile terminal having a central role; but users don’t tolerate poorly conceived services and poor user experience.

Carrier engagement

There wasn’t as much discussion of this as I’d expected; although “carrier interference” was cited by many of the speakers as one of the issues they’d contended with, it was by no means the most significant. The consensus was that carriers have a legitimate role to play in the overall value chain; provided you recognise that have a mature business discussion with them, you can work out most of the issues. Data plans and unpredictability of costs continue to be an issue for many apps developers; but even here there are more mature attitudes emerging than straightforward carrier-bashing. One example shown was Widsets, where there is user functionality provided in the app to monitor data usage and to help the user take control of data expenditure (such as an alert when data usage approaches plan limits or price breaks). Conclusion: to build successful services, you can try to divorce yourself from the carrier as much as possible, but ultimately you have to bring them with you.

Standards, content compatibility and content adaptation

Steve Bratt, and others, talked about the standards work that is underway to bridge the gap between the desktop web and the mobile web. Related topics for discussion were content and device certification including the work of .mobi, and a discussion about the various ways content adaptation can occur: within the target browser (eg Opera Mobile), within a “network-hosted browser” (eg Opera Mini), via a content adaptation system (eg Volantis) as well as via conventional means (XSL generation of markup, and use of target-specific stylesheets). A standards-based approach very strongly advocated and it was interesting to see so many of the significant players also investing effort in standards-making activities, mainly under the W3C umbrella or closely aligned initiatives. Conclusion: the community is fully committed to making a unified web based on open standards but recognises the time this will take.

Mashups provide way of adapting content

Here’s one thing that I found really interesting. Chris Hoffman from Minimo explained one approach to targeting existing websites at mobile devices: create a mobile-specific mashup. The example he showed was the Minimo version of Google Maps: it was a dedicated mobile site (not adapted or restyled markup), but it used the Google Maps API to provide its implementation. So this gave a site with an immediately familiar look, but with functionality and navigation tailored for mobile. A great way of creating a mobile derivative service: it doesn’t mean that interoperability issues complicate or compromise either the main site or the mobile site, nor does it suffer from the unreliability of mobile content adaptation when dealing with behaviour (and not just rendering) issues. Conclusion: many of the issues being faced don’t require new technology, just imaginative solutions.

Launchpad

There was a 1 hour launchpad session in which various companies were invited to give a short pitch about their offering. I thought this was the most inspiring aspect of the day.

Peter Vesterbacka talked about Connected day which is a service offered to parents of young children in daycare. The idea is that staff at daycare centres use a mobile to take photos of what’s going on and those are then uploaded to a site for viewing by the parents. The photos can be rated, tagged and organized just as in any other media sharing site. It is a very simple idea but transforms the experience for all concerned – the parents, carers and children.

Fabrizio Capobianco talked about Funambol which is a consumer push email solution. The interesting thing about what they are doing is how they are attacking the device fragmentation problem with respect to the porting and testing of software; they make the point that the issue simply isn’t about software porting – which in principle could be done anywhere – but that testing really needs to be by people on the ground in each target territory and network. Their solution was to create an open source community and to have financial incentives for users who test the software. A comprehensive test procedure has been developed, together with web-based systems to walk the user through the test procedure and log the results at each step. The end result is exceptionally broad device coverage, high product quality and happy users.

Marc Bookman made the first public announcement of MCN, a real-time mobile search solution. The problem they are addressing is that conventional (ie pure text) web search doesn’t really work well for mobile. For example, search results can be a perfect match by pure text criteria but might bear no relation to what the user is looking for; on mobile it is much harder for the user to know this at the level of the search results page and the user is much less tolerant of false positives. Their solution is to provide much more semantically-aware search services – based on having service providers and merchants hook their sites up to the search service explicitly and programmatically – arguing that most of the data on the “mobile web” is already in structured data repositories. The resulting user experience is said to be 3 clicks: search-select-buy.

Andy Jagoe talked about 3jam’s reply-all SMS system. It is an example of a service with disruptive potential that requires no extra functionality on the phone (not even a browser). It seems to be spreading very successful virally. The catchphrase is “in the loop, on the fly”.

Jim Kaskade talked about Eyespot which is a web-based video editing and sharing service with a mobile client. The mobile can be used for capturing and sharing videos directly, but advanced editing only happens on the website. The success of the web application lies in the way it simplifies the authoring process – it isn’t a fully featured video editor, but allows very simple and effective authoring of a sequence based on a timeline, users’ own assets, shared library video assets, still frames, etc.

Mike Prince talked about Mojeo and spoke so rapidly that he must have given a half hour presentation in about a minute. What he described seemed in essence to be a mobile del.icio.us with built-in geotagging. The purpose is to use the power of social networking, together with knowledge of location, to make the mobile web more accessible; that is, to make the good content easier to locate by having the community rate it and make the web “flatter” requiring fewer clicks to navigate. It has the built-in facility to spread virally by SMS and exemplifies the good and bad aspects of browser-based application environments: zero-install, cross device compatibility, fast integration with existing sites, but limited by not having access to location data from within a script. Apologies to Mike if I didn’t get it all.

On .mobi

In an earlier post I questioned why we need .mobi; in particular I was wondering what the merits were of a dedicated domain. Well, at the event we heard from Ronan Crenin, Director of developer initiatives, dotMobi and got to find out more concretely what they are doing.

I have to say I was pleasantly surprised. None of what was discussed necessitates a separate domain, but they are working to help developers creating web content for mobile devices, by a combination of standards evangelism supported by practical help. It is coordinated with the “mobileOK” work by W3C. It is intended support sites that are mobile-aware and can deliver both desktop and mobile content.

Their offerings include a streamed online training course, site templates and a book for developers described as “.mobi for dummies”. All of this is free of charge to developers.

The mobile-ready support system rates sites to establish whether or not they are suitable for mobile. You point the system at a mobile website, and it evaluates the content delivered to it by a number of criteria such as use of supported functionality, markup validity, page size and navigability, etc. It also provides estimates of download time for sites based on a number of network types. The results of the evaluation are provided in a clear form with explanations of the specific issues and reasons they are relevant.

Memorable quotes

Aside from the main discussion themes there were a few other snippets I thought worthy of mention.

“You can’t milk a calf” – Sumit Agarwal (Google). A reminder of Google’s basic philosophy to rolling out its mobile services. First build the service, get it right, build a community, and then you have a chance to monetise it. Attempts to monetise services when they are not yet mature will fail.

“Intertwinglement” – Judy Breck (Goldenswamp). Judy gave a lucid account of the possibilities for mobile and web content combining to revolutionise education. Intertwinglement describes how information is naturally interlinked in a way that defies simple and hierarchical classification. The web is naturally suited to delivering this kind of information, whilst teaching in a purely serial fashion is not optimal and, in the extreme, confusing and counterproductive. This triggered a related discussion on the validity of web content (eg Wikipedia) in comparison to traditional textbook materials.

“It’s about users and not just geeks” – Arun Ranganathan (AOL) on the challenges of proliferating services to the wider community.

“Does my page look big in this?” – the slogan on the (offensively turquoise) tee shirts handed out to delegates by dotMobi.

“Lies, damned lies and user agent strings” – Dan Appelquist on the conflict between browser manufacturers and site developers caused by user agent strings that are not informative or are intentionally incorrect.

“Simple things should be easy, harder things should be possible” – a mantra offered by Rhys Lewis (Volantis) for framework developers but useful reminder for UI and application designers as well.

In an amusing interlude, Tony Fish (AMF Ventures) challenged two members of the audience to locate the nearest Starbucks, one using a mobile browser and the other by any alternative means. He hoped to show that we geeks often turn to a technical solution and forget that normal humans are more socially adept. In the event the man with the Access Netfront browser calmly found the answer within around 30 seconds while his opponent ran around the room like a mad person.

Summary

Overall, this was a much-needed event, which was creatively organised, with a very ambitious agenda and set of objectives. For me, it nearly achieved all of it. Its main contribution was to inform and to provide the starting point for debate. I’d like to see the discussion topics picked up in the blogosphere, and if there was a follow-up event in 4 months time, I don’t think it would be too soon. I thought the launchpad was the highlight of the event, and it showed the diversity of what Mobile2.0 can mean. It also provided a glimpse of the opportunity out there for innovative companies.

The main disappointment was the lack of debate, especially as the grassroots attendance could have served that very well. The next event ought to concentrate on improving this aspect, but as it is likely to have an even bigger audience, it’s a challenge.

With all that said, I think the organisers deserve to be congratulated, both for taking the initiative to set it all up and for executing it as well as they did.

Where does all of this leave Mobile 2.0 or Mobile Web 2.0(Mobile Web 2.0 being discussed in Ajit and Tony’s book Mobile Web 2.0 ) ? Perhaps the best top-level summary was provided by Steve Bratt in the opening keynote (paraphrased wording):

There are many parallels between the mobile web today and the embryonic web of 1994: it’s too slow, there are walled gardens, poor interoperability, accessibility problems and child content protection issues. However, in many respects the prospects are a lot better: there is much more content, more and better equipped developers, business models and mature industry; the content includes rich applications, not just a web of documents; and there are billions of potentially connected users for whom web access isn’t a novelty.

These are the factors that will lead the mobile web to be truly ubiquitous and productive.

If you attended the event, I’d be interested to get your comments.