Reporting Water Quality – A Case Study of a Mobile Phone

Application for Collecting Data in Developing Countries

Introduction

• Aquatest project started 2007 – develop a low-cost, rapid-response water test kit

• Mobile tools for information collection• “better access to information enables

better decisions, improving service delivery”

• Water supply caretakers (operators) are comfortable with mobile phones

Water Quality Reporter (operators)

• Targeting low-end/feature phones – Nokia 3310c, 2700c, 2710n (GPS)

• Built on JavaRosa project – XForms• Automatic form and sample point synchronisation with

WQM• Can add additional samples points from the phone• Application available in multiple languages (Latin

alphabet)• Custom question types outside of XForms scope –

location and min/max/average

Water Quality Manager (web)

• Fork of Dimagi's CommCare web application• CHW/cases vs. caretakers/water samples• Forms associated to domains• Parameters can trigger SMS warnings• Automated email reports (Excel)• Google Map view and admin area for managers to set

up notifications and reports

Water Quality Manager (Android)

• Managers often on the road between sites - “on the run”• Read-only interface to sample data from WQM web

application• Samples synchronised daily• Calendar view with colour-coded results for easy

identification by managers• List views and map view also available

Development process

• Agile – rapid prototyping, multiple iterations• Participatory action research – stakeholders involved in

every iteration• Tried to close design-reality gap• Academic solution vs. real world, ingenuity vs.

usefulness (e.g. barcode reader)• Feedback from operators on the ground often lead to

improvements• Insight into management hierarchies and information

flow

Pilot sites in South Africa

• Well-defined and understood process for testing and reporting – WQR replaced paper log-books

• Initial training sessions important for project success• Operators travel far to training• A large set of sample points and operators is hard to

manage• Mobile phone screen size issues• Need buy-in from everyone – in a small office, one

person can derail the project

Vietnam

• Private water utility – supplement already extensive testing procedure with WQR

• Large number of tests done weekly – min/max/average question developed for this specifically

• Internal IT team wanted access to raw data• Local context is very important!

– GPRS set up

– International SMS provider

– Language barriers - “training of trainers”

Cambodia

• French NGO – providing communities with small water treatment plants

• Local team regularly tested for contamination – WQR replaced logbooks

• Extraordinarily motivated team – recorded video tutorials, set phone backgrounds, checked up on operators

• Language barrier was tricky (Khmer script) – resorted to printed and laminated translation tables

• Operators comfortable after a few test runs

Mozambique

• Well-point drilling campaign (One Million Initiative)• Local context

– Portuguese locale uses comma as decimal separator

– Poor network coverage / GPRS settings• Reporting module inadequate for national government

but we wanted to keep the system generic (scalability)• Excel macro on raw data was able to generate

sufficiently “advanced” reports (including map overlays)• Local managers not interested in trend analysis

Common themes

• “Out of memory” errors• Operators deleting application from phone• Operators downloading music and videos (memory)• GPRS settings and network coverage• Application reinstall is tricky – hard to coach operators

through this process• Financial structures with network providers don't

adequately cater for projects (reverse-billing)• High level of variability in rural projects – be prepared

Wrapping up

• Again, solid understanding of your local context will define your project success

• Integrate within an organisation - people know what they need

• Don't be married to your ideas - respect local opinion/knowledge

• Identify and compliment existing systems (IT-based or not), and do not try to replace them outright in one go

• Accept that there are external factors that you have no influence over

The end

Michael Champanis / michael@icomms.org

University of Cape Town

Project source code available at:

http://github.com/icomms and

http://bitbucket.org/icomms