From Random Hacks of Kindness
(Our discussion group is: http://groups.google.com/group/wfp-vam-field-survey-tool )
[edit] Contacts:
WFP Staff and Skypenames. (all email addresses are name.surname@wfp.org)
- Patrick McKay patrickmckay
- Stefano Giaccio s.giaccio
- Wael Attia wael_w20
- George Muammar geo-rge-118
Participating volunteer
- Chris Nicholas chrisgnicholas
[edit] Overview:
The United Nations World Food Program (WFP) - Vulnerability Analysis and Mapping (VAM) branch implement food security monitoring and analysis systems in many countries worldwide. While much can be inferred from aerial imagery and pre-existing records, good field data about hunger, malnutrition and the underlying factors, gathered by on-the-ground survey efforts that are designed, executed, and analyzed accurately and efficiently is critical to good decision making at all levels of policy and logistics. This is particularly important in rapidly unfolding crisis situations, where decisions about precious intervention resources must achieve maximum impact in a time-critical manner.
see the videos:
http://mobileactive.org/mobile-data-early-warning for work description
http://www.youtube.com/watch?v=G7UDug7-sVM for RHoK problem definition overview
http://www.youtube.com/watch?v=_q6t0y-gI0E video on old softare. How to author, deploy, collect and export data
http://sites.google.com/site/wfppdasurvey/home/software for old software: download field kit and backends
While decision-support in some countries is still paper-based, there is a vast opportunity to harness mobile devices (PDAs, smartphones, and SMS). This RHOK effort is to evolve WFP-VAM's current PDA survey tools to embrace next-generation XForms open-source frameworks, as per: as per: http://xformsinstitute.com/essentials/browse/book.php. . The goal is to identify and/or enhance a set of authoring and runtime environments capable of supporting WFPs statistical surveys, validation mechanisms, and multimedia capture requirements, in a wide range of languages, within the context of organizational workflow. Towards that goal, we intend to migrate existing infrastructure to the XForms framework,
WFPs existing authoring environment is a mix of MS Access and embedded VB scripts, that emits XML for use by a java runtime on Windows mobile PDAs. It is envisioned that the RHOK efforts will help WFP identify capable Java servlet, J2ME, XML/XPath/XForms, and VBScript programmers that can:
- determine if Core XForms can address WFPs needs, or if extensions are needed, and if so, what they are
- enhance the VB scripts to emit XForms compliant XML that can run on a number of mainstream processors
- identify a suitable alternative for XForms authoring that can produce the same XML and reuse form logic
- identify a suitable J2ME runtime XForm processor (Java Rosa?)
- define offline/file-based submission tags suitable for field work and batch sync
- explore suitability with ODK and other Android clients
relevant projects are:
The bulk of WFP's data collected focuses on nutritional indicators, market prices, import, cross border trades, socioeconomic indicators, agricultural data and health indicators. The Vulnerability Assessment Mapping (VAM) unit is trialing both FrontlineSMS and RapidSMS in its current projects, as well as a custom PDA tool.
In the process of collecting data, WFP always collaborates with governments and other UN partners. WFP staff are involved with the supervision, training and coordination but the people who conduct interviews and collect the data are usually government staff, university students, or NGO workers As one WFP staffer noted, "We have huge armies of data collectors."
The scope of the work is accordingly large. Most of the efforts cover an entire country. In Senegal, for example, WFP has 250 numerators covering the country – 22 teams of 11 people each who are collecting data for six weeks, visiting 2,000 villages.
These surveys are often common with the World Bank's Living Standards Measurement Survey (LSMS) and UNICEF Multiple Indicator Cluster Surveys (MICS) data collection at household and community levels and are often joint assessments with UNHCR and WHO. WFP VAM partner with World Bank LSMS team also for finding a suitable software solution for field data collection.
[edit] Surveys and advantages of using mobile technologies
The data collection is based on interviews to the household members and community leaders, and based on enumerator observations (anthropometric measurements of household members, for example). Mobile devices (cell phones, PDAs, UMPCs, Netbooks, laptops) to perform data entry in the field have achieved huge successes on several fronts.
[edit] Data quality:
- Questionnaire logic being enforced by the device (skips, mandatory responses etc)
- Validation (exclusion of impossible answers)
- Data entry clerk errors are eliminated (Handwriting interpretation errors, misunderstandings)
- Data collection can be monitored and errors can be corrected during the data collection phase (elimination of systematic biases in measurements for e.g.)
[edit] Timeliness of data availability for decision support:
- Data entry time is eliminated
- Data can be transmitted from the field (SMS, mobile internet, internet caffe)
- Data cleaning is greatly reduced
- Young enumerators find data entry easy and quicker than writing, also are more motivated on the job
[edit] Reduction in costs and environmental footprint:
- No data entry costs (data entry db and front-end, no data entry clerks)
- No paper, toner, printer wear (typical paper based assessments can use 50,000 sheets and 25 toner cartridges)
- Mobile devices can be shared between offices and used for many surveys
[edit] Data safety:
- Data is transmitted and stored on a central (backed-up) database, or stored on removable flash memory with appropriate back-up mechanisms
- Locally stored data can be encrypted so as not to fall in wrong hands (in cases of countries with conflict situations)
[edit] Areas of further development possible through RHoK:
[edit] Questionnaire development:
- Metadata can be defined at the question level during questionnaire design. IHSN have developed metadata editor for household survey metadata.
- An online questionnaire repository could be made. But questionnaire authors would not like to reuse questions and would prefer to create their own. Online access is not always available in countries.
[edit] GPS track data mining possibilities:
- GPS road tracking
- Cropped area measurement by walking around the field
[edit] Multimedia possibilities:
- Audio recording of interview for qualitative reporting
- Photo/Video recording for security reporting
- Photo-based response selection
[edit] Statistics during data collection:
- How long does a questionnaire take to compile?
- Which questions took long to respond to?
- Which replies had to be revisited/changed?
[edit] Software installation/data transmission:
- WLAN could be used for parallel installation/data transmission on all mobile devices. Shortcomings / lessons learned with SD cards, peer-peer, etc
- Mobile internet connections are unreliable and coverage is incomplete. Manual connection is complicated where reception is not good, and GSM data transmission is blocked in several countries, PDAs.
[edit] UI design
- Screens are too small for complicated questionnaires for some users
- Batteries are not large enough to allow full screen brightness for 8 hrs per charge
- Stylus and tiny keyboard are too slow for data entry
[edit] Data Entry from Paper
Paper is still being used in some assessments, usually because of the low profile of enumerators or because of lack of faith in the technology. Paper-based questionnaires should still fit into this project in particular in the phase of questionnaire design and in that of data entry from paper. Simple camera-based capture, and potentially some level of OCR, might be incorporated.
[edit] Features required from the Questionnaire Management Application:
A web-based application that enables assessment organisers to:
- Consult guidelines for electronic questionnaire creation
- Consult a repository of existing questionnaires and select sections that can be re-used
- Create a questionnaire using an offline client. Note that questionnaire creation is an iterative process that undergoes many edits due to multilateral decisions. Therefore:
- Versioning should be implemented on the questionnaire
- Each change to each question should be documented with reason for change
- Rearranging of questions should be a quick easy process. Questions should be auto-positioned and not require manual positioning in the form builder, for example.
- Metadata should be created for the questionnaire in compliance with the IHSN specifications
- Questionnaire builder should prepare the questionnaire in an XML file, compatible with WFP current XML schema
- Questionnaire can be exported into an MS Word compatible format for printing on paper (for paper based assessments). In order not to waste paper, questions should be tightly packed (or should allow for manual packing in MS Word document)
- Offline client should deploy data collection software and questionnaire onto other client computers/PDAs via LAN/WLAN (see below)
- Data collected should be harvested via LAN/WLAN from client computers and exported into SPSS and CSV formats
[edit] Features required from data collection software
- Platform: Should run on PDA (Windows Mobile 5, 6 or Android), tablet, UMPC, netbook, notebook or desktop PC (for data entry from paper questionnaire). This probably implies it must be written in Java
- Locale: should handle international scripts (including right to left) including Arabic, Amharic, Chinese, Cyrillic, and Latin characters.
- Easy Installation and autoupdate
- First time installation from flash memory card/USB drive with autorun
- WLAN or LAN to search for questionnaire/software updates and to respond to data download requests.
- Should be backward compatible with WFP XML formats (questionnaire definitions and micro data - more detail to follow...)
- Should handle tables and rosters, even nested up to 3 levels (tables do not have to be physically nested in the data or graphically on the screen, but there is the need to copy some of the fields from parent table to the child table in order to build the relation, and the user should be able either to compile the tables iteratively or recursively)
- Different types of fields are described in the next section, with validation techniques
- GPS should be able to take points, lines, polygons as described in the fields section. GPS coordinates are fields, enabling the questionnaire to have gps data in response to individual questions
- User should be able to switch views between single field view or whole section of questionnaire as a scrollable page.
- Each field should have an info button that explains more info on what is being asked. The info screen should include images if necessary.
- Data should be autosaved every few minutes, possibly using idle time
- Data should include version information: version of data collection software, version of questionnaire, version of questionnaire builder (for debug purposes)
- Data entry should be as rapid as possible. Automatic cursor placing in the next field, automatic scrolling of page. Keyboard shortcuts and Tab stops should be implemented for data entry with keyboard.
- Double check should be implemented for data entry from paper. Two clerks will enter the same data from a paper questionnaire. When the 2nd clerk enters a value for a field that is different than the 1st clerks value, then an alert will sound and the clerk is asked to double check and confirm. This assumes synchronisation with a central server must take place before the 2nd clerk starts working. It may be necessary to implement comparison of two questionnaires after data has been entered.
- Timing of questionnaire response should take place as follows:
- What time questionnaire was started
- How long for each field to be completed (time between finishing entering one field and finish entering the next)
- Screensaver time should be excluded
- Questionnaire can be saved at any moment, but cannot be tagged as “completed” until all mandatory fields are entered and validated, or if a password is entered to bypass this check.
- When application opens it lists all questionnaires present in the device’s memory. The list should show all fields marked as questionnaire IDs, whether they are completed or not, the creation date and last edit date.
- Fields
- Field types should include the following (parameter=default value for parameter if applicable). Each field should have an Field_ID and a label (text string displayed in front of the field). Should have the following parameters: width (in characters), optional=false, show field_id=true
- Integer (minimum, maximum)
- Integer by dropdowns - a quick way to enter integers, open to discussion (min, max)
- Float (min, max, n. of decimals=1)
- Text (min number of characters=0, max number of characters=50, upper case only=true)
- Dropdowns – a list of label, value pairs. (limited to list=yes, show value in label=false)
- Dates dropdown (min date, max date=today, day=mandatory|optional|hidden, month=mandatory|optional|hidden, year=mandatory|optional|hidden)
- YesNo (Unknown=false, N/A=false)
Notes:
- Some fields can be flagged as Questionnaire ID fields. This means that the concatenation of the values of these fields will make an ID that uniquely identifies the questionnaire. The total defined length of these fields should not exceed 255 characters.
GPS
- Points (lat, long, elevation, Time, PDOP)
- Tracks (start time, end time, length) with the possibility of marking points of interest along the track
- Polygons (area, perimeter, perimeter/area index, max PDOP)
[edit] Similar projects and Resources