GuidedTrack | How to adapt your survey to the use of the `*back` arrow

How to adapt your survey to the use of the `*back` arrow🔗

You may wish to include a *back arrow option so that participants can revise previous answers. If you do this, please keep the following tips in mind.

If you want to update the progress bar, avoid using the automatic progress-bar-updating program.🔗

If you use a back arrow option in your survey, then if you are using the public progress bar program ("update progress bar - public"), the progress bar will still update when people progress backward through questions. Because of this, we recommend not using the public progress bar program. Instead of that, you could opt to use the following options:

You could manually set the progress throughout the program with literal values (e.g., *progress: 75%) or with variables (e.g., *progress: {somePercent}%).
If you have a large number of questions, you could use a modified version of the public progress bar program, as in the example below. In that scenario, you would need to manually set the specific progress amounts for the final few questions in the program (e.g., the final 10%).

Example of how to use a modified progress bar (so that participants' use of the back arrow doesn't make it look like the survey is more complete than it is):🔗

If you're using the back arrow setting in your program, then after each question throughout the early sections of the survey, you could have this line (which refers to the modified progress bar program linked above):

*program: update progress bar - modified

Let's say that a participant has a total of 50 questions to answer. For the final 5 questions you could set the progress manually like this:

*progress: 90%

*question: I find it easy to concentrate whenever I want to.
	*answers: agreementScale

*progress: 92%

*question: I have a craving to learn new things whenever I can
	*answers: agreementScale

*progress: 94% -- (and so on until progress reaches 100%)

In the example above, the "update progress bar - modified" program guarantees that the participant will see a maximum of 90% progress regardless of how many times they use the back arrow — until they reach the section where you have manually set the *progress bar (at which point the progress bar will update according to your manually-set percentages until the person finishes the program). This will prevent people from thinking that they have finished the program before they reach the last question.

When you wish to count how many times someone has selected a particular option, save each individual question as its own variable, then add up the different variables at the end of that section.🔗

Please see this section of the manual and this section of the Q&A site for further details.

Bad example: allowing participants to add to a coding variable repeatedly (if they return to previous questions via the back arrow)🔗

*settings:
	*back: yes

>> totalNumberOfAvailableSubjectsLiked = 0

*question: I like physics.
	Yes
	No

>> totalNumberOfAvailableSubjectsLiked = totalNumberOfAvailableSubjectsLiked + 1

*question: I like mathematics.
	Yes
	No

>> totalNumberOfAvailableSubjectsLiked = totalNumberOfAvailableSubjectsLiked + 1

In this example, if the user selects "no" to the first question and "yes" to the following one, then changes their mind about "physics" and returns to that question to click "yes," then their total score (for the variable totalNumberOfAvailableSubjectsLiked) will be 1 (from the first time they did the questions) + 2 (from the second time they went through the questions) — which will make it seem like they liked 3 subjects out of a possible total of 2 subject options.

Example of how to create summary variables after a series of questions:🔗

When using the back button, instead of adding to a variable after each question, you should save the individual variables and add them up at the end of the relevant section, like this:

*settings:
	*back: yes

>> answerScale = [["Yes", 1], ["No", 0]]

*question: I like physics.
	*answers: answerScale
	*save: likesPhysics

*question: I like mathematics.
	*answers: answerScale
	*save: likesMath

*question: I like history.
	*answers: answerScale
	*save: likesHistory

Then, at the end of the relevant section, you can create a summary variable using all the relevant component variables:

>> totalNumberOfAvailableSubjectsLiked = likesPhysics + likesMath + likesHistory
-- (+ any other questions that should contribute to this score)

If you use the `maintain` keyword, `maintain` a "space" character on the screens where you don't want a message to display.🔗

If you enable the back button and have a section with a *maintain keyword, participants will still see the banner containing the *maintain message if they navigate backwards to previous sections where the banner wasn't intended to be displayed. A simple solution to this is to put a *clear right before the last question of the previous section. For example:

*settings
	*back: yes

----------------------------------------------------------
-- The following section DOES NOT have a *maintain box. --
----------------------------------------------------------

*question: Which of these best describes the lonely goatherd?
	He was high on a hill.
	His voice was loud.

*question: Which of these is your favorite thing?
	Raindrops on roses
	Whiskers on kittens

-- Note the *clear keyword here:
*clear

*question: How do you solve a problem like Maria?
	Keep a wave upon the sand
	Hold a moonbeam in your hand

------------------------------------------------------
-- The following section DOES have a *maintain box. --
------------------------------------------------------

*maintain: I hope you're enjoying these questions about /The Sound of Music/!

*question: So long?
	Farewell
	Auf wiedersehen
	Goodbye

*question: Edelweiss is:
	small and bright
	clean and white

*clear

Next: How to design questions that avoid introducing response bias while being efficient and easy to answer

How to adapt your survey to the use of the *back arrow🔗