goto routes respondents to a question, labeled group, or page. After routing, the survey continues from that point and follows any page or group conditions thereafter. goto can be used as a tag, element decorator, or widget.
Syntax
goto tags are attached to the question or variable the condition is based off of, and multiple goto tags may be attached to a single variable. Single-line goto tags require an input of the label or question/table ID the respondent will be routed to, followed by the condition as a decorator, starting with an 'if' statement.
The goto widget accepts a question or table ID, page label, or group label. As an element decorator, the goto directive is executed if the option is selected.
Note that single-line definitions of goto with conditions cannot be used as standalone widgets.
# Tag (must be attached to variable/question/table)
goto: question ID, table ID, page label, or group label {if [condition]} # Element Decorator ... 1. Option {goto: question ID, table ID, page label, or group label} ...
# Widget
goto: question ID, table ID, page label, or group label
condition: condition logic here; optional
Tip! If complex logic is required for the goto condition - e.g., complex Perl statements - it is recommended to use the multi-line goto method.
Tags
| Tag | Description |
|---|---|
condition |
Evaluates a Boolean expression which must be true for the Note that the |
onload |
Executes goto on page load instead of page submission. |
Note: Although goto can be used to direct respondents to later questions, groups, pages, or chapters, the usage of conditioned groups and questions (e.g., applying showif) is preferred for respondent routing. Most instances of goto are for routing to system groups like "term" or "bad".
For additional information on using showif, see showif and skipif.
Note: Single question groups should be eliminated, and defined via the show if tag. The benefit here is a more compact source file, plus better system diagnostics and transparency as to the proper display and basing of questions.
Caution! If a respondent is routed to a group with a condition tag, the condition is ignored. If the conditioned group has page breaks within, the respondent will see subsequent pages inside the group only if the condition tag's input evaluates to 'true'.
Examples
Deferred termination
A common use case for goto is when using defer term. Deferred terminations can be "overridden" to terminate a respondent before they reach the defer term point by including goto: term as a tag or widget along with the appropriate condition.
In the below example, the survey is using defer term to terminate at the page labeled 'deferred'. But, we want to terminate respondents immediately if they are under 18 at QAGE. So, we add the goto: term widget, using the same condition as the termif tag.
Caution! In this scenario, it is important to write goto as a standalone widget, not as a tag on the question. If it's a tag, the respondent will not punch the disp variable upon terminating.
Tip! In general, when routing respondents to term pages, it is better to use termif instead of (e.g.) goto: term. The above example should only be used when exceptions to defer term are needed.
Confirmation loops
Confirmation loops can be used to verify the answers for previous questions and, if need be, redirect the respondent to a previous question/table in order to edit their prior response(s). In the below example, respondents who claim to have 20 or more cats and dogs will be shown QOVER20. If they verify that they did answer the previous questions correctly, they will be allowed to continue. Anyone that selects 'No' at QOVER20 will be routed back to QCATS to alter their responses on QCATS and/or QDOGS.
Using goto as an element decorator, we could simply specify to reroute the respondent to QCATS on the 'No' option.
As a standalone widget, we could define the goto widget and condition as follows:
The previous goto could also be written as a single-line definition, where the condition is defined in an if-statement in curly braces. Note that when defined in a single-line, goto must be attached to a question/variable:
Double confirmation loops
Double confirmation loops work similarly to single confirmation loops except they include a second verification question before routing the respondent back to previous question(s) to alter their responses. In the following example, two questions (QOVER20 and QCHANGE) are used to confirm the respondents previous responses to QCATS and QDOGS. Like the previous example, respondents are only shown these confirmation questions if they indicate having over 20 total cats and dogs, but in this case, they will be routed back to QCATS if they indicate their response was incorrect and that they would like to change their response. As such, a compound condition is required.
Comments
0 comments
Please sign in to leave a comment.