Mobile app / web responsiveness

Posted on March 20, 2014


In short: Ensure your apps react quickly (sub 1 second), and tell the user when delays are expected, because with a flaky mobile connection these delays can happen more often than you’d like.

For many years at the birth of the internet there was a lot of effort in making web pages load fast over modems.

With the onslaught of bandwidth and miniaturisation of latency that came with broadband, we saw that this focus on load time was less important.  As a result pages ballooned in size loaded with lovely graphics, gorgeous typography and loaded with <insert favourite expletive/purr of contentment here> adverts.
Why am I telling you all this,  well with mobile services it is vital that one considers the service (app or web page) responsiveness as users are very likely to be distracted if you don’t.  Back in the days of Vodafone Live (mid to late 2000’s) we had a 400ms target for the servers to respond so that the page render times were in the sub 4 seconds range.  That is no longer acceptable.  So what is ?
Well I saw this set of slides from the [not so] recent Over the Air event,  it reminded me that we must consider usability not just in terms of functionality (or lack of) but also in the non-functionals, such as responsiveness
time and user perception
The author of the slides goes on to explain how you can design your pages to load far more efficiently,  thus trending towards all updates being painted to screen before the 1 second window is up.
He also makes the point that the network delays (we call it latency) is something that you just have to live with and gives a figure of c. 250 ms,  and without his speaker notes I am not sure what he said,  however I’d like to point out that the latency is variable,  and can change from good (<200ms) to awful 4  or even 5 whole seconds,  and as such you should, as a mobile service, take this into account and be ready to support the user through this.  Warnings, or letting the user know you are going back to the server, and therefore a variable length delay is unavoidable, will help them be prepared, and not be so concerned that the system has stopped working.  Of course this does not defeat the distraction issue, the butterfly nature of our brains to flit from thing to thing,  but it will mitigate their mood.
One strategy for minimising delays over a flaky mobile connection, is to pre-fetch data or content,  and hold it locally,  this is more acceptable now as folks tend to have larger data allowances than of old,  so the costs to the user are less. Of course the trick is knowing which content to send in advance,  and there are systems that can work this out from analytics on the server side.
So in summary make sure, that when you design an app you consider the impact of potentially long waits,  do all the tricks (see the presentation for a few good ones) to improve responsiveness, and be ready to warn the user.
Posted in: Apps, Architecture, mobile