As web application developers we tend to build for always connected scenarios. They simplify the problem of web development and allow us to keep the complexity of our solution hidden on web and application servers back at corporate headquarters.
Pity the poor rich GUI developer who needed to handle both connected and disconnected modes – mainly for corporate management with laptops. This requirement increased the complexity of their applications and forced sharing of business logic with the client GUI layer. Recently mobile developers have realised the need to provide the same service, and with HTML5 web developers are now being pushed to as well.
At the same time, the ability of any client machine to get connected is increasing dramatically. Modern cities provide plentiful sources of free, commercial public and private wifi services, and most modern telecommunications devices allow for secondary use as internet modems.
It is now clear that most web applications/websites are likely to be accessed via mobile devices, and there are far more people with internet access via their mobile devices than via landlines/roaming broadband.
One might wonder whether disconnected clients still need to be supported, or whether the vast majority of clients in the vast majority of locations are best handled by assuming connected, always-on access?
The problem with this thinking is that it ignores a fundamental truth:
“Space is big. Really big.” – The Hitchhikers Guide to the Galaxy
OK, so these are not all apps that will be used in space (has the first iPhone gone to space yet?), but they can’t all assume that the user is always connected.
There are two fallacies with the premise of always-on access, the first is assuming that most people’s situations mimic the developers’ own ultra-connected, hyper-geek, lives, the second is limiting “everywhere” to the points on the daily commute. For most people in the world, in most places, there are going to be frequent losses of signal – even in Australia most telcos can’t get reliable mobile signal to all urban locations, let alone cover the vastness of our Outback.
Of course mobile developers know this is a problem, and might decry that their app can handle the phone losing and resuming signal flawlessly. But is there still value in the app when it is disconnected?
The most interesting opportunities lie with providing access to applications that can still provide value during the occasional disconnection – these are the applications that will be truly useful all the time and everywhere. For example the mapping application on my Nokia N85 can operate with three levels of connection:
- Connected to the internet and GPS.
In this mode I get the latest map updates and can tell where I am on the map.
- Connected to GPS only.
In this mode the maps used are the ones stored locally but my current location is derived from GPS.
In this mode the maps are available to be read, queried or manually moved around on, but my current location is not available.
Even in the most disconnected mode the maps are useful, I can lookup addresses and perform most of what I would have with an old-school street directory. When they connect further I get increasing amounts of value. Because of this sort of disconnected operation, the map and email applications are the most useful aspects of the phone to me (the other is the clock). They are more useful than a static application because they can occasionally connect and update themselves.
There is a term for this sort of behaviour that web developers have coined with websites that offer substantial value for all browser clients, but increase their value for some special browser clients.
The point is to view the extra potential as something great to have, but not necessary for the application to fulfil its value proposition.
I really think this is the killer feature for a mobile app – provided of course that there can still be a value proposition in the disconnected mode. I also think that the best mobile apps will be web apps that respond and adapt to the restrictions of the mobile space rather than custom built ghetto-apps that can only prosper in one particular mobile OS. But that can be another post …