Tag: software development

Cometh the hour. Cometh the technology.

55 Comments

For NGOs and developers alike, the ICT4D space can be a tough nut to crack. While NGOs generally struggle to find the tools they need to meet their particular needs, developers face the opposite problem – getting their tools into the hands of those who need them the most. Attempts to connect the NGO and developer communities – physically and virtually – continue to this day with varying degrees of success. There is no magic bullet.

Of course, bringing together the two parties in one place – community website, conference room or chat room – is only a small part of it. Getting them to understand each others needs, often over a technologically-fuelled chasm, can be another. While one side may approach things from a “technology looking for a problem” angle, NGOs often have it completely the other way round.

One of the earlier attempts to join the non-profit/developer dots took place in February 2007 in the boldly titled UN Meets Silicon Valley conference, where the United Nations met up with a bunch of Silicon Valley companies to explore how technology and industry could bolster international development. Lower-profile events also began to emerge around that time, often in the form of ‘user generated conferences’ such as BarCampAfrica (held in 2008) which aimed to:

… bring people, institutions and enterprises interested in Africa together in one location to exchange ideas, build connections, re-frame perceptions and catalyse action that leads to positive involvement and mutual benefit between Silicon Valley and the continent of Africa

Having worked for many years in the non-profit sector, particularly in developing countries, I’ve seen at first-hand the kind of challenges many face, and their frustration at the lack of appropriate ICT solutions available to them. I’ve also been on the developer side of the fence, spending much of the last six years developing and promoting the use of FrontlineSMS. Unfortunately, despite what you might think, seeing the challenge from both perspectives doesn’t necessarily make finding a solution any easier. Getting FrontlineSMS, for example, into the hands of NGOs has become slightly easier over time as more people get to hear about it, but it’s been largely a reactionary process at a time I’d much rather have been proactive. No magic bullet for me.

Sadly, for every ICT solution that gains traction, many more don’t even see the light of day. While you may argue those that failed probably weren’t good enough, this isn’t always the case. Take Kiva as a case in point. In the early days Matt and Jessica Flannery were regularly told by ‘experts’ that their idea wouldn’t work, that it wouldn’t scale. They didn’t give up, and today Kiva is a huge success story, connecting lenders – you and me – to small businesses in developing countries the world over. Since forming in late 2005 they have facilitated the lending of over $200 million to hundreds of thousands of entrepreneurs in some of the poorest countries in the world.

A key turning point for Kiva was their decision to switch from business plans to ‘action’ plans, getting out there and building their success from the ground up. Some of us would call this “rapid prototyping”, or “failing fast”. Whatever you choose to call it, it’s an approach I firmly believe in. In places like Silicon Valley getting it wrong isn’t seen as a bad thing, and this encourages a “rapid prototyping” culture. Sadly the story is very different in the UK.

Some projects – Kiva and FrontlineSMS among them – are based on experiences gained in the field and the belief that a particular problem can be solved with an appropriate technological intervention. Of course, before any ICT4D solution can succeed there has to be a need. It doesn’t matter how good a solution is if people don’t see the ‘problem’ as one that needs fixing. In the case of Kiva, borrowers were clearly in need of funds, yet lenders lacked access to them. With FrontlineSMS, grassroots non-profits were keen to make use of the growing numbers of mobile phones among their stakeholders, but lacked a platform to communicate with them. These two initiatives worked because they were problems that not only found a solution, but a solution that was appropriate and one that was easy to deploy.

The ICT4D space is exciting and challenging in equal measure, and by its very nature practitioners tend to focus on some of the most pressing problems in the most challenging parts of the world. Whether it’s a natural disaster, a stolen election, human-wildlife conflict, a crushed uprising or a health epidemic, elements of the ICT4D community spring into action to either help co-ordinate, fix, or report on events. Interestingly, it can sometimes be the events themselves which raise the profile of a particular ICT solution, or the events themselves which lead to the creation of new tools and resources.

In 2006, Erik Sundelof was one of a dozen Reuters Digital Vision Fellows at Stanford University, a programme I was fortunate enough to attend the following year (thanks, in large part, to Erik himself). Erik was building a web-based tool – “inthefieldonline” – which allowed citizens to report news and events around them to the wider world through their mobile phones. This, of course, is nothing particularly new today, but back then it was an emerging field and Erik was at the forefront. During the final weeks of his Fellowship in July 2006, Israel invaded Lebanon in response to the kidnapping of one of their soldiers. Erik’s tool was picked up by Lebanese civilians, who texted in their experiences, thoughts, hopes and fears through their mobile phones. The international media were quick onto the story, including CNN. Erik’s project was propelled into the limelight, resulting in significant funding to develop a new citizen journalism site, allvoices, which he ran until recently.

In a similar vein, it took a national election to significantly raise the profile of FrontlineSMS when it was used to help monitor the Nigerian Presidential elections in 2007. The story was significant in that it was believed to be the first time civil society had helped monitor an election in an African country using mobile technology. As the BBC reported:

anyone trying to rig or tamper with Saturday’s presidential elections in Nigeria could be caught out by a team of volunteers armed with mobile phones

Although FrontlineSMS had already been around for over eighteen months at that time, its use in Nigeria created significant new interest in the software, lead to funding from the MacArthur Foundation and ended with the release of a new version the following summer. The project has gone from strength to strength since.

One of today’s most talked-about platforms also emerged from the ashes of another significant event, this time the troubles following Kenya’s disputed elections in late 2007. With everyday Kenyans deprived of a voice at the height of the troubles, a team of African developers created a site which allowed citizens to report acts of violence via the web and SMS, incidents which were then aggregated with other reports and displayed on a map. Ushahidi – “witness” in Kiswahili – provided an avenue for everyday people to get their news out, and news of its launch was widely hailed in the mainstream press. The creation of Ushahidi is a textbook study in rapid prototyping and collaboration.

The interesting thing about all these projects is that they all proved that they worked – i.e. proved there was a need and developed a track record – before receiving significant funding. Kiva got out there and showed that their lending platform worked before major funders stepped in, just as FrontlineSMS did. And Ushahidi put the first version of their crowdsourcing site together in just five days, and have reaped the benefits of having that early working prototype ever since. If there is a lesson to learn here then it would have to be this – don’t let a lack of funding stop you from getting your ICT4D solution off the ground, even if it does involve “failing fast”.

Of course, not everyone can rely on an international emergency to raise the profile of their project or big idea, and it wouldn’t be wise to bet on one ever happening, either. But when it does, an obvious lack of a solution to a problem often rises to the surface, creating an environment where tools which do exist – whether they are proven or not – are able to prosper for the benefit of everyone.

Building mobile applications for social good

80 Comments

“If you were thinking of designing or building a website, you’d be in luck. If you were thinking of writing a suite of financial management tools, you’d be in luck. If you were even thinking of creating the next big video game, you’d be in luck. Visit any good bookstore and the selection of self-help books and “how-to” guides leave you spoilt for choice. 

Unlike the plethora of self-help guides on the more established topics, if you were looking to do something with mobile phones you’d likely have mixed results. There are plenty of books available extolling the virtues of Java, Python, Ruby, Ruby on Rails, C++, Symbian, Android and just about any other development environment or platform out there. Combine that with the growing field of mobile UI (user interface) design and you’d think that pretty much everything was covered. But there is one thing missing, although you’d probably only notice if you’re one of a growing number of developers turning their attention to the developing world”.

I’m talking about a guide on “Building Mobile Applications for Social Good“. Although just a start, this article – written for The Testing Planet – in part aims to fill that gap. At conferences and seminars I often talk about our experiences developing FrontlineSMS, and the thinking and fieldwork behind it, but until now much of this wasn’t particularly well captured in written form in a single place.

A PDF of the “Building Mobile Applications for Social Good” article is available via the kiwanja website here [2 Mb]. A PDF of the full edition of this month’s Testing Planet is available on their website here.

The Testing Planet is a magazine produced by The Software Testing Club and its community members. The magazine is published in print, ebook, Kindle, PDF and web format. You can follow them on Twitter at @testingclub

Further reading
Check out an earlier article – “Mobile Design. Sans Frontieres” – co-written with friend and colleague Joel Selanikio, and the wider “Mobile apps development” category in this blog.

Mobile applications development: Observations

32 Comments

Technology and democracy: both great in theory, a little harder in practice. One of the key challenges is that one successful model doesn’t – by default – work somewhere else. For mobile techies, if we can’t easily ‘transplant’ a solution from one place to another, where does our “figure out what works” mantra leave us? What relevance does it have? Have we ever managed to “figure out what works” and make it work somewhere else, geographically? Is it even possible, or is it just a good industry sound bite?

Progress in the social mobile field will come only when we think more about best practices in the thinking and design of mobile projects and applications, rather than obsessing over the end products themselves. By then most of the damage has usually already been done. In my experience, many social mobile projects fail in the early stages. Lack of basic reality-checking and a tendency to make major assumptions are lead culprits, yet they are relatively easy to avoid. I would argue that successful mobile projects – those aimed at developing countries in particular – have a better chance of succeeding if some or all of the following are considered from the outset.

Women queue for water in Bushbuckridge, South Africa (photo Ken Banks, kiwanja.net)

Firstly, think carefully if you’re about to build a solution to a problem you don’t fully understand.

Check to see if any similar tools to the one you want to build already exist and, if they do, consider partnering up. Despite the rhetoric, all too often people end up reinventing the wheel.

Be flexible enough in your approach to allow for changing circumstances, ideas and feedback. Don’t set out with too many fixed parameters if you can help it.

From the outset, try to build something that’s easy enough to use without the need for user training or a complex manual, and something which new users can easily and effortlessly replicate once news of your application begins to spread.

Think about rapid prototyping. Don’t spend too much time waiting to build the perfect solution, but instead get something out there quickly and let reality shape it. This is crucial if the application is to be relevant.

Never let a lack of money stop you. If considerable amounts of funding are required to even get a prototype together, then that’s telling you something – your solution is probably overly complex.

Learn to do what you can’t afford to pay other people to do. The more design, coding, building, testing and outreach you can do yourself, the better. Stay lean. These tasks can be outsourced later if your solution gains traction and attracts funding. The more you achieve with few resources the more commitment and initiative is shown, increasing the chances a donor will be attracted to what you’re doing.

Don’t be too controlling over the solution. Build an application which is flexible enough to allow users, whoever and wherever they may be, to plant their own personalities on it. No two rural hospitals work the same way, so don’t build an application as if they did.

Think about building platforms and tools which contribute to the solution for the users, rather than one which seeks to solve and fix everything for them. Let them be part of it. Think about how your imported solution looks to a local user. Are they a passive recipient of it, or can they take it and turn it into their solution? A sense of local ownership is crucial for success and sustainability.

Ensure that the application can work on the most readily and widely available hardware and network infrastructure. Text messaging solutions aren’t big in the social mobile space for nothing. And, for the time being, try to avoid building applications which require any kind of internet access, unless you want to restrict your target audience from the outset.

Every third party the user needs to speak to in order to implement your solution increases the chances of failure by a considerable margin, particularly if one of those parties is a local mobile operator.

Be realistic about what your application can achieve, and wherever possible look for low-hanging fruit. Remember – big is not better, small is beautiful, and focus is king. A solid application which solves one element of a wider problem well is better than an average application which tries to solve everything.

Bear in mind that social mobile solutions need to be affordable, ideally free. Business models, if any, should be built around the use of the application, not the application itself. Easier said than done, so try to engage business studies graduates at universities, many of whom are always looking for cool social-change projects to work on.

Leverage what local NGOs (or users) are best at, and what they already have – local knowledge, local context, local language and local trust among local communities. Remember that it’s unlikely you will ever understand the problem as much as they do, and that it’s always going to be easier to equip them with tools to do the job than it will ever be for you to learn everything they know.

Don’t waste time or energy thinking too much about the open sourcing process (if you decide to go that route) until you know you have something worth open sourcing. (And, by the way, the users will be the ones to let you know that).

Don’t build an application for an environment where it may politically (or otherwise) never be adopted. For example, a nationwide mobile election monitoring system would need government buy-in to be implemented. Governments which commit election fraud to stay in power are unlikely to adopt a technology which gives the game away.

Consider controlling distribution and use of your application at the beginning. Not only is it a good idea to be able to contact users for feedback, donors will almost always want to know where it is being used, by who and for what. Neglect to collect this data at your peril.

Promote your solution like crazy. Reach out to people working in the same technology circles as you, post messages on relevant blogs, blog about it yourself, build a project website, try and brand your solution, and make use of social networking tools such as Twitter and Facebook. Although your target users may not be present, many are likely to be fairly resourceful, and the more people talking about your solution the more likely news is to filter down to them.

Finally, build a community around the application, encourage users to join and share experiences, and to help each other. Don’t be afraid to reach out for additional information, and work hard to keep it active, engaging and growing. Communities are notoriously hard to build, but when they work they’re worth it.

This blog post is also available as a PDF.

Note: I followed up on this post with an article for PC World – “Social Mobile Applications: The Missing Book“. (An index of all kiwanja PC World articles is available here)

Nokia: “Developing markets”?

Ka-Torchi poster, Uganda. Photo: Ken Banks, kiwanja.netIt’s official. Or so it seems. Already the most active handset manufacturer in the developing world, Nokia today made an announcement which places it well and truly at the heart of the international development effort. It’s a move which mirrors their ‘developed world’ strategy – a move from out-and-out hardware supplier to one of a more inclusive services-based outfit. As if (very) successfully designing and building low-cost handsets for emerging markets wasn’t enough, Nokia will now start offering emerging-market specific data services through their low-cost phones. And we’re not talking music or games here. We’re talking agriculture and education, and that’s just for starters.

According to today’s November 2008 Press Release:

“In 2002, Nokia unveiled a strategy to lower the cost of owning and operating a mobile phone and to bring the benefits of mobile telephony to people in emerging markets. Today, we are expanding that vision by introducing a number of devices and services that aim to bring the power of the Internet to these markets as well. The mobile device and the Internet are a powerful combination in connecting people with each other, accessing information, news, entertainment and sharing. By introducing products and services that are affordable, relevant and easy-to-use, we believe Nokia can fuel the growth of the Internet in emerging markets through mobility”

The announcement is interesting on a number of fronts. In addition to their move into ‘social mobile’ services – something previously the domain of the ICT4D community and a handful of innovative companies who managed to figure out working business models – Nokia also announced “Mail on Ovi” which enables Series 40 users to set up and run email accounts without the need to go anywhere near a personal computer. The mobile browsing world is also set for a shake-up with the announcement of new low-cost internet-enabled handsets, including the Nokia 2323 Classic (pictured) with a price point of just €40.

A little over a year ago, in a post called The Digital Divider, I made the point:

“The opportunity at the bottom of the pyramid is huge, and handset manufacturers and network providers alike are working hard to fill it with phones. For them, the most important issue is cost because that’s what’s most important to their customer. And if this means providing trimmed-down handsets at the lowest possible prices then so be it.

This current reality sees many of these phones with no GPRS, no browser, no Java, no camera, no colour screen – the very technologies which form the lynchpin of our plans to promote the mobile phone as the tool to help close the digital divide”

The emergence of feature-rich sub-$50 handsets isn’t necessarily a game changer on its own, but it’s a significant step in the right direction. Cheap as it may be, even the Nokia 2323 Classic is still around $25 off target from a comfortable price-point for many BOP customers, assuming they’re among the target audience. The shared phone culture in many developing markets could of course come to the rescue, allowing a single web-enabled phone to open up web access for many people, assuming shared phone functionality (private bookmarks, cookies, browsing history, and so on) is made available. It’s not clear whether this has been.

It’s the addition of Nokia Life Tools – agricultural and educational services – which raises eyebrows almost as much as it raises the bar. How will Nokia’s move into providing agricultural data and advice to farmers effect, for example, the operations of Trade At Hand, DrumNet, Manobi or TradeNet? Will they be partners in any Africa-wide venture? (Nokia do seem to be developing a habit of going-it-alone – more recently with their release of Nokia Data Gathering – rather than working with established, existing open source tools). For now, Nokia Life Tools will only be available in India, giving everyone – including Nokia – plenty of time to see how this thing plays out:

“Nokia Life Tools is a range of innovative agriculture information and education services designed especially for rural and small town communities in emerging markets. Nokia Life Tools helps overcome information constraints and provides farmers and students with timely and relevant information. These services use an icon-based, graphically rich user interface that comes complete with tables and which can even display information simultaneously in two languages. Behind this rich interface, SMS is used to deliver the critical information to ensure that this service works wherever a mobile phone does, without the hassles of additional settings or the need for GPRS coverage. Nokia plans to launch the service in the first half of 2009 with the Nokia 2323 classic and the Nokia 2330 classic as the lead devices in India, and expand it across select countries in Asia and Africa later in 2009”

So, what next? Nokia develop a mobile payments platform and embed the client into all of their emerging market handsets? Imagine, a single company controlling the entire mobile technology value chain would make interesting viewing. It could well be the answer to the age old fragmentation problems suffered by the “social mobile” and ICT4D space, but would this give the Finnish giant Google-esque powers?

These are interesting times. And for once, it’s the users at the bottom of the pyramid who stand to gain the most.