I have posted previously about using Pendragon Forms 5.1 to conduct surveys in low resource areas (here and here). Several colleagues and I recently finished a baseline survey in northern Uganda using Forms. And I am currently helping another colleague conduct an HIV survey using Forms in rural Kenya. I learn a few new things with each survey. It’s about time to jot them down.
In each survey, enumerators have made mistakes entering participant ID numbers. Since we use ID numbers rather than names to identify participants, it can be tricky to resolve errors. Checking your data every day is one way to guard against problems. Another is to design error checks into your forms.
In the Kenya HIV survey, we limited the acceptable range for ID numbers to the numbers we planned to assign to participants (i.e., 1000 to 2300). Then we designed screens to verify the ID numbers that are entered.
In the first screen, users enter the 4 digit ID twice and click on the “Do they match?” button.
If the ID numbers do not match, Forms redirects the user to an error notification screen that loops back to the original ID screen for re-entry.
When the user enters matching ID numbers, Forms displays a final verification screen that prompts the user to verify that the ID number entered matches the number assigned to the participant on the paper master list.
If not, the user can choose to be looped back to the original ID screen. Otherwise, Forms continues to a menu screen where the user can choose to start a new survey, resume a survey, or quit the program.
If the user is resuming a survey, the following screen allows her to select the correct section.
A resume option is helpful because enumerators occasionally need to suspend the survey because the participant has an emergency or runs out of time. Sometimes weather is the culprit.
There are different ways to allow users to resume a survey. One is to enable the “Review” option in Forms. I don’t like to keep survey data on the PDA, so my preferred solution is to create a screen that allows the user to jump to a specific section and start a new survey from this point. For instance, if an enumerator finishes sections 1 and 2 on Monday and returns to finish the survey on Wednesday, she would enter the participant’s ID number, select resume, and jump to section 3.
In this design, each section is created as a separate form [Note: If you have a big survey, you have to break it up into different forms because of limited number of screens allowed per form]. In the database, forms are stored in different tables that can be linked by the participant ID number.
The key to this system is to train enumerators to always finish a section before ending a survey prematurely. I’ve not found this to be a problem when the sections are kept short. The problem with ending in the middle of a section (form) comes in the data analysis phase: Two (or more) records are created for the same participant in the same table. By always completing a section before suspending a survey, you avoid having multiple records in a table for one participant.
To make it harder for users to end a survey in the middle of a section, I disable the “end” button on each screen. If you disable the end button, it is good to add a single Quit button at the end of the every section as shown below. Without a quit button, the only way to end the survey prematurely is to delete the record.
Click here to download the main survey form for entering participant IDs shown above.
