How can I adjust follow-up repeats when answer from select_multiple changes?

Hi @Fabla,

A colleague and I have been experimenting with repeats based on select_multiple counts, such as in your example, and we noticed that responses get displaced if changes are made to the select_multiple question after having started to fill out information in the repeated fields. For instance, in you start by choosing "person 2" and "person 3" in the select_multiple question, and then realize, after having filled out information for these two persons in the repeat blocks, that there is also a "person 1", the information for person 2 is now in person 1's repeat block.

To try to solve this problem, we tried to use dynamic defaults (https://docs.getodk.org/form-logic/#dynamic-defaults-from-form-data) to clear all values in repeats whenever the select_multiple questions is modified. Unfortunately, only the fields in the first repeat block are cleared using this function. How could we use dynamic defaults to clear fields in all repeated blocks (1, 2, 3, etc.)? See slightly modified program attached with my additions in red font, under columns "appearance" and "trigger".repeatgroup.xlsx (48.1 KB)

Welcome to the ODK forum, @A3pn_Haiti! We're glad you're here. When you get a chance, please introduce yourself on this forum thread. I'd also encourage you to add a picture as your avatar because it helps build community!

A similar issue is discussed here:

Maybe it will help with understanding the repeat group behavior?

Are you only collecting gender and occupation for up to 10 people? It's not elegant but you could create a group of questions for each select_multiple option and use relevant on each one to show/remove as needed.

Are you planning on replacing the "person 1, person 2, ..." with some other text? If not, can you change it to an integer question asking "how many household members are available?" and then do they repeat group # based on that?

1 Like

This is a good instinct and it looks like what you've hit is a bug/incomplete solution which I will look into. Thanks for bringing it up.

To be explicit, what you'll find @A3pn_Haiti is that you not only have the issue you described with values being offset but will also end up with extra repeat instances if fewer people than initially thought end up being available.

I agree with @danbjoseph that more information about your real scenario would be helpful. Do you have a fixed people roster that will be in your choices sheet? If that's the case, I would recommend using a repeat with a fixed number of repetitions based on the number of people. The first question in each repeat instance would be "Is PersonX available? yes/no". This would be followed by a group of questions with relevance based on the person's availability -- there would be no further questions asked about someone who is unavailable. If it's later found that this person is available, changing the availability response to 'yes' would reveal the follow up questions.

Hi @LN and @danbjoseph thanks very much for your responses.

I've attached a real example taken from one of my questionnaires. vegetables.xlsx (15.6 KB)

In this example, we ask the participant about the types of vegetables they consumed in the past month. For each selected vegetable, we then ask how often they had it in the last month, using repeats.

@LN thanks so much for looking into my question about using dynamic defaults to clear responses within all repeat groups. Any luck finding a solution?

Cheers,

Hi @A3pn_Haiti , I think @LN is right that could be a bug in collect, can you tell us the version of your ODK Collect, so that I can try it and see where the problem is.

1 Like

For what you describe, I'd generate as many repeat instances as there are choices and use relevance to only show the contents of the repeats corresponding to the choices that were selected. This is truly dynamic based on the selection and it allows for choices to be selected and unselected without their consumption frequencies being lost during a form-filling session. See an example here.

An inconvenience with this approach is that you'll see 25 repeats for every submission even though most will typically be empty. These should be easy to filter out so it doesn't seem like a big deal to me but it's something you should be aware of. An alternative is to "unroll" the repeat and have 25 groups with relevance based on the selection. The advantage of this strategy is that analysis on a per-vegetable basis would be very easy.

@Fabla the clearing-related issue is filed at https://github.com/getodk/javarosa/issues/627. However, clearing all the counts when the select value changes doesn't seem like a very good user experience. I hope what I've outlined above will serve this need.

1 Like