What if Apple worked in ICT4D? Reflections on the possible

“Two weeks ago, I was staying at a working dairy farm sixty kilometers north of Bogotá, Colombia. I was fiddling around with my iPad when one of the kids that worked in the stables came up to me and started staring at it. He couldn’t have been more than six years old, and I’d bet dollars to donuts that he had never used a computer or even a cellular telephone before (Colombia has many attractions. The vast pool of illiterate poor is not one of them)

Curious, I handed him the device and a very small miracle happened. He started using it. I mean, really using it. Almost instantly, he was sliding around, opening and closing applications, playing a pinball game I had downloaded. All without a single word of instruction from me”

Michael Noer, “The Stable Boy and the iPad

Two questions scream out at me when I read this. Firstly, what would happen if Apple turned a fraction of its attention to ICT4D? And secondly, why don’t Apple work in ICT4D? In a sector where so many tools and solutions seem to fail because they’re too complex, poorly designed, unusable or inappropriate, who better to show us how it should be done than the masters of usability and design?

The answer to the second question is a little easier to answer than the first. As Walter Isaacson pointed out in his recent biography, Steve Jobs felt he could contribute more to the world by ‘simply’ making brilliant products. He seemed to have little time for philanthropy, at least publicly, and his laser focus meant he saw almost everything other than Apple’s mission as a distraction. Ironically, had he decided to give away some of his ballooning wealth, he’d most likely have funded programmes working in nutrition and vegetarianism, not technology, according to Mark Vermilion (who Steve Jobs hired back in 1986 to run the Steven P. Jobs Foundation, which he was destined to shut down a year later).

Had Steve Jobs decided to pursue his Foundation, and had he decided to fund technology-based initiatives in the developing world, how well might he have done, and what might Apple have been able to contribute to our discipline?

Here’s five initial thoughts on where an Apple approach to ICT4D might be different – or problematic.

1. Consult the user

One of the central tenets of ICT4D is to consult the user before designing or building anything. In business, at least, Apple don’t do this. They certainly didn’t speak to Colombian farm children, yet they managed to intuitively build something that worked for the six year old Michael Noer met. As Steve Jobs famously said:

Our job is to figure out what users are going to want before they do. People don’t know what they want until you show it to them. That’s why I never rely on market research. Our task is to read things that are not yet on the page

An Apple ICT4D project would unlikely spend much time, if any, speaking with the target audience, an approach entirely at odds with the one we champion right now.

2. Customer vs. beneficiary

Apple would see people as customers, and they’d be carrying out what they’d see as a commercial transaction with them. This approach would mean they’d have to build something the customer wanted, and that worked (and worked well). Since it would have to sell, if successful it would by default be financially sustainable. Part of the problem with the largely subsidised ICT4D “give away technology” model is that no-one is ultimately accountable if things don’t work out, and regular business rules do not apply.

3. Open vs. closed

The ICT4D community is entrenched in an open source mindset, almost to the extent that closed solutions are scorned upon. Steve Jobs was a strong believer in controlling all aspects of the user experience, all the way from hardware through to software. To him, closed systems were better “integrated” and open systems “fragmented”:

What is best for the customer – integrated versus fragmented? We think this is a huge strength of our system versus Google’s. When selling to people who want their devices to just work, we think integrated wins every time. We are committed to the integrated approach. We are confident it will triumph over Google’s fragmented approach

There is no evidence in ICT4D, I don’t believe, which points towards more success for open solutions vs. closed (however you define success), yet open remains dominant. An early Apple success might give us pause for thought.

4. Time for the field

Although Paul Polak doesn’t work in ICT4D, he is one the biggest proponents of “getting out into the field to understand the needs of your customer”. In his long career he’s interviewed over 3,000 people earning a dollar or less a day to better understand their needs – and the market opportunity. In this short video he talks about the process of spending time in rural villages, talking in depth with villagers, and identifying opportunities for transformative impact.

Apple wouldn’t see the need to do this because they wouldn’t consider the needs of dollar-a-day customers as being any different to anyone else. They’d consider their intuitive design and user interface to be non-culturally specific. People, everywhere, want simple-to-use technologies that just work, regardless of who they are.

5. Appropriate technology

Apple’s product line hardly fits into the appropriate technology model – they’re expensive, power-hungry and the devices are reliant on a computer (via iTunes) as their central controlling “hub”. The systems are also closed, blocking any chance of local innovation around the platform. How Apple tackle this – yet maintain their standards of excellence in design and usability – would probably turn out to be their biggest challenge.

Although it hasn’t happened yet, a post-Steve Jobs Apple might yet develop a philanthropic streak. If they did they could easily turn to their friends at frog design (now branded Frog) for help. Frog, who worked closely with them in the early days of the Macintosh range, have recently worked with a number of ICT4D initiatives and organisations, including Project Masiluleke and UNICEF.

Apple have already reinvented the music and publishing industries. With the talent, capital and resources available I’d bet my bottom dollar on them reinventing ICT4D if they chose to. Steve Jobs liked to “live at the intersection of the humanities and technology”, and that’s exactly the place where ICT4D needs to be.

Building mobile applications for social good

“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.

Putting data integrity on the map

We were excited to join colleagues and friends in Washington, DC, on Tuesday 9th August to release the first edition of our “User Guide on Data Integrity”, a tool that will help FrontlineSMS users around the world better understand the flow of information into and out of the platform, the risks and vulnerabilities to that data, and simple ways they can mitigate those risks.

Review by Cathryn Paine reposted from the FrontlineSMS blog

To kick off the discussion around the new guide, we hosted a panel discussion at Johns Hopkins’ School of Advanced International Studies, where FrontlineSMS’ Sean McDonald joined Jon Gosier of metaLayer, Development Seed’s Paul Goodman, and Internews Vice President for New Media Kathleen Reen, who moderated the event. This research effort, based on FrontlineSMS user input and research by Kristina Lugo and Carol Waters, focused not on mobile system security, a critical issue better addressed by others, but more on the ways that contextualized program design and implementation can improve data quality and reduce user risk. Above all, we learned through the process, context is key. Understanding the needs and norms of the target population, and the goals of the project itself, is vital in determining the proper tools and approach to designing a FrontlineSMS workflow that can achieve those goals.

The panel discussion centered on these key points, especially the role that stakeholders play in the reliability and integrity of project data. Issues from misinterpretation, to unconscious bias, to lack of corroboration can creep into an improperly designed data collection effort, polluting the entire dataset in the process. To mitigate these threats, Jon emphasized focusing on localization and usability in project design—understanding the users or beneficiaries of a project is the best way to minimize human error and maximize data integrity.

Paul Goodman during a project planning session, sketching out project workflow which includes FrontlineSMS use. Photo credit: Paul Goodman

Paul contextualized these points with insights from mobile projects in Haiti and Benin, focusing on the process of implementing new technologies—from design to training to implementation. Particularly, the panel discussion focused on assuming that program data would be made public, in an effort to design projects that achieve important goals while minimizing risks associated with data sharing or system compromise.

Throughout the conversation, the discussion kept coming back to the importance of user-focused, context-aware approaches and resources in ICT projects. No matter how complicated the technology, an informed and engaged community of project staff and participants is really the best tool for safeguarding quality data. All in all, a great discussion that we hope to keep going through the forum and ongoing interactions!

You can download a PDF of the FrontlineSMS User Guide on Data Integrity here.

Taking the social mobile “taste test”

“After all is said and done, a lot more will be said than done” –
Unknown author

Twitter has been abuzz lately with fascinating snippets of advice on how to succeed, how not to fail, what makes a good social venture, what makes a good mobile project or how to be a successful social entrepreneur. Of course, it’s easy to say these things, and even easier to repeat mantras and slogans which fit a popular or emerging philosophy. Who could argue, for example, that “users should be put first”?

Sadly, when all is said and done, the reality is that it’s still much easier to ignore the advice and go do your own thing your own way, rather than doing things the right way.

The best way to get a sense of the true philosophy – the DNA – of a project is to see if it passes a “taste test”. This is particularly true in mobile, where almost all initiatives claim to have engaged or active communities, or to empower, to put users first, or to have been ‘born’ in the field. The question is: Does the rhetoric actually match the reality? In an age where more and more projects are coming under increasing scrutiny, ensuring they are properly positioned is crucial.

It’s quite easy to determine whether or not a tool is going to be of any use to an end user (an NGO in this case), or whether you’d need a medium to high degree of technical literacy to make use of it (in which case you might argue that the tool was more developer-focused). For some time I’ve used the concept of the “social mobile long tail” to graphically represent this.

In short, 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.

So, how might we determine where a tool should be placed on the “social mobile long tail”? There are likely many measures and metrics, but I’d say these are a few of the more obvious ones the user would be principally concerned with:

  • Does the project have a user-facing, NGO-friendly website?
  • How technical is the language on the site?
  • Is there an easily accessible, open, visible user community?
  • How easy is the software to find, download and install?
  • Will it work on widely available hardware and software in the places where it will be used?
  • Can the user independently deploy the tool if they want to?

For some time I’ve wondered whether it would be worth scoping out the mobile landscape and plot available tools along the tail. Not only would it satisfy my general curiosity, but it could be immensely valuable to an NGO community which still largely struggles to understand the mobile technologies they believe – and hope – they should be using.