. Question 1: What fruit did you eat today.
Ans: multi-select options (Orange, apple, watermelon, Guava, Pineapple, lemon, tangerine, carrot, spinach, okro, melon,). Please note that the respondent can only think a maximum of 5 products.
Question 2: Do you pay this seller at the moment of purchase? Product 1, (options: Yes/No)
product 2 (options: Yes/No) product 3 (options: Yes/No) … product 5
If the questions like question2 continue throughout the survey, enumerators would make mistakes in remembering the options the respondents picked in question 1.
Is there a way I can restrict the options selectable in the further questions to the 5 options selected in question 1
well, i think i understand
But very unfortunately, i don’t know how to use the excel to code the form.
i just use the form builder straight from KoboToolBox
I can see its a bit complicated but i also don’t have the time to start learning coding from excel now.
Is there a simpler way to use the form builder?
If you want share with me your form and I can work in it,
My user is: elvira_rios
And you can also send me the questionnaire to my mail: elvi_berzo@msn.com and I can help you with that
As stated, if you want to filter the displayed (ie selectable) options in, say, a multi-select you would use a choice_filter in your form. However, on re-reading your original post it actually sounds like what you are trying to do is present a multi-select (with all options visible!), and then subsequently loop (ie enumerate) over each selected choice and ask the same question: “Did you pay at purchase?”. Is that Correct?
If so, this usecase would actually be better handled with a repeat group to iterate over all the selected options. You’ll need to use a selected-at() calculation to display the current selected value inside the repeat group, and a count-selected() function for the repeat_count in your form [the later is not exposed in Kobo, so you have no choice but to manually edit the XLSForm file to add it].
The following form shows how all this works. Load it into XLSForm Online and have a play around:
Hello,
just take care (as generally with back-referencing repeats):
If the user goes back and deselects (or changes) any choice which was base of the repeat(index), the values get mixed-up wrong. See example below
choice 1, 2, 3
edit amount in repeat
go back and deselect 2
System now automatically maps amount from 3 (banana) to 3 (orange). That would be wrong from data content.
(Exception, no mix-up if only the last item was deselected.)
This is a very general problem, as the KoBo back-reference is by index and not by static id-reference. The only solution we found so far to avoid such mix-up, is to control if the repeat_count rep. the referenced items changed, and force the user to delete (or reedit) first all references after the deselected element, before he can go on (or successfully validate) Any better solutions would highly been appreciated.
A similar problem and mix-up happens for ex. if you have a (dynamic) HH roster and then repeating education data per person, And after entering education data, the user goes back and deletes a referenced person (but not the last one) in the HH roster…
Dear @Xiphware,
it is a very general problem with referencing repeats in KoBo, and I could not find examples for good and robust solutions in the community so far, how to avoid/control this mixing-up… Can you help? Maybe we should transfer this to a new topic?
Kind regards
It may be worth re-producing your above example on XLSForm Online, and posting the overall problem to theODK Support Forum. You’ll probably get better exposure to the issue there, and any long-term solution would probably require some changes to ODK Collect and/or Enketo anyway (if not something new added into the ODK Spec…).
Its an interesting problem, so I’ll be curious to see what idea’s folks may have around it approaching it.
