Social mobile: Myths and misconceptions

A couple of weeks ago – in “The long tail revisited” – I briefly touched on the topic of “myths in the social mobile space”. It wasn’t the major focus of the post, but as is often the case it kicked off a completely separate discussion, one which took place largely off-blog in the Twitterverse and via email. I’ve been thinking more about it since, particularly as the social mobile space continues to hot up and people begin to face tools and projects off against one another – sometimes for the right reasons, more often for the wrong.

So, here’s my current “Top Ten” myths and misconceptions in this emerging field. Feel free to add, remove, agree, disagree, debate or dismiss. In no particular order…

1. “High-end is better than low-end”
Firstly, one mobile tool should never be described as being better than the other – it’s all about the context of the user. There is just as much a need for a $1 million server-based, high bandwidth mobile-web solution as there is for a low-cost, SMS-only PC-based tool. Both are valid. Solutions are needed all the way along the “long tail“, and users need a healthy applications ecosystem to dip into, whoever and wherever they may be. Generally speaking there is no such thing as a bad tool, just an inappropriate one.

Server Farm - via Flickr (Jemimus)

2. “Don’t bother if it doesn’t scale”
Just because a particular solution won’t ramp-up to run an international mobile campaign, or health care for an entire nation, does not make it irrelevant. Just as a long tail solution might likely never run a high-end project, expensive and technically complex solutions would likely fail to downscale enough to run a small rural communications network. Let’s not forget that a small deployment which helps just a dozen people is significant to those dozen people and their families.

3. “Centralised is better than distributed
Not everything needs to run on a mega-server housed in the capital city, accessed through “the cloud“. Okay, storing data and even running applications – remotely – might be wonderful technologically, but it’s not so great if you have a patchy internet connection, if one at all. For most users centralised means “remote”, distributed “local”.

4. “Big is beautiful”
Sadly there’s a general tendency to take a small-scale solution that works and then try to make a really big version of it. One large instance of a tool is not necessarily better that hundreds of smaller instances. If a small clinic finds a tool to help deliver health care more effectively to two hundred people, why not simply get the same tool into a thousand clinics? Scaling a tool changes its DNA, sometimes to such an extent that everything that was originally good about it is lost. Instead, replication is what’s needed.

Toolbox from Flickr (_sarchi)

5. “Tools are sold as seen”
I would argue that everything we see in the social mobile applications ecosystem today is “work in progress”, and it will likely remain that way for some time. The debate around the pros and cons of different tools needs to be a constructive one – based on a work in progress mentality – and one which positively feeds back into the development cycle.

6. “Collaborate or die”
Although collaboration is a wonderful concept, it doesn’t come without its challenges – politics, ego and vested interests among them. There are moves to make the social mobile space more collaborative, but this is easier said than done. 2009 will determine whether or not true non-competitive collaboration is possible, and between who. The more meaningful collaborations will be organic, based on needs out in the field, not those formed out of convenience.

7. “Appropriate technologies are poor people’s technologies”
A criticism often aimed more broadly at the appropriate technology movement, locally-powered, simple low-tech-based responses should not be regarded as second best to their fancier high-tech ‘Western’ cousins. A cheap, low-spec handset with five days standby time is far more appropriate than an iPhone if you don’t live anywhere near a mains outlet.

kiwanja Mobile Gallery

8. “No news is bad news”
For every headline-grabbing mobile project, there are hundreds – if not thousands – which never make the news. Progress and adoption of tools will be slow and gradual, and project case studies will bubble up to the surface over time. No single person in the mobile space has a handle on everything that’s going on out there.

9. “Over-promotion is just hype”
Mobile tools will only be adopted when users get to hear about them, understand them and are given easy access to them. One of the biggest challenges in the social mobile space is outreach and promotion, and we need to take advantage of every opportunity to get news on available solutions – and successful deployments – right down to the grassroots. It is our moral duty to do this, as it is to help with the adoption of those tools which clearly work and improve people’s lives.

10. “Competition is healthy”
In a commercial environment – yes – but saving or improving lives should never be competitive. If there’s one thing that mobile-for-development practitioners can learn from the wider development and ICT4D community, it’s this.

Mobile applications development: Observations

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)