We’re never good enough when it comes to speed, stability or simplicity of our mobile and web applications. This is a three-part series where I unpack my experience building apps on each of these subjects. It’s not just for those of us working on Ushahidi, these are the three most crucial abilities of any web or mobile application.
Let me tell you a personal story:
Libera, March 2009
I’m sitting, sweating in the sweltering heat of a Monrovia cyber cafe, I have my notebook out and my am watching the clock. My goal is to see how fast I can load up the Ushahidi home page for the Democratic Republic of the Congo, it has a map, timeline and list of recent events tracking the current level of unrest in the country.
It’s not looking good. As I look around, waiting for the page to load, I count 8 others in the room – 6 of which have fired up stuttering and unusable Yahoo and Skype video chat windows. Why this is the channel and usage of choice, when it so obviously doesn’t work, I cannot answer. But this is reality, and if we expect ordinary Africans to use our application, we had better make sure that it loads up relatively fast on the low-bandwidth, shared internet connections that proliferate across the continent.
Utter failure. After 20 minutes painfully watching the page load byte by byte, I give up. I quickly type out a message to our team, imploring everyone to streamline this “fat, squeeling pig of a page”. Peppering them with questions… Can I buy some caching please? What can we do with this map to make it not kill the load? Can we get rid of 75% of the images on the page? Do we need to redesign this from the ground up?
Granted, Liberia’s internet situation is worse than almost any other on the continent. Especially when it comes to the grinding halt you see in the cyber cafes during the daylight hours as the local population piles on at the same time, completely overwhelming the limited satellite connection. That’s no excuse though. Ushahidi is built on the idea that the lowest common denominator, whether it’s PC or mobile-phone based access, will work. The PC-side is clearly failing.
Worst of all, my patience is short, Liberia is pissing me off with the heat, humidity, lack of bandwidth and no electricity grid. Objectively, this is the perfect state to be in, I am now able to come up with a solution for normal users in Africa.
What other’s know
Speed… if there’s only one thing that you do with your application, make it faster. No, it’s not fast enough.
This isn’t news to anyone, or it shouldn’t be. For years the major web sites around the world have known this and have been building for it. Mozilla, Amazon, Google and Facebook are all aware of just how critical speed is to their success. It boils down to attention threshold and what we, as users ourselves, are willing to put up with.
There is no area in which our team has felt more pain than in trying to speed up the page loads of our apps. Maps tend to be page killers by themselves. Once we add multiple calls to the database we start to get some truly agonizing speeds. It’s a constant pressure that sits on every one of our development cycles, and for which we dedicate a great deal of energy.
User experience research needed in Africa
One area that hasn’t seen enough true user experience testing is Africa. We know that internet speeds are slower, sometimes by orders of magnitude. I’ve got a lot of questions, more than answers at this point. Should we cut out the maps and all images? What’s the true cost of a page load +/- 7 seconds? What is the real value of maps in Africa compared to the West – do they matter?
Jessica Colaco is a top-notch programmer who has shifted to doing research in Kenya. I hope that she, and others like Eric Osiakwan and his team from Internet Research in Ghana, will help us dig out these answers. More than that, I hope they will help us ask the right questions.
