3 reasons why the Web platform will not fragment on mobiles

Totally agree with you!

web will be the future form mobile applications. In terms of the debating around ‘widgets’ I recon browser based ‘widgets’ will prevail.

Jason

I think the argument of applications vs. web is a lot more nuanced than you allow for here. 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.

Users want easy to use services which make their lives better and are context-relevant. I seriously doubt people on the street are clamouring for ‘One Web’ as you suggest, and the success (and clearly superior usability) of eg. iPhone-optimised versions of sites like GMail and Facebook show that ‘one web’ is often not actually in the user’s interests. The even greater improvements achievable with dedicated apps – again 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, and usually when applied to Java they don’t actually code Java and get it wrong. Mobile fragmentation comes from a huge range of issues, from bugs and 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, whatever) etc. These issues apply equally to browsers and standalone applications.

You may “like to think QA and awareness will be much better on the Web” but I think the qualifier you use indicates how much fo this is optimism in the face of all experience to date about the quality of software shipped on mobile phones, whatever it is.

For all of these factors, 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. I will stand corrected if yuo can point me to a standards body that has published a standard and has Nokia, Samsung, Apple et al signed up already.
2) There are and will continue to be differences in performance and implementation specifics, just like desktop browsers but with more variants – 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. They only offer it for Windows Mobile now but he hinted at Symbian support too – 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. Hard to define that as not being fragmentation.

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 autoswitch based on UA 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 dev but a nightmare for maintenance of multiple different library versions.

Even ignoring all of this, the kind of AJAXy 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 cacheing, 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 photo organising, 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 apps, and improvements in browsers are certainly very welcome (and overdue). it isn’t 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. Your optimism is commendable and you do state at the end you are looking to the future – but your dream is some way off and all history suggests that fragmentation will get worse before it gets better.

I’ve written a few blog posts on these subjects over at blog.masabi.com and am happy to discuss further if you are interested.

Yes the issue is complicated, though I wanted an idiotic “tech crunch” style post to get the idea across. Of course the Web is fragmented, though it’s far from unusable and it has a healthy upgrade path with HTML5.

Sorry, I wish your post was shorter and easier to reply to. Addressing your main points:

1) Device APIs for cameras are coming to the Web. The approach at work with WebVM is to expose the standards defined by the Java community process.

2) True, though they shouldn’t make Web applications unusable as I tried to point out. Hopefully as you mention, firmware upgrades will come to mobiles (as they do with Desktop and consoles nowadays). Android I’m told gets this right. Nokia seems like are slowly moving in the right direction too.

3) Android will ship Gears. Our customers will ship WebVM (like they we do with JBlend). Apple/Webkit is already implementing some of the technology proven by Gears like Web workers.

I don’t like WURFL and work arounds. Just write a simple Web application. Google.com probably works on any Web browser on any mobile device without fragmented “device dependent” engineering.

Yes, Javascript is broken on a lot of mobiles and I’m working to improve the situation for the future.

I know many like you who are frustrated and have to deal with stark realities of today. I’m working on developing device APIs and improving the Web on mobiles for the future. A future where basically you can not only view the “Desktop Web” with ease from a mobile (like the Iphone can currently), though also get the benefits of exciting new possibilities with device APIs like Geolocation.

Catch me sometime at MoMo and I’ll be happy to talk further. Now, back to work…

> I don’t like WURFL and work arounds. Just write a simple Web application. Google.com probably works on any Web browser on any mobile device without fragmented “device dependent” engineering.

OK, so I want to write a mobile web app that NEEDS to reach literally as many of the different phone models that are out there, in use, especially older models in people’s hands in developing markets. So, I don’t use WURFL. So how do I get my app to work on all those phones then? Do I:
a.) Write one markup, and screw anyone who’s phone it doesn’t work on (most people), bearing in mind this approach also misses out using more advanced features of more capable phones?
b.) ???

WURFL, or more specifically the WURFL based WALL and WALL4PHP (and probably HawHaw) are the only way I can see to address as many users as possible. I see no logic or reason whatsoever to your suggestion.

Basic HTML works on most phones with a browser Alex. Unless perhaps you unfairly include WAP phones.

You can use advanced features like Javascript in advanced phones. Then you must make sure your application is usable without Javascript enabled.

If you are determined to throw money and resources to eeek out small & temporary amounts of “user experience” then use WURFL. Reason why I say “temporary” is that these approaches & techniques quickly become out of date and fragmented themselves.

Sorry Hendry but your misinformation needs correcting…

> Basic HTML works on most phones with a browser Alex.
Not true. Lots of little gotchas out there, that need device specific adaptations. Therefore the WURFL powered WALL, or possibly Haw Haw (tho I don’t know how device-specific it is) is the only way.

> Unless perhaps you unfairly include WAP phones.
Countless millions of people (e.g. in developing countries) still have WAP-only phones. Personally I don’t want to exclude them from using my apps. Indeed, I am making apps that are specifically targeted toward them. I personally think the Web should be an inclusive place, and not only be for the subset of richer folk that have access to phones with XHTML browsers.

> You can use advanced features like Javascript in advanced phones. Then you must make sure your application is usable without Javascript enabled.
Yes. So what? No big deal, esp. with WALL‘s assistance. Any half decent programmer/designer should be able to do this.

> If you are determined to throw money and resources to eeek out small & temporary amounts of “user experience” then use WURFL
WURFL/WALL are free, easy to use, and run on most server/shared server plans. Hence why they are the de facto industry standard the world over. Using them has meant potentially reaching very many more users in the world (technically hundreds of millions) vs. them not being able to access the app at all (a slightly larger effect than small I think most would agree).

> Reason why I say “temporary” is that these approaches & techniques quickly become out of date and fragmented themselves.
Nonsense. WURFL/WALL beats fragmentation, that’s the whole point of it. As for temporary, a 2-minute periodic update to the device database (free also) with the latest updates means I consider it a permanent, not temporary solution.

Cheers!

Little gotchas? A simple HTML page will work. It won’t be pixel perfect for the perfectionist who does not understand how the Web scales.

WAP is not the Web. Neither is XHTML btw. Though I am not going down that road.

Just in case readers are confused into thinking you need WALL to handle browsers that have no Javascript capability, that’s of course not true. I’m sure Alex didn’t mean to imply that anyway.

It must take a long time to check and recheck different tweaks. I’ve known WALL to be wrong. WURFL is a leaky abstraction after all. There is a high maintenance cost to device dependent engineering even if you are using free tools.

I’ve written simple HTML markup as long as ten years ago that works in more and more devices which I have never updated. That’s device independent engineering for you. It’s the long term solution.

Alex I understand your side of the argument. Though please don’t ignore mine.