July 5, 2009

Observations: Mobile applications development

  • Buffer
  • Buffer

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

Ken Banks is founder of kiwanja.net, a site that helps nonprofits use mobile technology to serve their communities’ information needs. See his profile page, visit his blog, contact Ken or leave a comment. Follow Ken on Twitter at @kiwanja.

Print Friendly, PDF & Email
  • 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?

    1. If you put your project out there (open source) from the beginning there is for more chance of early collabration (& by the why – it's not tricky unless you want to make it tricky – just stick a GPL v3 license on it and put your code for download on sourceforge – that's usually it).
    2. You will need source code control – why not use sourceforges SVN
    3. Open source is more attractive to funders
    4. It is easier to promote your idea if there is already something for people to look at rather than just an idea you are working on – it shows you are serious
    5. You either want it to be open source or not – why beat around the bush

    • Hi Rob

      I totally agree with much of what you say. However, in our experiences with FrontlineSMS open sourcing was challenging due to some tricky and complex licensing issues which we never expected. Someone like yourself may be well versed in open sourcing a project, but for people who don't have that knowledge I'd say you're better off concentrating on building something that works and has potential in the field, before you end up spending a lot of time (like we had to) figuring out open source licenses.There's a lot of focus around open source and mobile right now – I posted more of my thoughts on this here:



      • Hi Ken,

        I agree that in the real world you have to take a very pragmatic approach to application development and licensing issues definately shouldn't be an obstacle to producing something.

        That said I would certainly encourage any potential mobile applications developer to get a basic understanding of open source because it probably will prove very useful for them in the future – One of the best introductions to open source is at http://en.wikibooks.org/wiki/Open_Source

        • Hi Rob

          Thanks for the link. Very helpful. I agree that it makes sense to have an understanding of the open sourcing process. For me, I was expecting it to be quite simple, but there were certainly challenges!

          Good to connect here.


  • I just returned from presenting mobile ICT to several audiences. The hearerswere all expecting an explanation of the latest technology and recommendations for specific tools for development program deployment in the field. they received neither. Instead, after a brief intro, it involved more of what Ken has more eloquently (and once again, more succinctly) described. The tool selection is one of the last activities after the requirements and context is not only understood, but more or less agreed upon by the stakeholders. This is exasperatingly difficult to do, but this "hard" work must be done prior to deployment. I work on mutual understanding and agreement until I see those faces are nodding up and down in agreement. Then, based on cost and schedule, decide when to break it off and either proceed or abandon in favor of a new direction, i.e. "hitting the wall".