This is long-due post on designing web tools for ”limited connectivity” contexts, a challenge I’ve addressed in several projects at Reflab, and that can better described as a “compilation” of requirements and constraints.
My goal here is to draw attention to the topic and summarize what it means to access a web tool from the “fields”: emergency situation, remote or just under-served areas of the world, where humanitarian relief takes place. There is nothing really new, but it is worth having very clear when developing products that require an Internet connection, either for PCs or mobile devices (and there are many, you know…).
I’d rather not talk (and rant) about how data could be managed and information organized, I want just to make an overview of the technical challenges and solutions to making better web tools.
Limited connectivity
Connectivity is just a promise still for many on our planet: in large urban settings, and places like the north of Europe it is even difficult to imagine but in a crisis, in an emergency, in rural contexts, in remote areas of developing countries the best you can get is: limited connectivity.
TelecomMap maps 3G Networks, Network Quality and Wi-Fi hotspots in Indian cities (powered by Ushahidi)
Imagine you’re on a train (in Italy, this time, and if you are not familiar with Italian trains, good for you): you need to access a website or use an online application, they promised you 3G or better, but in fact you get a lot less. You pick up your mobile, type the web address and your spinner spins, but nothing appear on your browser, finally you get some elements of the page but, no luck, a series of tunnels starts. Patiently you wait, retrying from time to time, your page loads then stops, then reload, Finally the train is now past the tunnels in the nice countryside: you try again, the page loads… slowly, and finally you have it. You click on the link you were looking for, it works! Now back to the previous page and oops! connection is gone again.
As Imna Gonzales (Organizations and Systems Responsible at MSF Spain), puts it:
“Vendors design their products from a very well connected office in some large US/European city, and their regularly fail to understand how much things can be different in the areas we operate”.
This is limited connectivity: you have some bandwidth, you have bad to awful latency (don’t even think playing online games), and connection goes up and down more or less frequently and, in many places, you do not have any connection at all. Depending on location and time you get a mix of all of the above (in office good connectivity, in cybercafé some connectivity, here a 3G, here SMS only, here nothing!). Unstable. Note also that I’m simplifying a lot by focusing only on web and mobile (smartphones) and assuming the (limited) connectivity is relatively cheap).
Hints for designers and developers
Page weight
Speed and performances
Just after page weight, and event more important, comes the speed and performances. While having well responding, fast systems is a general principle for usable software in the case of limited connectivity they can really make the difference. There are two sides of it:
Server side
Speed and performances are far too complex to discuss here, let’s just note that worst-than-average performances will sum up with page weight and client side performances to make it really impossible for some people to use the system in limited connectivity conditions.
Client side
Cache
A good old way of speeding up things is caching: server cache, browser cache and “supercache” (see HTML5 Application Cache). Even for small projects a good use of the browser cache, maybe even of the new application cache can bring very significant improvements reducing transferred data from hundreds of Kb to a less than a hundred Bytes. Server caching is not always good for every project, in my experience and, as my friend Federico (system administrator) keeps reminding me:
“There are only two hard things in Computer Science: cache invalidation and naming things” - Tim Bray
