|
|
| Line 1: |
Line 1: |
| == Best Practice ==
| |
| Inside a self-contained repeat group, dealing with 'other' choices is relatively straightforward - we can add an 'other' response to a [[SurveyCTO Dynamically Populated Choice Lists|dynamically populating choice list]] and select from there. However, this gets complicated under more complex structures.
| |
|
| |
|
| Imagine that we are surveying smallholder farmers about their crop production and sales over the last year. To assist the analysis and structure the interview, we should take into account the crops produced, which plots they were grown on, and in which season. This might require having 3 layers of repeat groups: season > plots > crops. We are easily able to set up an 'other' crop as an option for produced crops at the bottom level, however, once we want to refer to this 'other' crop at either the plot or season level or in a different repeat group, SurveyCTO cannot then link this selected 'other' crop's ID with it's name.
| |
|
| |
| There are several ways around this, though none are perfect:
| |
| * Ask enumerators to reserve an 'other' crop option to a specific crop throughout the whole survey, where 'other crop 1' would always refer to one type, 'other crop 2' to another type and so on. In theory this would work, but is not recommended because of the large potential for enumerator error.
| |
| * Keep all questions related to the crops contained within their respective repeat group at the lowest level. Again, this is not ideal for the form structure, as we don't always, for example, want to ask about a crop's sales or processing over plots or seasons - we may just want to ask at the crop level.
| |
| * Define all the potential crops at the start (highest level) of the agriculture section. If we establish what the 'other' crops are at the start of the section, we can then dynamically add these to the crop choices in each lower level repeat group. The main drawback with this approach is that once the crops are defined you can't define more later on if the respondent forgets one. Out of the 3 approaches, this is the most viable to overcome the problem described above, especially when enumerators are well trained to predefine these 'other' crops and good form piloting has already defined all potential crops in the choice list. Also, any crops that the respondent may forget probably aren't that important anyway. The example below gives an example of how to develop a form under this approach.
| |
|
| |
| == Coding Example ==
| |
| [https://drive.google.com/open?id=1SWRRv6_WxNdFmeColcw5jyRVhsbUmMP_HGfeSQa1uAc Here is a code example] of ...
| |
|
| |
| == Back to Parent ==
| |
| This article is part of the topic [[SurveyCTO Coding Practices]]
| |
|
| |
| [[Category: SurveyCTO Coding Practices ]]
| |
