Designing for the REAL 95%

As occasionally happens, Ken and I find ourselves on opposite sides of the world at conferences this week. Ken is at Mobile Web in Africa 2010, in Johannesburg, and I'm hereby asking him to tell you all about it here when he gets a minute. o/ I'm at Design for Persuasion in Ghent, Belgium, with a room full of people who've never heard of FrontlineSMS - this is only the second time I've done this kind of event, but it's something we're committed to doing because that's how we get the word out to new audiences. As I did after the Digital Indaba in July, I thought I'd post the gist of my talk here. You can also listen to an AudioBoo which I recorded in a far more coherent manner than the actual talk, shortly afterwards.

Sidenote: I showed, as I always do, Ken's favourite diagram of 'social mobile's long tail'. Related but different is the persuasion map we're all developing (read: wrangling over) live at the conference, at BJ Fogg's suggestion. It maps technologies along axes showing prominence versus usefulness. SMS has already moved from unknown to well known, and from useful to not useful, a couple of times. Will be interesting to see where it ends up - or who gives up first...

Since I joined the team back in March I've spent a lot of time emailing our users and begging them for stories and feedback about their experience. You can read a version of this plea here! Many of you have given generously of your time and energy to write and tell me your thoughts on the platform and the challenges of implementing using SMS.

Something that surprised me a bit was the low proportion of users who were utilising more than the most basic functionality in FrontlineSMS. Many, perhaps 90-95%, are using only the functionality up to and including keywords to automatically respond to incoming SMS, or simply organise incoming SMS. But not all are aware of additional plugins like the Reminders module and the enormous potential of Medic's PatientView. Even auto-subscribing people to groups via SMS is a step beyond what many have time to set up.This might be controversial - do people disagree? Am I getting a false picture?

If not, the low take-up of advanced features is probably to do with capacity and time - both for many of the small community-based organisations who are our target user, if we have such a thing, and for larger NGOs and international organisations. Indeed, we know at times people struggle to get basic FrontlineSMS functions working effectively and meshing well with their existing work. We're tremendously excited about the potential of new functionality and technology, and small groups of users will be able to make excellent use of them - but for the majority of users, basic troubleshooting, support and advice are critical.

In the coming weeks we'll be working on our plans for the software in 2011 - stay tuned for more from this from our Lead Developer, Alex. Our role in providing user guides and resources, advice and support, and even training is something we're also looking carefully at. As ever, we'd welcome your thoughts.

Our "social mobile" line in the sand

The depth and range of discussion generated by my last post on "the cloud" and "appropriate technology" may have come as something of a surprise, but one thing is clear. There's a great deal of misunderstanding around the topic, particularly with people who are either developing or promoting tools based on the very technology I was challenging. The only way to avoid this kind of confusion is to spell out our positions clearly, and I made this point in that very same post. So how do we move on from here? Well, we need to set out our positions clearly as a marker in the sand for future discussion. So, let me go first. To clear up any present and future confusion, here's the official FrontlineSMS / kiwanja.net position on what I consider five key "mobile tools for development" areas - location in the "long tail", scaling, replication and growth, open sourcing and access to "the cloud".

1. Who are your target audience?

Some time ago I butchered Chris Anderson's "long tail" concept and adapted it for mobile. It seemed like the best way of categorising the different focus areas for mobile tools - high-end for larger organisations down to low-end for small grassroots ones. Here's what I came up with.

The basic rationale behind the diagram is this. Tools in the red area are technically and financially out-of-reach of many grassroots NGOs, many of whom sit in the green space. Tools at the higher end of the graph are generally more complex, server-based systems which require a high degree of technical competence, and often the Internet, to set up and use. Tools in the lower end are simple, low-cost, need few technical skills, work on easily available hardware, don't require the Internet, and are easy to install and run. Tools in the green space can be quickly adopted and replicated - within hours - whereas tools at the other end need much more planning, i.e. more people and more lead time, and most likely a degree of training.

Note: There is no right or wrong or good or bad place on the tail. There are just different places

From its early beginnings in South Africa in 2004, FrontlineSMS has been totally focused on grassroots NGOs in the green space, an area which I believed back then was heavily underserved (and to a large degree still is). We're not particularly interested in big users such as international NGOs or government departments. So if our tool isn't considered right for the kinds of big projects they're likely to be running, then that's fine with us.

I wonder where the other social mobile tools would place themselves on the tail?

2. What is your position on scaling?

Believe it or not, not everyone wants to build tools that can grow into large centralised solutions, which is how many people seem to define scale. No one is ever going to run a nationwide election monitoring campaign running into millions of text messages using a single laptop, cable and mobile phone. FrontlineSMS is based on "horizontal scaling", gained by an increase in the numbers of individual users with their own systems. In other words, a hundred systems in a hundred clinics serving 10,000 people each, rather than one system adapted and "scaled up" to serve a million. We're happy and comfortable with this approach, as are our target audience of grassroots NGOs.

3. How does it replicate and grow?

Growth is based on patience, and a "pull" rather than "push" approach, i.e. awareness-raising and then letting NGOs decide if they want to try out the tool or not. Those that do then go and request it from the website. Everything is driven by the end user, who needs to be independently motivated to download and use the tool. There is no need for us to be involved at any stage, so no-one flies anywhere and no-one does any training - note that the approaches of FrontlineSMS:Medic and FrontlineSMS:Credit may be different - and no-one tries to "sell" FrontlineSMS to anyone. The solution is designed to allow users to do everything themselves. No core FrontlineSMS implementations are driven by us, and none are our projects. Use is replicated by users sharing experiences, talking about their use of the tool to others, and growing numbers of champions who are either building their own solutions around FrontlineSMS, or bloggers and researchers who write about its use and impact.

4. What is your position on open sourcing?

Again, from the very beginning we have been unashamedly focused on our end user - NGOs in developing countries seeking easy-to-deploy mobile tools. Our end users are not programmers, coders or technical developers, and few if any of our FrontlineSMS user base would have any idea what to do with source code. We decided that we would focus on the open source community once we believed we had something worth working with, and that time is about now. In between working on everything else, we plan to launch a developer community soon. That all said, there are already a number of developers bolting on new functionality to the core FrontlineSMS platform, and 90% of the code is already available online and accessible through SourceForge.

5. Does access to "the cloud" matter?

FrontlineSMS only came about four years ago because of a critical lack of tools that allowed for group messaging without the need for the Internet. Building a tool which is able to operate in Internet-free zones has therefore been central to our thinking since the very beginning, and continues to this day. Beyond basic messaging, FrontlineSMS can make use of an Internet connection when and where available - messages can be forwarded via email, or posted to websites, for example (that's the functionality Ushahidi takes advantage of) - but no Internet is not a show stopper for us. And as time moves on and connectivity does improve, we'll be ready. We're adding picture messaging in the next couple of months (for example), and other web-based features are in the pipeline. We are not anti-Internet, but realistic when it comes to its availability and reliability.

So, that's our line in the sand. If anyone else has a mobile tool - or is working on a mobile tool - I'd encourage them to clear up any possible confusion and write a post outlining their thinking in these five areas. The alternative is more confusion, and more false arguments and comparisons.

I know I'd love to know the thinking behind more social mobile tools, and going by the reaction earlier this week, it looks like I'm not the only one. Now is a good-a-time as any to join the conversation.

Read responses and "lines in the sand" from:

FrontlineSMS:Credit FrontlineSMS:Medic

(As of 20th December, no other mobile tools providers have responded, which is a shame. May the confusion and misrepresentation continue...)

The Social Mobile Long Tail explained

What follows is a short extract from the recent "Soul of the New Machine" human rights/technology conference hosted by UC Berkeley, in which I explain my theory of the Social Mobile Long Tail.

This video is also available on the FrontlineSMS Community pages

A full video of the session - PDA's and Phones for Data Collection - which includes presentations from InSTEDD, Ushahidi, DataDyne and Salesforce.com, is available via the FORA.tv website.

A glimpse into social mobile's long tail

Although I've only been writing about the social mobile long tail for a couple of years, the thinking behind it has developed over a fifteen year period where, working on and off in a number of African countries, I've witnessed at first hand the incredible contribution that some of the smallest and under-resourced NGOs make in solving some of the most pressing social and environmental problems. Most of these NGOs are hardly known outside the communities where they operate, and many fail to raise even the smallest amounts of funding in an environment where they compete with some of the biggest and smartest charities on the planet.

Long tail NGOs are generally small, extremely dedicated, run low-cost high-impact interventions, work on local issues with relatively modest numbers of local people, and are staffed by community members who have first-hand experience of the problems they're trying to solve. What they lack in tools, resources and funds they more than make up with a deep understanding of the local landscape - not just geographically, but also the language, culture and daily challenges of the people.

After fifteen years it should come as no surprise to hear that most of my work today is aimed at empowering the long tail, as it has been since kiwanja.net came into being in 2003, followed by FrontlineSMS a little later in 2005. Of course, a single local NGO with a piece of software isn't going to solve a wider national healthcare problem, but how about a hundred of them? Or a thousand? The default position for many people working in ICT4D is to build centralised solutions to local problems - things that 'integrate' and 'scale'. With little local ownership and engagement, many of these top-down approaches fail to appreciate the culture of technology and its users. Technology can be fixed, tweaked, scaled and integrated - building relationships with the users is much harder and takes a lot longer. Trust has to be won. And it takes even longer to get back if it's lost.

My belief is that users don't want access to tools - they want to be given the tools. There's a subtle but significant difference. They want to have their own system, something which works with them to solve their problem. They want to see it, to have it there with them, not in some 'cloud'. This may sound petty - people wanting something of their own - but I believe that this is one way that works.

Here's a video from Lynman Bacolor, a FrontlineSMS user in the Philippines, talking about how he uses the software in his health outreach work. What you see here is a very simple technology doing something which, to him, is significant.

Watch this video on the FrontlineSMS Community pages

In short, Lynman's solution works because it was his problem, not someone elses. And it worked because he solved it. And going by the video he's happy and proud, as he should be. Local ownership? You bet.  o/

Now, just imagine what a thousand Lynman's could achieve with a low cost laptop each, FrontlineSMS and a modest text messaging budget?

The "long tail" revisited

Four years ago was a very lonely time. Not for me personally, understand, but in the social mobile space. The wider non-profit world was just beginning to take a serious interest in what the technology had to offer, and in 2004 I'd just co-authored one of the earlier reports - funded by the Vodafone Group Foundation - on the use of mobile technology for conservation and development. To give some context, these were the days when it was widely believed that "poor people in developing countries" would never be able to afford a phone, and the days when concrete case studies on the application of mobile technology for positive social and environmental change were few and far between. Most evidence was anecdotal. A revised report would look very different today, but with one exception - many of the conclusions would likely still stand. If that's the case, how far have we really come?

Four years ago this week I came up with the concept of a laptop-based group messaging hub. The software I ended up developing is better known today as FrontlineSMS ("ProjectSMS" was the working title for the first few months). When I eventually got the resources together to write the first version in the summer of 2005, there was zero chance of reinventing any wheels. The "social mobile applications" shop was quite literally bare. After extensive research for a project I had been working on with South Africa National Parks (SANParks), there were simply no appropriate technology mobile solutions they could easily pick up and run with. The situation seemed crazy, and I had a hunch that SANParks were not alone in their need for an appropriate, portable, GSM-based communications tool. The rest is history, as they say.

Things are not quite so lonely today and 2008 - for me, at least - goes down as the year things really began to change. For what seemed like an age, FrontlineSMS was one of the few appropriate technology-based mobile tools aimed at - and openly and freely available to - the grassroots non-profit community. For a while it was the only one. It was also likely the first to be developed specifically with the NGO sector in mind - most other solutions were commercial offerings which found their way into the hands of NGOs, quite often the larger international variety with the funds, expertise and resources to use them. The frustration for me was that - until last year, at least - many of the emerging 'non-profit' mobile solutions seemed to be following that same model.

Enter "The Social Mobile Long Tail", my attempt at mapping out the social mobile applications space (you can read the original post, which explains the thinking in detail, here).

The basic rationale behind it was this. The majority of emerging mobile solutions, platforms or tools (call them what you will) were settling in the red area, and as such were technically and financially out-of-reach of many grassroots NGOs, many of whom sit in the green space. Tools at the higher end of the graph are generally more complex, server-based systems aimed a multinational NGOs or government departments. Tools in the lower end are simple, low-cost, appropriate and easily replicable solutions. My experiences working with NGOs in Africa over the past fifteen years has strongly influenced and steered the focus of my work towards the long tail, and I would have it no other way.

But let's just destroy a few myths for a minute. There are many out there. Here's my top three (feel free to add to these in the comments section below).

Firstly, wherever your tool sits on the graph, there is no right or wrong place for it. It's all about the context of the user. There is just as much a need for $1 million server-based, high bandwidth solutions as there are for free, SMS-only tools. In your typical scenario, national governments would likely go for the former, and grassroots NGOs for the latter, but not always. Both are valid, and tools shouldn't ever be described as "being better" than another because of it. This is a big mistake. We need there to be solutions all along the tail so that the users have a healthy applications ecosystem to dip into, whoever and wherever they may be. If you're trying to park a car into a small space, a Mini is much better than a Rolls Royce.

Secondly, let's not get all hooked up on scale. Just because a tool in the long tail might not run an international mobile campaign does not make it irrelevant. Just as a long tail solution might likely never run a higher-end project, expensive and technically complex solutions would likely fail to downscale enough to run a small communications network for farmers from a small NGO office with no mains electricity, for example.

Thirdly, we don't yet have any complete, polished mobile tools. I would argue that everything that we see in the social mobile applications ecosystem today is "work in progress", and it will likely stay that way for a very long time. Speaking with my FrontlineSMS hat on, I'd say we're probably only about 40% there with that solution right now. There is much to do, and the mobile technical landscape never stands still. Our challenge is how we all move with it, how we stay relevant, and how we all work together to share technical resources and know-how. A fragmented mobile landscape is a problem for all of us.

There have been many positive blog posts calling 2009 the "Year of Mobile". I think they could be right. I also think 2009 is going to be the "Year of the Searcher" (see my earlier blog post). As I argued back then, let's never forget it's the users of our tools who we answer to. Social change happens on the ground, often through them, and not online.

For the first time in four years things don't feel quite so lonely. I for one am hugely honoured to be working in a space alongside some of the most dedicated and talented people in the mobile and development fields, all of whom are trying to apply a range of practical solutions - all the way along the "social mobile long tail" - to some of the most pressing problems in the world today. We have a great opportunity in front of us if we stick together, remain focussed, and do not lose sight of the big picture.

After all, we don't want to be reading blog posts in twelve months time calling 2010 the "Year of Mobile", do we?

The Social Mobile Long Tail 2.0

A few months ago I finally got round to diagramming what I thought mobile applications development in the not-for-profit space looked like. I came up with this, and called it "Social Mobile's Long Tail". It was based on the original Long Tail concept, first talked about by Chris Anderson in a Wired Magazine article, when he used it to describe consumer demographics in business (something quite different).

(A larger image is available via the kiwanja.net site here)

My thinking was this. Looking at the mobile applications space today we have a number of high-cost, well-publicised, large-scale mobile-related projects which tend to cover national (and sometimes international) needs. These "large" systems play a crucial role in helping larger bodies, sometimes as big as government departments, provide mobile services to their target audiences. They are generally aimed at the higher-end of the market, where only the larger or resource-rich NGOs reside. Way out there on price, complex to develop (assuming you wanted to) and near-on impossible to replicate, they're almost completely out-of-reach of your average grassroots NGO. These applications and platforms sit in the red part of the Tail.

In the orange section we move into the more mid-range systems - solutions developed by individual NGOs for a specific need, campaign or project. These are generally less complex, which makes their chances of replicability slighter better, but still difficult for many grassroots non-profits with few technical resources or hardware at their disposal.

Finally, in the green section - the truly long part of the long tail - we have the low-end, simple, appropriate mobile technology solutions which are easy to obtain, require as little technical expertise as possible, and are easy to copy and replicate. From my own experiences the number of NGOs present in this space is by far the greatest, making it the area to focus on if we want to create the highest amount of mobile-enabled social change. Add up all the value here, and it easily outweighs the rest along the higher (more lucrative) parts of the tail.

I use this diagram in many of my conference talks and presentations, and it seems to go down very well. It was interesting to see some of the staff at Nokia Research, where I spoke last month while I was in Palo Alto, grabbing their camera phones to snap a picture of it. I'm always thinking about ways I can refine it though, and Jim Witkin - a colleague - suggested adding an extra axis. This is now the one on the right, representing the number of NGOs in each of the Long Tail segments.

There are probably better ways of depicting this, but for now I'm happy with this. Suggestions, however, are always welcome.