Platform: KoboToolbox, web forms via Enketo (not Collect).
What the form does
Monthly PMER reporting form, 7 programs. Each program has a fixed list of activities (28/27/30/37/11/17/23 = 173 total). Each activity is one of two types, pulled from an attached CSV via pulldata():
- ‘matrix’ type (82 of 173): a sex × age disaggregation table, ~49 fields per activity.
- ‘integer’ type (91 of 173): just two simple integer fields.
Both blocks exist in every iteration and are switched by relevant on question_type. Per-iteration calculates use position(), selected-at(), jr:choice-name() and pulldata(). The matrix-type activities are unevenly distributed across programs: concentrated in 3 programs (TS=27, HC=19, EP=17); the other 4 programs are mostly integer.
Problems of two designs:
Design A: fixed repeat groups (one repeat instance per possible activity):
- repeat_count = is a fixed total defined at the top of the XlS (e.g. 28)
- relevant on each iteration: selected(${activity}, ${activity_code_fixed})
- Result: NO data shifting (each repeat group permanently bound to one activity), BUT won’t submit, takes too much time, sometimes the submission gets through, but it does not seem reliable. The ~49-field matrix is built in every slot before being hidden… regardless of whether that activity is matrix-type, so it fills slowly and hangs on submit.
Design B: selection-driven repeat groups
- repeat_count = count-selected(${activity})
- Result: light, submits fine, BUT data shifts. If the enumerator enters values then goes back and adds/removes an activity, the slot→activity mapping reindexes and entered values stay bound to the slot, not the activity.
Fixed slots = correct but too heavy; selection-driven = light but shifts.
What I’ve already tried
- Moved per-iteration calculates (jr:choice-name, pulldata) inside the relevant group so they only evaluate for selected activities. Still won’t submit.
- Switched to count-selected (Design B): submits, but reintroduces shifting.
Question
The heavy part is building the ~49-field matrix in all 173 groups, even though only 82 activities are actually matrix-type and only a few will be selected per month. Is there a known pattern that avoids data shifting while preventing Enketo from instantiating the matrix block in the groups that are non-relevant or non-matrix? Thanks!
