This has been on my list for some time, but nudged by the work of SurveyCTO, I'd like to develop ODK versions of the Progress out of Poverty Index (PPI) tools. I've been using PPI extensively recently, and think developing tablet-based versions could add a lot of value.
There are PPI tools available for 60 countries, each comprising of 10 questions. I'm happy to start working my way through this, but would be very grateful for a very experienced ODK developer to QA at least the initial few forms. Alternatively, we can develop one core form together and then others can take responsibility for a few countries each. As the PPI is only 10 questions, it's not a huge endeavour but could be a great resource.
I like the idea of starting one core form that gets really polished and then working on getting the others to that level. @Calum perhaps you could start by putting one that you have up on Google Drive with comments turned on? We could also schedule a quick call for those interested to discuss and plan.
I've had a little time this week to put together a very basic form for Afghanistan. It can be accessed here. The introduction, formatting etc, will all be done later. I've turned on the comment functionality, so please do add your thoughts and suggestions.
You can also find the Afghanistan PPI Scorecard (with the values for each answer) here.
The PPI is an index, so each answer has an associated value. These are then summed, with a total for the entire ten questions ranging from 0 to 100. Each country has a 'Lookup Table' (on the Scorecard, above) where the PPI value can be used to identify the probability of household poverty against a range of different poverty lines.
The main question I'd like feedback on is the calculation aspect. I've added placeholders for individual calculations for each of the questions - to get the total for each question, and then the total household 'score'. However, a lot of the time this analysis will be done following the submission of responses, and is probably of little interest to the enumerator (it may also encourage some enumerators to focus too much on the values, and what the 'best' value is). So, should we build-in a calculation function, or drop this completely? I'm happy to write Do files for Stata and SPSS to do the conversion on a dataset if we feel this might be a better approach.
I'm only passingly familiar with PPI so take my feedback with a grain of salt....
One option is to do the total household score in the form and store the value as a calculate without a prompt that a user can see. This will make the value available to folks looking at the data in Aggregate them having them do math. And those implementers of PPI who want to show that value can add a note prompt to show that value.
As to the lookup values, I wonder if all the country values can be bundled into a CSV. My quick math says there should be 1200 rows (60 countries * 20 score ranges) and 6 score types and Collect could handle that easily. And again, you can choose to show this or not.
Thanks for this. Agreed that it would be helpful for the calculation to be done regardless of the user being able to see it. I'll add the calculate function in.
With regard to the lookup, the PPI questions vary between countries - so the associated scores will also change. So we could have a master CSV of all scores or add these into the Excel on a country-by-country basis. I'm inclined toward the latter, to minimise the work of the user in ensuring the CSV file is pulling through correctly but will have a think.
My name is Ruthie, I work for SurveyCTO. I just wanted to let you know that the SurveyCTO forms for PPI are excel templates and can be used in ODK with just some slight modifications (if any). As long as anyone modifying the forms gives credit to Amrik Cooper and IPA as the original authors, they are a publicly downloadable resource and can be used by non-SurveyCTO users too. You can find the SurveyCTO forms here.
Thanks for the kind offer, that's very much appreciated! You guys have done a great job here.
I'm personally still interested in developing this as a community effort. In particular, because the PPI surveys have regular updates and it would be nice to not have to rely on a particular company hosting them. You're a very busy organisation and it wouldn't be fair for you to prioritise keeping them updated at the expense of other activities. I'd be very grateful for your inputs though, as we build these!
To anyone interested in contributing: I've been tweaking the survey since its original version, so please have a look at the Sheets link in my original post. In particular, I'm interested in:
Feedback on the calculate setup at the end. I think this is working fine
Thoughts on the final element - whether or not we should provide the PPI status against set poverty lines. This would require a lookup function and an additional csv file (I don't think we could do this within the same document, but happy to be corrected!)
Whether it's worth pursing this in light of Ruthie's very helpful comment above
I've given a comment. I think in general this is a great initiative, and we could think of doing this for most of the standardized questionnaires, such as FCS (Food Consumption Score), HDDS (Household Dietary Diversity Score) etc. I think there is a lot out there, which gets coded over and over again (I cannot remember the times, I had to code the above).
Thanks for the engagement! I've responded to or resolved comments accordingly, so please do keep adding thoughts and feedback. I'll hopefully be able to get this version finalised on Sunday and we can then use it as the basis for the other tools - perhaps drawing on more of the members for development and translation.
Thanks again for additional comments. I've incorporated these, so I think this is almost sorted. Three points that I'd like to get feedback on are:
Is it possible to count the number of times that a respondent uses a particular answer? For example, I'd like to count how many times a respondent answers 'don't know' or 'didn't answer' for the entire survey (and add this at the end)
For those two answers, I've put an associated value of 0. Usually, I'd prefer to add something like 99, so it's clear that this is not a response. However this would screw up the PPI calculation, even if used on only one question. Using '0' also errs on the side of caution - assuming that households are poorer than they are if the answer to this question was known. There's a lot of discussion on the PPI forum around this, and the difficulties of missing questions, so grateful for other thoughts/comments.
How useful is it to calculate PPI look-up values in the survey itself? I've added a calculate function for the PPI number, which will be hidden, to make it easier when analysing data (avoiding having to sum/calculate in Stata etc). However, would it be useful to also calculate associated probabilities of poverty for each poverty line? My instinctive feeling is that this wouldn't be that useful, and may add to the complexity of administering the survey (as a separate csv would need to be included with the survey tool) and may not be useful for analysis (as different poverty lines are of interest depending on the analysis being completed).
and 2. Selects use the name of a choice to keep track of which was selected. The way things are set up now, multiple options have the same name. I think this means the form won't be meaningfully editable after save because the choice selected with name '0' may not always match. This is something that should probably be reconsidered. You could separate out the name and the value using a strategy similar to the one I outline in 3. That could also let you differentiate between answers of 'don't know' and 'didn't answer.' Let me know if you want examples.
hi @Calum. i have gone through your three points above and this are some of the comments i have on each of them.
it is possible to count the number of times a respondents say don't know to a question or refused to answer there are two this i will recommend.
you can put a calculation for all the question with the don't know and refused to answer questions with a if condition. so you may say that that if don't know is selected give 1, otherwise give 0, and same to the refuse to answer so that at the end of the form you can calculate all the question with don't know and that of refused to answer.
you can also do this by using stata after all the forms have been downloaded. you can count don't know and that of refused to answer.
i agree with you that if you add something like 99 for the code of don't know or refused to answer could led cause mess when you are doing the calculation for the PPI. hence i will suggest that you can put them together and assign 0 to them. example don't know/refused to answer = 0. so during calculation this will not really affect the outcome since 0 will not add or reduce anything in the PPI calculation.
For the issue of difficulties in the missing questions, i will suggest that the questions should be meant for the most knowledgeable person in the household, this person answering the questions will provide you with the necessary answers and if possible the respondent should be given the chance to verify an answer from someone within the household who may have the idea about that question. Also the should be a note or hint to explain the question a bit for clear understanding to the respondent so that he will be fully aware of what is require.
I have conducted a similar survey and have the done calculation for every household to get which category the of the PPI the household fall under and if there is a need to have a separate questions for specific household then that can be done easily without downloading the data to know which house household is qualify for the next set of question. attached is a sample file for only the PPI and the calculation for various categories i used may be you can have a look at it too. ppi_2017.xml (19.5 KB) ppi_2017.xlsx (44.8 KB)