Audio & Video: Mobile at the Margins

This page contains a selection of kiwanja.net conference talks, news items and radio interviews. A wider selection of kiwanja and non-kiwanja videos – covering technology, anthropology, innovation, entrepreneurship and development – can be found in the Video category of the “Build it Kenny, and they will come…” blog.

Talk

Mobile at the Margins

10:04 · May 2009

This video is from the “Computing at the Margins” conference at Georgia Tech in May 2009, where Ken Banks gave a ten-minute talk on “tools that travel”. He talks about the need, and the criteria, for building and designing mobile tools for grassroots NGOs in the developing world.

Details

Read the transcript

Okay, good morning. It’s great to be here. Ten minutes is not a lot of time, as most people have found out so far, so I’m going to whiz through this really quickly. This is basically a whole bunch of thoughts from the work I’ve done over the last 15 or 16 years, and the last six years in mobile. It will be quick.

I’m thinking about tools that travel, not necessarily people that travel: how you build tools that will move into different environments and work in different environments. My background, very quickly: 25 years or so in IT, the last 15 or 16 years doing a lot of work in about nine or ten African countries. My degree is in social anthropology, and since 2003 I’ve been working specifically to try and figure out how you get mobile technology to work in places like this. You have NGOs serving underserved communities, working in pretty harsh places, and a lot of the technologies that were coming out, or that I was seeing, just wouldn’t work in those places. So I’ve put in the best picture I could find that I’ve taken of what it might look like for them to be on the margins.

The first bit of work I did, originally in 2003–2004, was with Kruger National Park. They were seeing increasing numbers of cell phones appearing in the hands of these people. These women live in a community on the edge of the national park, and they’re largely excluded from the conservation process, or from benefiting in any way from it. They were thinking: how do we re-engage them after 80 or 90 years of never speaking to them, and how do you do it through cell phones? I was tasked to try and find something they could use in that kind of environment, and we couldn’t find anything that really worked, for a whole bunch of reasons. It got me thinking, and I’ll explain in a couple of minutes why I think the tools we found didn’t work.

Generally, for me, a lot of it comes down to this centralised versus decentralised argument. Everyone’s excited about the cloud and connecting to things, but connecting to things in those kinds of environments is pretty tough. Generally speaking, SMS will get you there, if there’s a mobile signal. If you go beyond that, you exclude so many people that you have to start wondering why you’re doing what you’re doing. We have this traditional way of thinking about how we connect people. We have the internet in the middle (I apologise for using the Microsoft logo there), and then we have all the communities, and we think about how we connect them to that, how we share information at a central point and give them access to it. We don’t always think about what it is they might want to access. That’s a different argument altogether, but that’s the model we follow. For me, there’s a lot of content within the communities that actually needs to be shared. We don’t always think of communities as content generators; we just think they need to suck up information. How do we allow communities to share the information they possess with other members of their community and nearby communities? If you do that, you don’t need to connect to the middle. Ideally, perhaps, you could argue that you do, but there’s plenty you can do if you just connect people within those little sections.

A quick story about elephants. One of the projects I’ve worked on has been trying to give early warning of elephants encroaching on villages. When I was walking around meeting villagers, they were thinking: why are the national parks trying to find a way of giving information to us about elephants arriving? We’re usually the first to know; we’re out in our fields and we see the elephants. The national park authorities are in Nairobi or Johannesburg, so why don’t we have the tools to spread that information among ourselves? Again, it got me thinking about how we were going about trying to solve some of these problems.

Most of the NGOs I’ve worked with, and most of the NGOs who come to me and I try to help, generally fall into these sorts of categories: they’re small, very dedicated, highly efficient with their money. I’ve seen education centres in Nigeria built with just $200, and I see fundraising attempts trying to raise tens of thousands to do similar things, and I wonder how many storeys that building is going to have, whether it’ll have underground parking and all sorts of crazy stuff. You can do really, really good things with small amounts of money, and grassroots NGOs seem to be able to figure out how to do that.

When thinking about how we build tools that they can use in those environments, there are a few things they need to meet. First of all, they have to work on readily available hardware. They can’t go shopping for a top-of-the-range server, and they can’t necessarily go shopping for an iPhone, if you’re thinking really on the margins. They need to be quick to put together; they don’t want to spend hours and days and weeks figuring out how this thing plugs in and does stuff. They need to be cheap, or free, ideally free. They need to be replicable as well: how does one NGO tell another NGO what they’re doing, and how does that NGO then very quickly adopt that technology? If it’s not replicable, we’re kind of getting ourselves stuck in a bit of a hole. We need to think about going beyond building one solution for one organisation in one country, and think about how it can be spread to other organisations doing similar work. Also, forget the internet, in my view. If it needs to connect to the internet, then I don’t generally do it. We do stuff that will use the internet if it’s available, but it’s not a showstopper. And finally, when they can get on the internet, how do they connect up and join communities with other users, to figure out what other people are doing? That gets them a little bit away from being on the margins and takes them slightly more central, where they can read about other things and try to engage with other people doing similar work.

But today I’m not actually out there, I’m here, and I wanted to very quickly go through a few things that I’ve found over the last couple of years in particular. There are huge numbers of people trying to build tools and solutions for developing countries, and not all of them are in institutions like Georgia Tech or MIT. There are a lot of people out there, hobbyists and people who are just very interested in solving problems that they see, and often they fall into traps. When I came here I thought I’d just talk about this: some software I developed which actually works in places like the communities around Kruger National Park. It’s just an SMS messaging hub which allows you to do group two-way messaging through the mobile phone signal, and it doesn’t require the internet. I decided, though, that thinking about the community here and what we’re talking about, I’d be better off talking about some of the things I often talk to people about.

I’m amazed, and continue to be amazed, how many people try to fix a problem they’ve got no understanding of. I think Aaron mentioned it this morning, and it still happens: why is some white guy in Massachusetts trying to solve a problem in a rural village he’s never been to and never spoken to anybody there? It’s great, good intentions, but I think we need to really think about that. Also, be flexible. Don’t try to make it all perfect before you do something with it. Be flexible so that, in changing environments, you can adapt what you’re looking to do. Again, think about building things which are easy to use and don’t require training. Users can’t fly off to the capital city for a week to get training; they really need to be able to figure it out for themselves. And the act of discovery also buys you local engagement and empowerment. If a user figures something out, if it’s not too hard, they feel amazingly empowered. Certainly with the software I’ve developed, many users start to do things with it that they never imagined, and the engagement, the empowerment and the buy-in are already there. So let’s not put everything on a plate. Let’s give the users a little bit of work to do, but not too much.

Think about rapid prototyping. If you do a rapid prototype of something and you throw it out and nobody’s interested, that’s a message: don’t do any more. Why are you bothering? So do it early, iterate, throw it out, see what happens, and then evolve around the response you get from people. And be patient as well; things don’t happen overnight. Don’t be too controlling. In the work I do, I give a tool away and I step back, and I have very little to do with anything beyond that point. It’s a little bit scary, because you lose total contact with people and you lose a sense of what it’s doing half the time, but if you try to control it you’re almost strangling it at birth. And the last one: just ensure that it works on readily available hardware, as I’ve mentioned, and make sure that people can get the bits they need relatively easily to make what you’re building work. I think that’s really important. These are all in a blog post, by the way. There are about 22 of them, and I’m happy to give you the link a bit later.

A final section: some of the myths that really bug me. I’ve blogged about this as well. “Scale” is one of the most misused words, I think, in ICT4D. It means so many things to so many people; it’s almost like the phrase “appropriate technology”, where no one really knows what it means but it sounds good. I think we need to think about scale in different ways: think about scaling things horizontally, not taking something which runs quite nicely in a small environment and sticking it on a big fat server, because that changes the DNA of the solution completely, and what you originally had can be destroyed and lost. “Big is beautiful”: again, I think it’s not [unclear]. I see no problem in having 10,000 small health hubs running services for local people, which may or may not be connected. I’d rather see that than some very big, fat thing sitting at the Ministry of Health where there’s no local engagement and ownership.

And then finally, the old argument that appropriate technologies are poor people’s technologies. I studied appropriate technology at university and got very interested in it, and I carry a lot of the themes through in my work today. I think you still see this: “Why are you giving them this low-end stuff? Why are you giving them netbooks and OLPCs? Why don’t you give them the really cool things?” Those are some of the little snapshots of the things I’ve learned and try to share with people who contact me who are trying to develop things in this space.

And just finally: when we go to bed at night, I think we need to ask ourselves, have I really advanced anything today which gets us any closer to helping people like this? Am I doing something of value? Am I doing it for me, or am I doing it for them? I constantly challenge myself to think: in the work that I do, are we getting closer to producing tools which can travel in these marginal areas and serve communities on the edges of parks like Kruger National Park? So that was ten minutes, I think. Thank you.

Transcript edited from YouTube’s auto-generated captions for accuracy.

← Back to all audio and video