XLS form- Repeat select_one question until "A" is selected

Support
21

Haha, I hear you. I always try to work around it in survey design and there's generally a way. I'm glad you were able to get to something you like!

I've filed a documentation issue at https://github.com/opendatakit/docs/issues/1042 to make these approaches easier to find.

1 Like
22

Wow, that works great. One remark:
When I add the full path /indefinite-repeat/..... this is not working.

However, if I set it the way you showed in the spreadsheet on google docs, it works flawless.
Now that it works, I will think if it is worth to have decrease option by the user, for exemple if he changes the previously "do you want to repeat?" question.
Thank you.

1 Like
23

We made some changes to the XLSForm converter a few months ago and now the XLSForm filename isn't used in the path by default anymore. Instead, /data/ is always used. Indeed, what I did in the sample form lets the form conversion fill out the group path and thus always works:

if (${count} = 0 or (${person}[position()=${count}]/choice != '' and ${person}[position()=${count}]/choice != 'a'), ${count} + 1, ${count})

Thanks for pointing that out -- I'll make an edit to the post marked as the solution to reduce confusion.

24

HI @LN et al.,

I'm writing to ask about a small wrinkle in this elegant example...in our form the question that triggers adding another repeat group is this: Was that the final household in this multi-family dwelling? (A response of `no' means we should add another group (household) and 'yes' means we should drop out of the repeat and get ready to finish the form; 'yes' is analogous to stopping condition 'a' from your example.)

The problem we run into is when someone MISTAKENLY says 'no', thinking they need to do an additional interview. They tap 'no' and swipe forward; the repeat counter increments and a new group is added. If they swipe back and change 'no' to 'yes' ( 'b' to 'a' ) and swipe forward again, presumably the repeat count logic does not increment the counter yet again, but it's too late...aargh...repeat count has already been incremented after the first 'b' and swipe-forward. So the form takes the interviewer on an extra faux trip thru the repeat...(at which point some of them get creative in trying to save and abort the form).

Is there a sweet way to decrement the repeat counter if the user swipes back into the bottom of the previous repeat and changes 'b' to 'a'?

Many thanks,
-Dale & @marykaytrimner

25

I see now that @RafaelKluender also asked about users changing the repeat question.

As far as I know, there is no way to do this programmatically. There should be conceptually but some quirks of the evaluation engine currently make them impossible:

  • When repeat count is decreased, repeat instances are not deleted. This was a deliberate choice to avoid accidental data loss. The general recommendation is to use a group inside the repeat with relevance testing against the target count to hide repeat instances that are no longer desirable. This means that if the count is adjusted up again, the data will not be lost. This approach doesn't work in this case because of the reasons below.
  • Attempting to use references to values in other repeat instances in a current repeat instance is incorrectly considered a reference cycle.
  • When a value inside of a repeat instance updates, values in other repeat instances are not recomputed. This limitation has always been there and is a performance tradeoff.
  • Relationships between relevance and calculations are incorrectly considered reference cycles.

The latter two probably should be addressed at some point but will likely not be a priority for some time. The first probably is not realistic to address.

I would train data collectors to long press on the label of a question that is in a repeat they accidentally added and then select "Remove Group". This is functionality that is kind of scary and should be used with care but with proper training I think it could solve the issue here.

26

Thank you very much for this context and suggestion, @LN. I think we're going to use your earlier suggestion and remove the HH loop from the form altogether and 'pull forward' the last lat/lon when needed. This appears to offer several advantages in terms of simplicity and less susceptibility to RAM problems. Sounds like we may be moving to a new phone model for our 2021 operations, as well. I'll write back and let you know how it goes. We, like others, are disappointed to not have a super stable deviceid field anymore, but we will make the best of the new solution.
Gratefully, -Dale

1 Like
27

This is one you'd have to take up with Google! I agree having a stable id has been very useful for Collect users. It's a pretty scary thing for any app creator to have access to, though, so it feels like the right move. Since you are going to own the devices you hand to data collectors, consider looking into solutions that will prevent app uninstalls. App id changes are only triggered by an app reinstall.

1 Like