The Mobile Web and Fragmentation

Last week I read some interesting comments that came out of the last MoMo London event on whether the mobile web is the only way to deliver mobile services, and whether it will fragment like every other mobile development platform. I thought it was worth republishing my comments in an extended form here on our official blog as this is an area in which a number of people have an opinion, and there is a real divide between the optimists and the realists.

Firstly, the choice of platform for a mobile service is not clear cut and we strongly believe at Masabi that no single platform is the ‘winner’. Some types of service are better SMS driven, some as standalone apps, some purely web-based, some as a hybrid and some will simply never actually work in the real world. At Masabi, we focus on areas where standalone apps deliver the best experience, but tie in SMS in various innovative ways and offer web fallback where viable, but we always assess every project on its own requirements.

Ultimately, mobile phone users wants easy to use services that make their lives better and are context-relevant. It is difficult to see evidence for many users clamouring for ‘One Web’ and access to desktop-optimised web sites on their small phone screens; the success (and clearly superior usability) of, for example, the iPhone-optimised GMail and Facebook sites show that ‘one web’ is often not actually in the user’s interests. The even greater improvements achievable with dedicated apps – look at, for example, Google Maps on the iPhone – further suggest this is wishful thinking, and one size does not fit all.

The fragmentation issue is a thorny one. People mean many different things by fragmentation, and for some reason Java is a particular target for misinformed comment. Mobile fragmentation comes from a huge range of issues, from bugs and implementation inconsistencies, different screen sizes (a problem for any application that wants to look better than a 1996 web page), different interaction mechanisms (touchscreens, qwerty and numeric keypads are not alike), different hardware features (only some phones have GPS, camera, Bluetooth) etc. These issues apply equally to browsers and standalone applications.

The mobile web is still relatively young by many counts (despite the legacy of Wap), and it is only recently that users have been presented with browsers which are not a punishment to use. They are improving rapidly, as they must, but they are subject to the same Quality Assurance constraints that beleaguer all mobile phone firmwares – the lifecycle of a mobile phone is driven by the marketing department much more than the software development department, and TV advert deadlines are less amenable to change under pressure than bug lists.

The mobile browser world is extremely fragmented already when viewed as a whole – and even if you ignore 85% of users and look only at smartphones, it is still fragmented. There are many bugs even in rendering, and they don’t get fixed because updating firmware is still non-trivial. Once you start looking at scripting the picture gets worse:

1. There are no standards for things like camera access, and all mobile history suggests that will lead to manufacturers adding proprietary extensions – some are being suggested, but none yet have Nokia, Samsung, Apple et al signed up.
2. There are and will continue to be differences in performance and implementation specifics for all of these new APIs even after standardisation, just like desktop browsers but with more variables – even when the underlying rendering engine is the same eg. Webkit.
3. Offline scripting engines like Google Gears really make things worse. A chat with one of the Gears guys at the previous MoMo London was revealing – Apple will never have Gears on the iPhone, which means instant fragmentation even if some parts of the API are copied over. They only offer it for Windows Mobile now with Symbian support hinted at soon – but Google will NOT pursue a strategy of bundling on devices, which means users must perform a complicated native app installation to get Gears. How many users will do this? Few, I think – and it leaves feature phone users, vastly outnumbering their smartphone brethren, out in the cold.

There are two ways to work around these handset differences – downloading a single big script which contains variants for everything (the current desktop way) or running servers which auto-switch based on the HTTP User-Agent header and a database like the WURFL. The former approach means more data shifted (which is still not free for most people, and certainly isn’t instant) with a greater memory and performance overhead when it arrives. The latter will risk becoming a rat’s nest of script conflicts – scripting is lovely for quick development but a nightmare for maintenance of multiple different library versions. Desktop browsers still require browser-specific workarounds in the script as they are still not all compatible, despite years of Javascript development and auto-updates over broadband – it is inconceivable that mobile, with more platforms, more browsers, more device variation and fewer updates, will not suffer similarly.

Even ignoring all of this, the kind of AJAX webapps people use today are feasible because PCs have effectively free always-on high bandwidth network connections, effectively free mains electricity supplies or laptop-style battery expectations, and fast processors tied to loads of memory and even more storage for caching, and a single consistent UI model with mice, full keyboards and big screens. XML may carry a huge overhead over the network, and scripting may consume a vast amount of clock cycles, but it doesn’t matter because both are plentiful. A drag and drop UI model, like Flickr’s Organizr, can work on Safari on the Mac and also IE on a PC with only a few code tweaks. Does this sound like a mobile device? Some of these areas are improving, some aren’t, but it doesn’t avoid the fact that AJAX webapps are not a natural fit for handsets.

The browser is a natural fit for a huge number of mobile services, and improvements in browsers are certainly very welcome (and overdue). The browser is not the be-all and end-all of the mobile user experience though, and developers who believe it is are to some extent working for the world they wish existed, not the one that does exist.

Despite immensely rapid technical innovation in the mobile world, actual adoption rates of new phone software like browsers is slow with upgrade periods lengthening and a very large installed base of users on legacy phones. Masabi recognises this and out applications support the very widest array of handsets possible, because for many real world services you can never be sure the users who would benefit from the service are the same as the users who always upgrade to the latest handset.

(Disclaimer/plug: I’m one of the MoMo Estonia chapter founders, but I keep referring to MoMo London events simply because they are extremely good and not because of any MoMo bias!)

---