Designing for limited connectivity

6 Apr

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).

Now imagine that the software you are building has to be used in those conditions by people with a very limited time, in a hurry, in an emergency, people how are working to save lives. If you build and maintain a product that has to operate in those conditions here are a few things you should always consider in the design, monitor and continue to improve:

Hints for designers and developers

Here are a few hints, starting points in fact, for designers and developers; good results can be achieved by just setting the bar higher on some common requirement: for example a slower than average site is less likely to be used, but in these contexts it will not be *possible* to use it. And keep monitoring, and keep caring.

Page weight

A classic. The first thing you hear about and usually followed by the request to have a huge banner, logo or video in the homepage. Lighter pages require great UI design, clean code and optimizations, and those don’t just come fore free, unfortunately.
A recent article on The Guardian by John Naughton, “Graphic designers are ruining the web” shows the awful trend of webpage obesity.
It is quite interesting to see how much data (before cache) we are downloading every time we open a web page: the home page of the CNN today have 948.22KB transferred, YouTube home page 1.4Mb, etc.

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

Most will focus their attention to the server, but it’s important to keep in mind that users might be browsing from old browsers and old hardware. I’ve never been a big supporter of old-browsers compatibility (especially IE), but a good product will try to avoid long rendering time and heavy Javascript.

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

Asynchronous calls

Particular handy to manage long list of documents and the huge banner in homepage, it is a very useful technique the UI designer should keep it mind: user will be able to immediately access new pieces of information or features, only downloading the necessary Bytes. For a simple example see the logcluster.org preview of documents.

Binary files management

Ok, this is getting even more technical, let me just mention file compression and a good management of the synchronization, if any.

Offline

If you know what I’ve been working on in the past months you know I have to talk about offline web: the most complete support to limited connectivity would include it, but note that having offline support does not mean all of the above can be skipped! Offline support means the site/application can work online and offline, if needed it updates (sync), and updating is “sensible” i.e. just update things that have changed, use compression for files, etc. See my post on HTML5 offline support.
Two examples: the Ushahidi mobile web application and OOPS (Online Offline Publication System). The year looks promising, the standards are being finalized, will browsers follow?

Final considerations

Products made to be used in emergencies, crisis, humanitarian operations, remote, unserved areas, etc. require a lot more than just tackling limited connectivity, of course, and several of the points above are true for every good software product in general. Important improvements can be also made by designing different information flows, data formats, interfaces, etc. The main point? whatever is your product, please care about limited connectivity and keep evaluating, monitoring and improving!
About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,132 other followers

%d bloggers like this: