the challenges of technology research for … challenges of technology research for developing...

1536-1268/06/$20.00 © 2006 IEEE ■ Published by the IEEE CS and IEEE ComSoc PERVASIVEcomputing 15

E M E R G I N G E C O N O M I E S

The Challenges ofTechnology Researchfor Developing Regions

The work we’ve done in the world’sdeveloping regions1 has been im-mensely rewarding and helped makeus all strong advocates for technol-ogy. The first reward is simply the

experience of these countries, their surprisinghappiness, and the technology insights that comefrom being there. The deeper reward is of course

actually helping people by cre-ating new options through tech-nology. For example, a video-conferencing solution on top ofour novel low-cost long-distancenetworking has directly led toimproved eye care for about 30patients a day in our test site in

rural India. Although we’ve worked in eightcountries, most of our examples come from fourprojects:

• In the telemedicine project just mentioned, withthe Aravind Eye Hospital in Tamil Nadu, India,our goal is to diagnose patients that are too farfrom the hospital to visit in person (www.aravind.org).

• In the village kiosks of the M.S. SwaminathanResearch Foundation (MSSRF), also in south-ern India, our goal is to use speech recognitionfor semiliterate villagers (www.mssrf.org).

• In a rural networking project in Ghana, we’relooking at low-cost wireless backhauling of IPtraffic (that is, carrying aggregate Internet traf-fic for a group, such as an ISP).

• In an Asia Foundation project in rural Cam-

bodia, we’re focusing on improved email andcontent distribution applications over verypoor networks (www.asiafoundation.org).

However, we encountered a wide range of tech-nical, environmental, and cultural challenges thatare outside the scope of typical computer scienceresearch.

In this article, we share some of our experienceswith the hope of increasing understanding of theseissues. We also hope to help others, particularlyresearchers from outside these regions, to avoidour mistakes. We document real challenges (mostlyour own), try to generalize them, and suggest stepsthat might at least mitigate the problems.

Technical challengesAlthough the specific technology issues we

encounter differ somewhat from one developingregion to another, they are in many ways easier tosolve (than environmental or cultural challenges).Our problems ranged from equipment and powerfailures to software and remote management.

Equipment failuresOne of the first lessons we learned is simply

that typical equipment specifications aren’t real-istic for developing regions. The most obviousissue is humidity, which can often lead to con-densation inside the equipment, eventually short-ing the circuitry. For pole-mounted routers, wedesigned a box with a slanted top, so that con-densation flows down the slant and around theboard rather than dripping on it.

Our projects in several developing regions ran into many technical,cultural, and environmental challenges. We hope to help others,especially researchers from outside these regions, avoid our mistakes.

Eric Brewer, Michael Demmer,Melissa Ho, R.J. Honicky, Joyojeet Pal, Madelaine Plauché,and Sonesh SuranaUniversity of California, Berkeley

Heat is the next obvious problem. Indeveloping regions, equipment mustoperate in a wide range of temperaturesbecause of the lack of widespread cli-mate control. Although cooling therooms containing computers is some-times possible, doing so is expensive andrequires power, and cooling systems areunlikely to be handled by a UPS (unin-terruptible power source).

Dirt and dust are also an issue (see fig-ure 1). In Pailin, Cambodia, we foundthat the staff of a rural center had toclean the inside of computers once aweek using an electric blower. Theamount of dust accumulated was incred-ible, owing to the center’s location in anopen-fronted office on a relatively busydirt street. Without this intervention, themachines would become unreliable andstop functioning over time.

All of our outdoor equipment neededto be especially robust to water andultraviolet exposure. In one example, weinstalled a makeshift plastic enclosure inPondicherry, India, as a temporary mea-sure, but exposure to the elements ren-dered the plastic so brittle that the equip-ment was ruined in less than six months.UV protection in particular is both crit-ical and hard to get; for example, we had

trouble finding UV-rated CAT5 cable inseveral countries.

In general, we lose equipment on everytrip. Although power tends to be thebiggest short-term cause, equipment alsobreaks because of bumpy roads. Onesystem stopped working immediatelyafter a very bumpy auto rickshaw (three-wheel mini taxi) ride over an 11-kilo-meter dirt road. We can’t be sure that theride was at fault, but one of our laptopsalso stopped working on that ride.

Power problemsThe obvious problem with power is

outages, both long and short, and UPSbackup is the usual solution. However,the power in some centers in India andCambodia was so intermittent that theUPS would frequently turn on and off,ultimately reducing battery life. So, in atleast one case, when the power finally didgo out for a longer period of time (morethan a few seconds or minutes), the UPSbattery was already dead. For the wire-less backhaul project in Ghana, we deter-mined that battery backup for the gridpower had to last for at least three days,implying a relatively expensive batterysystem. For these types of networks,power is the second most expensive ele-

ment, after the cost of the towers (if thereare any). These costs are compoundedfurther in multihop networks.

Even when the power is on, the qual-ity is often insufficient for IT, which ismore demanding than the typical usagefor lighting and cooking. Using a powerlogger, we observed spikes of up to 1,000volts on a 220-V grid, as well as long peri-ods of 170 V (brownouts). Anecdotally,AC adapters such as those for cell phonesend up having very short lives, occasion-ally even less than six months. Many UPSsystems only help a little, as they passthrough the grid power and its problems,switching to battery mode only when thepower is completely out.

On the positive side, laptops havesomewhat fewer problems because oftheir integrated batteries, and the moreexpensive UPSs tend to work somewhatbetter. Finally, most middle-class homesand all data centers use gas or diesel gen-erators for backup power, so this is anoption, albeit an expensive one.

Intentional power outages also causedproblems. In one Tamil Nadu center, ourproxy cache was in an error state everymorning, requiring a manual reboot.After some investigation, we found thatthe operators shut off the entire center’spower each evening—a fairly commonpractice in many places. Yet it was stillnot obvious why the cache ended up ina hung state rather than rebootingcleanly, as we had specialized watchdoghardware that should have automati-cally rebooted the system. The real prob-lem was that a single master switchturned on the whole center at once, lead-ing to high current demand and a sub-sequent voltage drop. Booting this par-ticular hardware board with insufficientvoltage caused it to hang withoutenabling the hardware watchdog. Ourcurrent solution is still to reboot manu-ally every morning, but a simple time-delay circuit to offset the boot timeswould be a nicer solution.

16 PERVASIVEcomputing www.computer.org/pervasive


Figure 1. A dusty UPS system in Cambodia.

Software infection and reinstallationMany of the Windows PCs used at

Aravind and MSSRF were poorly main-tained and infected with spyware andviruses. This meant that several appli-cations, including the new ones we triedto install, didn’t work properly. Simi-larly, general Internet access in Cambo-dian centers meant that viral infectionwas basically inevitable, since no oneuses firewalls or antivirus software andmost users do not understand viruses orspyware. As we later found out, thestandard procedure for dealing withthese computers’ problems is to fullyreinstall and reconfigure Windows. Thisis due in part to a lack of technicalknow-how to implement more targetedsolutions, but in many cases it’s the onlysafe solution.

In some cases, the impact on our pro-ject came down to this: the monitoringsoftware we had installed was erasedwithin a week of our departure becausewe had failed to leave sufficient rein-stallation instructions. In the case ofAravind, unlike in Cambodia, we leftreinstallation CDs at each site, whichseemed to help significantly—at least oursoftware got reinstalled along with therest of the system.

However, we also had to configure thePCs for specific network settings and rout-ing-table entries. Such site-specific settingsget lost during reinstalls, so they must bereconfigured. One lesson here is that weshould treat the OS installation as soft-state, by which we mean it’s temporary,unreliable, and easily restored to a safe ver-sion. In turn, this implies we must gatherany data and complex configuration ontoseparate storage systems, such as a localserver or USB key. Also, we did not havereinstallation issues with Linux systemsbecause they generally were left alone andtended not to get infected.

Remote managementRemote management seems like an

ideal solution to aid research in distantplaces. Local contacts are often untrainedto diagnose or support problems, and it’sclearly not time- or cost-effective torepeatedly fly graduate students toremote locations. Unfortunately, remotemanagement has been extremely diffi-cult to achieve in practice.

Given a good connection, we cansecurely log in to remote machines via theSecure Shell protocol (SSH) and manageor upgrade them. Most of the trouble is

how to ensure a good connection. Net-work Address Translation and firewallsbar incoming connections, and for satel-lite or dialup-based connectivity, the linkis simply down until an outgoing con-nection initiates connectivity.

The basic solution is to have theremote device “phone home”: we initi-ate connectivity from the remote sideand then use the opened connection andSSH to log back into the device. How-ever, this approach often works for awhile and then stops. Problems we’vefound include a lack of power at thescheduled time, hung nodes (despite awatchdog), and loss of the capabilitybecause of misconfiguration or refor-matting of the entire machine.

Once “phone home” stops working,we tend to be in trouble, as our machinesare on the far side of the planet with-out network access. We’re considering“sneaker net” style solutions such as USBkeys or CDs that we can ship to remotesites to auto-install a patch, but this isn’teasy, especially when we have limitedinformation about the actual problem.

Finally, beyond simply enabling con-

nectivity to our machines, we mustdesign systems that can revert back to asafe state, including correct local con-figuration settings. A smarter variationof a safe-mode boot or a custom rein-stallation CD with all known (good) set-tings for a specific host might suffice.

Environmental challengesLogistical problems include trans-

portation, customs and shipping, andlocal production. There are also height-

ened risks of personal safety in urbanslums and natural disasters.

TransportationTravel time often hinders research,

especially in rural areas. Kwaku Boadu,a wireless-network CEO in Ghana, saidthat travel costs are a significant part ofoperating expenses and limit a com-pany’s reach. Average speeds of 20 kmper hour are common, and we’ve hadmany all-day or all-night trips.

Worse, each trip to a remote locationhas a nontrivial risk associated with it.To minimize risk to his engineers, Boaduavoids hiring professional drivers, real-izing that they’ll feel obligated to driveeven when severely tired. Similarly,while working in Tamil Nadu, India,two of us narrowly avoided a seriousaccident when our van’s driver had aseizure. Luckily, he was able to stop thevan (somewhat roughly) before black-ing out and convulsing. The driver hadno known history of seizures, so thebest explanation we could find was thathe (a poor man) had eaten spoiled foodthe previous day and nothing else the

APRIL–JUNE 2006 PERVASIVEcomputing 17

Once “phone home” stops working,

we tend to be in trouble, as our machines

are on the far side of the planet

without network access.

following morning. Although ill, heapparently felt that he could not affordto miss work.

Weather and other unpredictable fac-tors often exacerbate transportation prob-lems. In Cambodia, we had to cancel atrip to a remote, rural information centerin Preah Vihear because of an impassableroad (see figure 2). We had assumed theroad was still good because our driver hadtraveled it just a few months earlier—butheavy rains intervened.

Transportation problems thus increasethe need for reliable equipment andremote management, both for cost andsafety reasons.

Customs and shippingWhenever possible, we bring all needed

equipment with us or arrange to buy itlocally, but for various reasons, some-times we must ship it. However, ship-ments can be delayed while clearing cus-toms and afterward.

Officials who were confused by thelabeling of our wireless-equipment ship-ment incorrectly thought that it might vio-late spectrum usage policy. For 10 days,our equipment sat idle at the airport whilewe clarified the situation. We now try touse only simple, innocuous labeling andalso find that shipping to Intel Indiaworks better than to less-well-knownreceivers. To avoid delays while we’reworking in a developing region, we try toship our equipment a month in advance.

In India, we have to pay customs’ dutyof about 20 percent. Although importtaxes on computer equipment are gener-ally coming down, they remain high inmany countries. Clearly, these customsand tax issues imply that shipping isn’t agood long-term strategy, but it does sim-plify first-time deployments, after whichwe can invest in local procurement.

Local purchase and manufacturingIn the long term, we intend to trans-

fer the technologies that we develop tolocal firms. This helps with both cost andscalability as well as encouraging localeconomic growth.

With that in mind, we’ve begun toidentify local manufacturers and vendorswho can provide equipment and skills.For our backhaul link in Ghana, wehired a man who makes satellite dishesto build some high-gain Wi-Fi antennas.Although some of his tools are rudimen-tary by modern standards, he clearlyunderstands how to adjust a dish’s geom-etry to different sizes and what gain toexpect from a particular-sized dish at acertain frequency. Satisfied with his crafts-manship, we ordered two custom dishes,tailored to the 2.4 GHz band.

Building the dish was fast and suc-cessful, but when it came time to mountit, he couldn’t weld the mounting brack-ets because the power was out for sev-eral days. He purchased a generator, butit had insufficient power for the arc

welder. Worse, the next day, he camedown with malaria. Despite his illness,with our departure date quicklyapproaching, he drove the finished dishacross town to a place with power andwelded the mounting bracket for us. Onthe last working day of our visit, wehoisted the dish onto the mast and con-figured the network.

It was worth the wait. After some con-figuration tweaking, the dish yieldedapproximately 31 decibels (close to thetheoretical maximum of 33.4 dB for adish that size and shape), making a solidconnection supporting 7 Mbps on an802.11b link over 56 kilometers withvirtually zero packet loss at the link layer.We recently installed the second dish ona return trip. This example reflects allthe issues: strong local knowledge andcraftsmanship, limitations to productiv-ity, and unexpected delays.

Developing regions vary widely in thequality of local manufacturing, fromhigh-quality, low-cost items to poor-quality, (relatively) expensive items. Forour second trip to India, we knew thatEthernet crimpers, jacks, and cableswould be readily available in Chennai’shuge high-tech bazaar. However, we dis-covered that some crimpers and jackswere so badly manufactured as to bebasically unusable. For the RJ45 jacks,pushing the Ethernet wires into theirslots in the right order was almostimpossible. We are now more careful inmaking local purchases. Finally, localprocurement takes considerable timebecause of communication and trans-portation problems and the need to visitmany locations. Despite these issues,local purchases remain preferable toshipping equipment in from outside.

Urban dangerAlthough we’ve done most of our

work in rural areas, some was in theurban slums of India and Brazil. Espe-



Figure 2. This pickup truck was stuck on a bridge in Cambodia that heavy rainfallhad damaged.

cially in Brazil, we found that researchcould be a perilous task. Our work in Riode Janeiro’s slums, known as favelas,revolved around using refurbished com-puters in subsidized public kiosks. Basi-cally, no research can occur in the favelasif the local drug lords choose to prohibitit. Even entering or leaving a favela with-out a local escort is usually out of thequestion. In some favelas, hiring someoneto do the surveys was difficult because fewagencies have experience working in thepoorer neighborhoods. Getting a goodsample of computer users was difficultbecause door-to-door visits were too risky,so we had to make do with samplingrespondents at the favelas’ outskirts ratherthan in the labyrinthic interiors. In thetwo-week survey-taking period, we hadone incident in which a surveyor walkedinto a drug-related shootout.

Taking photos was very difficult, andthe “informal” authorities prohibited it.Pictures contribute to creating street maps,which are strategic during drug raids. Wewere repeatedly told that drug lords andlocal gangs monitor computer centeractivities. One center was always warnedin advance of shootings to help keep thecomputer students out of danger.

As an aside, some photos we took ofgraffiti in a Sao Paulo slum became a toolfor threats between gangs. After one ofus posted these pictures on a personalWeb site, they surfaced in Google queriesfor one of the gang’s names. We foundout later that Brazilians, probably gangmembers, had used the Web site’s com-ment features to send coded messagesand threats to each other. Somewhat sur-prisingly, the messages’ authors took thetrouble to mask their IP addresses.

Natural disastersOn one of our trips to India, we

arrived shortly after the December 2004Indian Ocean tsunami, which had nearlydestroyed two of the villages where wewere working. Despite advance arrange-

ments, when we arrived we were toldthat we couldn’t go to the villages—somany news crews had been in the areathat the villagers were resentful. Althoughwe used our time doing a combination ofrelief work and unplanned research, wewere completely unable to address ouroriginal research goals.

You might be tempted to ignore dis-asters as a research challenge, given thatthey’re rare. However, life is generallymore fragile, less prepared, and more

overcrowded in developing countries, allof which exacerbate crises. Just in thepast two years, we’ve seen the tsunami,a devastating earthquake in Pakistan,and incredible flooding in Bangladesh.Less damaging but more frequent arelocal crises, including broken dams,school fires, and monsoons. These eventsare systemic problems that, althoughunpredictable, will likely affect fieldwork at some point.

Cultural challengesCultural issues present the greatest

challenges, and they vary widely byregion. We’ve faced IT staff problems,tampering and theft, corruption, andilliteracy.

Staff and trainingOverall, developing regions have

severe shortages of IT personnel, whocan often make more money in othercountries or in their own country’swealthier cities (such as Bangalore).

When deploying our work into ourpartners’ infrastructures, we must workclosely with their IT support staff. How-

ever, these staff members are typicallyoverburdened. At the Theni AravindHospital, the network administrator wasalso responsible for data entry of patientrecords, statistics for all patients visitingthe clinics and the eye camps, and weeklyreports. He was hard-pressed to find timeto maintain the existing network, letalone to help us install new technologies.

We’ve also worked with staff peoplewho were relatively inexperienced orlacked confidence. The hospital’s tech-

nical staff could do basic Windows con-figuration, but they couldn’t help withmore complex tasks such as modifyingroutes on their main gateway. Further-more, lack of Linux knowledge meantthat the staff was essentially unable tofollow even detailed instructions aboutSSH, routing tables, and software instal-lation. Similarly, after we set up the net-work, a staff person would occasionallycontact us to say that the link “wasn’tworking.” However, in many cases theroot cause was something simple, suchas a loose Ethernet cable or a mistypedping command.

Many organizations also face high ITstaff turnover—as the staff become moreexperienced, they leave for more lucra-tive positions elsewhere. At the Madu-rai Aravind Hospital, our project wasdelayed when the experienced networkadministrator with whom we wereworking left for a more lucrative job inChennai. Much of the project knowl-edge left with him, and now we mustinvest a substantial amount of time intraining a new administrator. In fact, theAravind hospitals face similar problems


Cultural issues present the greatest challenges,

and they vary widely by region. We’ve faced IT

staff problems, tampering and theft, corruption,

and illiteracy.

with their doctors as well. No doctorsgo to the city of Theni permanently,despite incentives such as increasedsalaries. However, in Aravind’s case, themanagement views this training andturnover as a positive contribution: theysee themselves as creating more doctorsfor the region and contributing to manyyoung doctors’ careers.

Where Windows is prevalent, it’s hardto find experienced people to help us main-tain Linux-based equipment remotely,and it’s hard for us to provide that train-ing. To mitigate this problem, we’ve hadto develop detailed training manuals andprovide a Web-based user interface forviewing and modifying the configura-tion. These reduce the learning curve andalso simplify remote management butadd more delays to the research efforts.

Finally, training staff to troubleshootis important, so that when they encountera problem they can’t solve, they at leastcan give us more information than “thelink isn’t working.” We have the localadmins accompany us during the initialnetwork setup, and after training weleave behind spare parts for them to use.

Recently, we’ve had some success askinglocal admins to set up links themselvesas we watch or stand by on the phone;this breeds confidence in the admins andseems to bring them up to speed morequickly. We’re also starting to partnerwith faculty or students in neighboringuniversities to act as local contacts fornetworking issues.

Tampering and theftFabio Rosa’s company installs solar

power for people’s homes off the grid inEncruzilhada, Brazil, renting the equip-ment at the same cost as they would nor-mally spend on candles, batteries, andlamp oil.2 Initially, his team had to returnoften to make repairs, usually becausepeople became curious about the equip-ment left in their home and started tam-pering with it. The solution? He askedeach family who their favorite saint is andput the corresponding figurine on the lidof the box containing the equipment,thus preventing them from disturbing theequipment and underscoring that theyshould leave it alone.

In Cambodia, we deployed packet-

level network-monitoring software to logdata onto a USB drive; this lets us retrievethe data later, swap out the drives whenfull, and avoid filling local hard drives.We later found that the USB drive’s valuewas too much of a temptation—severallocal center operators had appropriatedsome drives for personal use, and otherswere simply missing.

Perhaps a better solution would havebeen to make a deal with the center oper-ators when we were installing the soft-ware, such as giving them several USBsticks up front in exchange for helpingus collect the data. We needed such anagreement with the operators in addi-tion to a broader agreement with thelocal partner, which we did have. Typi-cally, the operators value the actual hard-ware whereas the researchers value thedata it contains.

Batteries are also regularly stolen, asthe cage in figure 3 implies. In Ghana,Arrow Networks found that one of itsremote hilltop towers stopped working,only to find that the batteries were gone.Their solution: relocate a farmer onto thetower’s land in exchange for guarding it.

CorruptionAlthough we know of corruption prob-

lems in many countries, both industrial-ized and developing, our primary directexperience occurred in Ghana. Workingwith Arrow Networks, we’re building aWi-Fi-based backhaul network betweenAccra (the capital) and Kumasi in thenorth, about 300 km in total.

Two of the towers that Arrow Net-works uses on the route from Accra toKumasi are owned by Ghana Broad-casting Company and used for FM radiobroadcasting. Arrow Networks had anexisting contract with GBC to arrangeto turn off the transmitter when engi-neers needed to climb the tower, for a feeof US$100 per visit.

When we arrived, however, GBC’s



Figure 3. A battery in a locked cage inGhana. Heat dissipates better from thebattery in a cage than in a lockbox.

regional director in charge of that partic-ular tower raised the fee to a million cedis(US$660) per hour. Clearly this violatedArrow’s contract, but he was obstinate,and contracts are difficult to enforce inGhana.

As it turned out, a personal contactwho happened to be a radio personalityfor GBC later contacted the director andexplained that our project was intendedto bring low-cost connectivity to ruralGhana. The director then switched hisposition, saying that we could use thetower for free.

Ghanaians have a strong sense of socialresponsibility and also want to help outtheir associates. We were lucky to be ableto tap both: the personal contact and thesocial goal both probably contributed tothe director’s change of heart.

IlliteracyIn many developing regions, illiteracy

rates above 50 percent are common,3

making computers and technology inac-cessible without a literate mediator’s help.Many researchers have suggested speechrecognition as a key to universal access,but success stories are rare. In additionto the challenges of dialectal variation,multilingualism, cross-cultural barriers,and lack of linguistic resources, we foundthat illiteracy presents a significant obsta-cle to the traditional techniques ofrecruiting, recording, and user testing.

Recruiting. In Tamil Nadu, recording illit-erate speakers saying digits (zero to 10)took approximately six times as long asit did for literate speakers. The discrep-ancy was due to difficulties explainingthe task’s purpose, the protocol con-straints (no reading), the uneducatedparticipants’ inflexible and demandingoccupations, and apprehension. In addi-tion, illiterate speakers had limited accessto quiet spaces and longer social proto-cols for foreign visitors.

In Ettimadai, for example, a small vil-

lage with a large engineering school, ourlocal contact and interpreter—a univer-sity student who had grown up in anearby village—recruited (by word ofmouth) and arranged short appointmentswith both literate and illiterate individu-als. Participation was on a volunteer basis,as local contacts had suggested. On thefirst day, the villagers with little or noeducation all failed to show up for theirappointments. The next day, we foundthat four people had missed the appoint-ment due to work, one had to tend to asick child, and one reported feelingafraid of what might happen to his voice.When we worked alongside trustedorganizations that serve the rural poor(MSSRF and Aravind eye camps), wewere much more successful in recruitingand recording villagers, especially illit-erate volunteers.

Recording. Illiterate participants in speechstudies require novel speech-collectiontechniques. How do you elicit a partic-ular word from a speaker without sayingthe word yourself, thus influencing thespeaker’s word choice and pronuncia-tion? For literate or semiliterate partici-pants, bilingual flashcards with digitswritten in both numerical and ortho-

graphic form were randomized andshown to speakers one at a time, whowere recorded while saying the numberaloud. If a participant couldn’t read theflashcards, a researcher or interpretertranslated the flashcards into a displayof fingers (see figure 4). (A fist repre-sented zero.) Unfortunately, we failedto anticipate the cognitive differencebetween the task of reading numbersaloud and counting fingers,4 which hassignificant effects in the speech domain,such as more disfluencies (filled pauses,false starts, and repetitions) and shout-ing—for example, “um, thr ... no!FOUR! four.” In combination with envi-ronmental conditions, the techniquefailed to be free of external linguisticinfluence: recordings often took placeoutside or in a crowded room, where thetask of guessing the number of displayedfingers was often irresistible to “helpful”bystanders.

We had anticipated limited infra-structure and unfamiliarity with tech-nology among rural villagers, however,and built a custom microphone embed-ded in a telephone handset. The handsetwas easy for all speakers to use, eventhose who had seen but never used aphone. It captured quality speech record-


Figure 4. Collecting Tamil speech samplesfrom a semiliterate speaker in India.

ings in various environmental conditions(average signal-to-noise ratio was 29 dB),avoided the need to fasten equipment tothe speaker’s clothing, and didn’t requirethe use of a table.

User testing. Another challenge we foundin exploring speech technology for illit-erate users was in user-testing a spokendialog system that provides marketprices of agricultural commodities andweather. We conducted a Wizard-of-Ozstudy,5 which required one interpreter,one researcher acting as the speech rec-ognizer, and another bilingual researcherobserving participants and recordingcritical incidents. After a short demo bythe bilingual researcher, we asked sub-jects to perform three tasks (for exam-ple, “find the weather for today”). Thethree illiterate participants who agreedto participate performed comparably toliterate users.6 However, they had moredifficulty understanding the nature of a“task” and instead explored the systemout of interest or correctly completedunassigned tasks.

In addition, illiteracy appears to affecta speaker’s attention to linguistic form.One participant who had never been toschool repeatedly used the formal formfor “yes” (“amaanga”), which the sys-tem didn’t recognize. Despite the sys-tem’s explicit prompts for “amaam,” therecognizable form, and multiple instruc-tions from a bystander to say “amaam”instead, she continued to say “amaanga,”until finally quitting the system. Thisexperience, along with results from pre-vious user interface studies7 and cogni-tive studies that target illiteracy,8 suggestthat successful user interface solutionsfor illiterate users will rely on words andinteractions that are meaningful and rel-evant to everyday language use and won’trequire illiterate users to memorize iconsor command words. Our protocol alsoincluded a questionnaire intended to col-lect linguistic, educational, and regional

information. The participants with verylittle education completed only one ofthe three tasks, then politely excusedthemselves. They didn’t complete thequestionnaires.

Overall, we learned that individualswith little education can navigatethrough a dialog system that primarilyresponds to local terms for “yes” and“no” with very little training. The lengthy(45 minutes) experimental protocol,however, favored literate speakers andleft us unable to make quantitative con-clusions about differences between thetwo groups. We also found that tradi-tional data-collection and user techniquesfavor literate speakers. We’re exploringsimple, robust speech technologies thatadapt to users, thus avoiding the time-consuming, artificial step of recordingdisjointed instances of speech, which isparticularly ill-suited to an illiterate pop-ulation. Instead, by integrating data col-lection into a spoken dialog system, wecan meet the user’s needs (gaining accessto relevant information) and the system’sneeds (gathering speech instances toenable recognition) simultaneously.9

Despite these challenges, weplan to continue working indeveloping regions. The dif-ficulty of the work and the

value of the solutions make it quiterewarding. We offer these high-level rec-ommendations on how to approachsuch work.

• Plan hard, but be flexible. Our plansalways change in the field because ofequipment failures, power or staffproblems, or even local crises, and thusagility is probably the most importantgoal. Nonetheless, detailed planning isworthwhile, exactly because there areso many details: shipping ahead, spareparts and tools, transportation, andtime with local partners.

• Time dilation. Everything takes longerthan expected, which is frustratinggiven the limited time students havein the field. Often our goals for a tripslip, and we must complete themfrom abroad or wait until we canreturn.

• Bulletproofing. We spend much moretime than usual getting our systems towork reliably and to enable remotemanagement when possible. The dis-tance and lack of local IT staff place apremium on robustness of all kinds,including packaging, theft prevention,and power.

• Simple UIs. Similarly, for both endusers and IT staff we need simple man-agement UIs, especially for Linux. Wetry to put all the common managementtasks into a simple Web-based UI.

• Local partners. We depend on strong,long-term relationships with localpartners such as the Aravind Eye Hos-pital. Our partners provide designinput, vendor selection, deploymenthelp, long-term maintenance, andrespect within the community. Noneof this work is possible without them,and they are generally both capableand excited.

ACKNOWLEDGMENTSThis material is based on work supported by the USNational Science Foundation under grant 0326582and by Intel Corp. Thanks to Alan Mainwaring ofIntel Research Berkeley for the power quality mea-surements and to Michael Rosenblum of UC Berke-ley for input on customs and shipping.

REFERENCES1. E. Brewer et al., “The Case for Technology

in Developing Regions,” Computer, vol. 38,no. 6, 2005, pp. 25–38.

2. Y. Mugica, Distributed Solar Energy inBrazil: Fabio Rosa’s Approach to Social



Entrepreneurship; www.nextbillion.net/files/DistributedSolarEnergy_3.pdf.

3. Provisional Population Totals: Census ofIndia 2001, Paper 1, Office of the RegistrarGeneral, Ministry of Home Affairs, NewDelhi, India, 2001; www.censusindia.net.

4. B. Butterworth et al., “Storage and Retrievalof Addition Facts: The Role of NumberComparison,” Quarterly J. ExperimentalPsychology, vol. 54A, no. 4, 2001, pp.1005–1029.

5. J.D. Gould, J. Conti, and T. Hovanyecz,“Composing Letters with a Simulated Lis-tening Typewriter,” Comm. ACM, vol. 26,no. 4, 1983, pp. 295–308.

6. M. Plauché and M. Prabaker, “Tamil Mar-ket: A Spoken Dialog System for RuralIndia,” Working Papers in Computer-Human Interfaces, 2006.

7. T. Parikh, G. Kaushik, and A. Chavan,“Design Studies for a Financial Manage-ment System for Micro-credit Groups inRural India,” Proc. ACM Conf. UniversalUsability, ACM Press, 2003.

8. A. Castro-Caldas et al., “The IlliterateBrain,” Brain, vol. 121, 1998.

9. M. Plauché et al., “Speech Recognition forIlliterate Access to Information,” to appearin Proc. Int’l Conf. Information Technolo-gies and Development, UC Berkeley Press,2006.

For more information on this or any other comput-ing topic, please visit our Digital Library at www.computer.org/publications/dlib.


the AUTHORS

Eric Brewer is a professor in the Computer Science Department of the University ofCalifornia, Berkeley, as well as director of Intel Research Berkeley. In addition to tech-nology for developing regions, he studies Internet systems and programming lan-guages. He received his PhD in electrical engineering and computer science fromMIT. He’s a member of the IEEE and the ACM. Contact him at 623 Soda Hall, UCBerkeley, Berkeley, CA 94720-1776; [email protected].

Michael Demmer is a doctoral candidate at UC Berkeley and an intern at IntelResearch Berkeley. His research interests include delay- and disruption-tolerant net-working, distributed systems for unusual or challenged network environments, andthe application of technology in developing regions. He received his BS from BrownUniversity. Contact him at 74 Chattanooga St., San Francisco, CA 94114; [email protected].

Melissa Ho is a graduate student in UC Berkeley’s School of Information, research-ing communications and healthcare infrastructure for developing countries. Shereceived her MSc in data communications, networks, and distributed systems fromUniversity College London. Contact her at Intel Research Berkeley, 2150 ShattuckAve., Ste. 1300, Berkeley, CA 94704; [email protected].

R.J. Honicky is a doctoral student at UC Berkeley, researching environmental sensorsembedded in location-aware cell phones. He received his master's in computer sci-ence from UC Santa Cruz. Contact him at 545S Cory Hall, UC Berkeley, Berkeley, CA94720-1776; [email protected].

Joyojeet Pal is a doctoral student in city and regional planning at UC Berkeley,researching community technology initiatives in developing regions. Contact him at228 Wurster Hall, UC Berkeley, Berkeley, CA 94720-1850; [email protected].

Madelaine Plauché is a postdoctoral researcher of linguistics at the InternationalComputer Science Institute, where she investigates speech tools for limited-resourceenvironments and speech disfluencies. Contact her at ICSI, 1947 Center St., Ste.600, Berkeley, CA 94704-1198; [email protected].

Sonesh Surana is a doctoral student in UC Berkeley’s Technology and Infrastruc-ture for Emerging Regions research group. His current work focuses on low-costnetworking infrastructure, including using Wi-Fi for long distances and cellphonesfor rural data collection. He received a BS in computer science from Carnegie Mel-lon University. Contact him at [email protected].

the challenges of technology research for … challenges of technology research for developing...

Documents