I was part of a roundtable discussion at Mobile Web Summit during which we discussed the mobile device fragmentation problem. For mobile application developers, fragmentation is a huge pain in the backside. Simply put, there are too many variants of device to program for. This means that programming for a large number of users across a range of devices is often impractical and uneconomical.

Fragmentation tends to indicate that the device variants are indeed fragments - that we had a whole to begin with, which was never the case. In fact, we’ve never had a mobile computing environment at all. We have mobile phones, not mobile computers, with very few exceptions. Mobile phones have a completely different history and evolution to desktop PCs, although, perhaps because they also now run programs, such as MIDlets, there is a tendency to draw parallels between the two environments.

The notion of creating a common computing environment on top of a sea of resource-starved consumer devices was problematic from the start and doomed to failure, even with initiatives like J2ME. In fact, had we stopped to think about J2ME and the Java ethos of “write once, run everywhere,” we should have smelled a rat.

Even if the run-everywhere idea was the right one to pursue, which I doubt because it leads us to the incorrect notion of a uniform experience, we should have realised that the principle hinges on one important feature of the desktop world that is absent in mobiles. Run-everywhere technologies need a flexible run-time environment, which principally means one with room to grow (i.e. excessive memory/processor resources) and - most crucially - one that obeys the most fundamental aspect of general purpose computing, mobile flavoured, or not, which is the ability to update the environment.

Without the ability to update the programming environment, fragmentation is almost guaranteed. Bugs cannot be fixed, poor implementations cannot be corrected and, perhaps most importantly, new APIs and features cannot be added. We therefore struggle to achieve sameness. Mobile device programmers will know that variations of program behavior can even occur within one model of device. Devices that appear the same might have different versions of operating software.

The market today is still predominantly a mobile phone market. As long as the phone does all its phone stuff, like making calls and sending texts, it’s up to the manufacturer how they do that, especially what software they run on the device. As this is likely to continue for some years yet, we can’t expect mobile phones to converge any time soon on a universal mobile computing platform.

Meanwhile, if we still can’t update these devices, then the problem of ‘fragmentation’ remains. Of course, enabling mobile devices to be updated after sales is easier said than done. Most phones are made with the minimum amount of memory and processing power to achieve the basic functions of the phone. This does not make them easy to update, never mind that we don’t really have a mechanism for doing the updating in the first place.

However, I think that this has to be a design goal for any phone that is going to be a serious contender for a mobile computing device. We could specify that a certain class of device (let’s ignore the platform for now) must be capable of easily downloading and installing new updates to any of its software functions. For the time being, I can only see this being practical via a short-range or fixed connection.

My favourite idea for some time has been to take advantage of the charging cycle as a means to download new data or software into the device. This is not a new idea and is obviously a strong feature of the iPhone. There are many alternatives and I would imagine that there is an opportunity here for Femtocells and other short-range RF connections that are fast and reliable.

The ability to download data easily and update software is not enough. We need an ecosystem, if I can use that term, to support it. In other words, we have not just a specification for updating software on a device, but a means to do so that is open to any developer and device manufacturer to participate in. This is perhaps the missing piece from stories like Android. We do need a class of devices that support this feature.

As per my recent presentation about narratives for thinking about the mobile user experience, a device that can support a host of key experiences in addition the general benefits gained from a flexible (i.e. update-able) software environment. Within the mobile user experience, we have to pay a lot of attention to discovery. It is extremely difficult at the moment to discover anything that might run or be viewable on a mobile device. Without the chance to “bump into” stuff, it’s not likely to get used. Someone at the Mobile Web Summit suggested that she now uses YouTube a lot because it’s on her iPhone, whereas she never visited the site on her desktop. This, I suggested, was simply because it was there - as an icon - and therefore very easy to bump into.

Whilst we tend these days to think that increasingly the browser is the solution to mobile device fragmentation, this is currently a lesser of two evils. Yes, we can reach a much wider set of devices using the browser, but this usually means that we have to accept a lowest common denominator experience, which, if we’re honest, is lousy.

Browsers could do a lot more, especially if we start to allow them to access parts of the traditional mobile phone architecture (e.g. camera, address book, SIM card), which is the promise of where ‘Mobile AJAX’ is headed. However, this is still going to bring us up against the same sorts of problem that we have today if we don’t insist on a device architecture and ecosystem that supports updating the device. Just look at how often Firefox wants to update on the desktop. Once we allow browsers to become more intricately connected with the underlying platform, it’s going to be extremely difficult to support such developments without updates.

The ability to download data to the device via a short-range connection isn’t just useful for updating software, it’s great for updating content too. On-device portals have shown us that users will access more services and buy more content in the long run if they “bump into” it on their devices in the first place.

If you’re keen to mobilise your services and content today, then my advice is to accept that you’re going to have a limited user exposure and experience compared with desktop Web 2.0 services. Building mobile-only businesses on such a proposition remains doubtful in my opinion, unless mobile is an adjunct of something bigger within the Web 2.0 realm. Given the limitations, then one strategy is to offer a great user experience on only one or two devices, either via a rich browser or embedded environment, and an average experience on everything else, via the browser. Don’t be fooled into thinking that anything else is really possible or sensible.

[This blog has moved to here]