Survey logic and skip patterns
Relevance, skip patterns, constraints and calculations in Zottle forms.
How logic runs
Skip patterns and validation travel with the form. Whatever a form does conditionally is compiled into its XForm — the standard that KoboCollect and the web filler execute — so conditions are evaluated during the interview itself, on the device, online or offline.
Both ways of creating a form agree on that contract: a workbook imported as an XLSForm is compiled by pyxform, and a form built or edited in Zottle is compiled by the converter the Studio uses. Conditions written the XLSForm way — ${question} references — are turned into the expressions the device evaluates; a reference that cannot be resolved is reported by the form check, never compiled into a rule that silently does nothing.
Skip conditions
A question — or a whole group — can appear only when its condition is true. While the condition is false, the question is skipped: it does not come up during the interview, and the submission carries no answer for it.
A condition combines one or more rules with and / or. The supported rules:
- answered / not answered — the field is filled, or left empty.
- equal to / different from a value (text or number).
- comparisons — greater than, greater or equal, less than, less or equal.
- choice membership — the answer includes a given option (selected), or does not (not selected).
Conditions are built in the builder, or written in the workbook's relevant column (for example: age over 18, or services including water). A condition can only rely on questions placed earlier in the form — a reference to a later question is flagged by the form check rather than left to fail on the device.
Constraints
A constraint is a rule an answer must satisfy before the form can be finished; when it fails, the device shows the message attached to it. A form can enforce:
- comparisons — equal, different, greater or less than, greater-or-equal and less-or-equal.
- a regular expression — to enforce a format, such as a code or a phone number.
- choice counts — at most, or at least, a given number of selected options.
- a custom message, shown to the interviewer when the rule fails.
Calculated fields
A calculated field is computed from the other answers — a score, a total, a category derived from several questions. Nobody types it; its value is produced when the form data is evaluated, and it is kept intact when a form is exported and re-imported.
The form metadata uses the same mechanism: interview start and end times, today's date, the device id and the username are filled in automatically by the client and travel with the submission.
Required answers and read-only text
A question marked required cannot be left empty: the requirement is written into the form itself, so it holds offline as well. Instruction text (a label) is different by nature — it is stored as a read-only field, so it can never collect an answer by mistake, and it is normal for it not to be required.
Groups and repeated sections
Questions can be organised in groups — sections that can themselves carry a condition hiding the whole group at once. A repeat group is filled as many times as needed (each household member, each visit); every passage keeps its own answers, and groups can be nested.
What gets checked
Before a form is saved or published, Zottle runs a check pass over it. What can be repaired without inventing content is repaired — a missing technical name, a duplicate name, a label that is just the technical name, a list option missing its value — and what needs your decision is reported: a condition pointing at a question that does not exist, a condition on a question placed later in the form, a comparison without a value. While an error remains, the check does not declare the form ready.
Logic written in a workbook (relevant, constraint, calculation columns) arrives here intact: import it, check it, and the same conditions run in KoboCollect and in the browser.