A (semi)clear position on laptops vs mobile phones (!)

Jon Camfield offers a clear statement on the perceived choice of mobile phones vs laptops as the "engines of development":

First, there are clear cases where one technology is better suited to a task than another. I'd no more write long papers on a cell phone than I would carry around a laptop to use as a personal communications device. However there's a large chunk of tasks where either tool will suffice, and which "should" be used is more a factor of the local conditions than the features of any one technology.

Secondly -- and more importantly -- this discussion is tool-centric. We have a hammer (two, in this case) and are going around the development landscape searching for nails we can drive home, and it's a race between the two hammers to see who can hit the most nails. This is inherently the wrong way to apply ICT in development.

We shouldn't be arguing about mobiles vs computers, or even OLPC XOs vs Intel ClassMates, or Windows vs Linux, we should be arguing about specific problems in development, what tools could help, how, and for what costs (training time, implementation and infrastucture gotchas, as well as equipment costs).

You can't really argue with this position, but of course I'll try: Sure, we need to pick tools that are appropriate to our objectives. BUT objectives themselves need to be  appropriate to their contexts. And the critical contexts, the most critical contexts, share certain characteristics. I can probably run a pilot project that helps a few kids in a really poor country -- I'll go with Chad and "MDG education" for US $0.50 -- use laptops to write longish reports and build both skills and knowledge in the course of their writing. If I want to have impact across a wide swath of schools and students, however, I'll be better advised to focus on an objective that emerges out of Chad's educational context, perhaps increasing primary-school completion and lower-secondary enrolment, and that takes advantage of available infrastructure and of tools that are in use and supported. 

You can walk this context/objective/tool-choice discussion back any number of ways. (For example, you could say that my objective, to have impact on education outcomes in a poor country, determines my characterization of context.) But IF we stay within the context of the "bottom billion" and the countries in which they live, I'll wager that we find out that laptops are rarely if ever the appropriate tool to achieve scaled impact in schools.

On the other hand, Sugar...

 I could have it all wrong, per this update from Ethiopia's OLPC experiment (courtesy of OLPCNews)...

Sugar: Would an OS by any other name taste as sweet...?

As you might know, the open-source Sugar operating system has been spun out of the OLPC (One Laptop Per Child) program and is now managed by a new non-profit, Sugarlabs. It's also been lightly re-branded as the Sugar Learning Platform, highlighting its inventive, learning-centered tools designed to help kids work effectively and work together. But can these affordances be effective in developing-country grade schools?


Sugar offers a unique combination of tools and features:

• Collaborative writing tools 
• Easy sharing of bookmarks and URLs
• USB portability between school, home and wherever
• Reasonable integration of writing tools and drawing tools
• Automatic recording and (theoretically) cataloguing of all work
• Graphical network topography displaying (who's who and where)

And now that it's de-coupled from the XO (Children's Machine XO, that is), and ported to Windows, Mac OS and many flavors of Linux, Sugar is as platform independent as you could wish.  eeepc, iBook, Classmate, Inspiron--Sugar works with all of them.

Sugar-the-idea is extremely cool: an OS designed for active, collaborative and (essentially) design-based learning. Kids grab Sugar and start to find things, make things, and share things. I can easily imagine Sugar becoming the OS of choice for primary and possibly middle-school 1:1 laptop programs in Maine, Washington, Edinburgh and Melbourne--any place, really, where teachers and primary-grade kids are already exploring the Internet as a learning resource, and collaboration as a learning method.

It's not so clear that Sugar will fulfill the original OLPC aspirations for primary-school change in developing countries.

In OECD countries primary school can be pedagogically posh: Kids can learn in a variety of ways, one teacher teaches nearly everything and knows the 20 to 30 kids in class pretty well, the subjects can be all mashed up interdisciplinarily, and, in the US, historically there have been few tests that really determine a student's educational future.*

In poor countries, even in well-off enclaves, primary learning is more constrained: Parents might struggle to pay school fees, buy uniforms, let the kid skip work; teachers confront (sometimes literally) classes of 50 or 60 kids (or more), and at the end of each term the kids face tests that determine whether they advance to the next grade and, ultimately, whether they matriculate to the next level. 

OLPC + Sugar was originally conceived as a resource that would transform primary learning in poor countries. But the nut is just too big to push up the hill: No tool in and of itself is going to pry apart the educational, bureaucratic and community cultures that come together to determine what happens in schools. Teacher training, learning resources and changes to assessment--not to mention increases in teacher professionalism (e.g., $)--all have more bearing on what happens. And, more importantly, none of these more necessary factors are sufficient in and of themselves to catalyze change. 

So, what are we going to see? It's possible, and perhaps probable, that we'll see Sugar adoptions taking place all over the world in schools that serve elites--whether in private schools in Bangalore or public schools in Portland--while the impact of Sugar on its originally intended demographic remains slight. 

If Sugar has become a "learning platform" to change teaching and learning in poor countries, SugarLabs needs to  partner-up with strong, committed advocates for comprehensive systemic change in developing-country school systems.

* I'm not suggesting that kids in your town aren't having crappy experiences of fourth grade. Poverty and educational success in the US are tightly linked,as they are in most places. I'm also not suggesting that primary education in the US isn't becoming more test driven: NCLB has introduced regular but not instructionally informative testing; lower-stakes tests such as the MAP suite [Measures of Academic Progress] have been developed to help schools conduct formative assessments and build student skills [and prepare for NCLB].

Specialized hardware vs SMS, you be the judge

The Neurosynatpic ReMeDi MDAU (Multi-parameter Data Acquisition Unit) telemedicine tool assesses critical diagnostic services measurements and prepares them for transmission back to a clinic or hospital. The diagnoses provided are:

• Electro-Cardiogram (ECG) 
• Blood pressure 
• Oximeter (your blood's oxygen saturation level) 
• Auscultation (what a stethoscope tells you) 
• Temperature
• Heart rate

ReMeDi, the basic version, is designed for use, at least theoretically, in village kiosks such as those provided by nLogue. Cost is about US $250. ReMeDi, plugged into an n-Logue computer or someone else's hardware, is probeware.

By delivering diagnostic services in villages that don't have doctors, ReMeDi at least potentially saves villagers the costs and lost opportunities of traveling to towns or cities when they need to see doctors. (And if you're making the benchmark, $2 per day, you would: a) like to work as many days as possible; b) prefer not spending money when you don't need to.) So ReMeDi has some potential to improve morbidity rates (e.g., general health-related suffering) and cut end-user healthcare costs. ReMeDi also has the potential to increase revenues among early-adopter physicians and, of equal importance, deliver a bit of a revenue stream to the n-Logue. (Prof. Ashok JhunJhunwala, god-father of n-Logue, is also among the guiding lights of NeuroSynaptic.) 

Now, I tend to argue that there's room for all kinds of solutions in the big tent of technology-for-development. (I mean, technology covers a lot, from pencils I suppose to robotic arms.) But in keeping with a flurry of information about telemedicine, it's interesting to compare the NeuroSynaptic approach to the effective use of SMS (Short Messaging Service) by healthcare-related NGOs in Africa, India and elsewhere.

SMS supports cheap one-way and two-way communication among healthcare providers and patients. It's been used to build HIV/AIDS awareness, (Text to Change, Uganda), 
support and track drug-regimen compliance (the SIMpill medical adherence system is one among many), as well as to support diagnostic-and-treatment programs. 

ReMeDi is low-cost, but the ability of Neurosynaptic to continue to offer the product requires 10s of 1,000s of kiosk operators and other providers of rural Internet access to offer the product and service and, critically, make money by doing so. (it's a bit hard for me to grasp the means by which kiosk operators connect to providers of diagnoses and medicines.) ReMeDi is state of the art, but it's only as effective as the training that the kiosk operator receives and his (her) ability to market the ReMeDi service. (In the pilot test supported by IDRC, an initial stream of users shrank to a trickle, possibly because the kiosk operators failed to operate the ReMeDi device effectively.)

ReMeDi, in its state-of-the-art-ness and its robustness, creates challenges in relation to training, asymmetrical partnership-building, and supply chain. (If the patient has to travel to get the prescription, her initial savings in avoiding a doctor visit are lost.)

SMS creates challenges based on the simplicity of the communication medium. Short text, no media. There's a bit of work involved in establishing broad- or narrow-cast message dissemination (although organizations like Frontline SMS are striving to reduce the work involved).

Most critically, ReMeDi requires several layers of inter-mediation, most noticeably by Neurosynaptic, by the kiosk-operating organization (n-Logue) and by the all-too-critical-and-all-too-unlikely-to-be-effective kiosk operator at the village level. 

Again, it's not that these variant approaches exclude each other. But if I had a few dollars to support a scalable, sustainable, effective tool for reducing morbidity and/or mortality rates across a rural region, I would see what I could make happen with SMS and leave the more complex solutions for another player. 

If I were prescription-drug manufacturer Rambaxi, however, I might look into ReMeDi as _part_ of a solution that included druggist-to-villager delivery of my products. That is, if someone else would fund hardware and connection for Internet access. 

Jane Hirshfield sez...

Well, to find out, check her poem,
"French horn," in the Feb 9 New Yorker....