Improve data updating functionality when using back button.

[mitch-mitchel]

Use of the back button can cause problems, particularly if a user uses it in order to go back and change an answer to an earlier question in the Guided Pathway. CLEO can provide detailed examples.

[mitch-mitchel]

In testing and in our support inquiries, we’ve had reports of several issues when it comes to changing answers that will send users down different branches of the interviews.

This is an example of a typical branching structure. As noted, we tend to exclusively use fields (e.g. radio buttons, checkboxes, etc.) to aid with navigation, writing logic to direct users to the correct questions based on their selections, rather than using Buttons. We’ll use Continue buttons of course but will often have multiple logic conditions to navigate to questions other than the one set as the Continue button’s destination if the conditions are filled.
In these sorts of cases, we’ve found that issues arise if, after progressing through these questions, you go back and change one of your selections.
For example, if you select option A, proceed through Qs 2, 3, and 4, and then at Q 6, you use the Back button to go back to Q 1 and select Option C. Then at Q 5, you select option E. You will no longer see Qs 2, 3 or 4, but the variables in those questions will still be filled in. If the variables in those questions are mapped to a form being output by the interview, the fields on those forms will still be filled in, even if they’re now irrelevant based on the user’s corrected answers. The checkbox variables in Q3 may also be used for logic further down the pathway, which means the user may be directed to answer irrelevant questions and may skip a set of questions that they actually should answer.
Another example: If you select Option B, go to Qs 2 and 4, and then go back, you may end up seeing Q 3, which will no longer be skipped, because the Before logic won’t run if you navigate to a question via the Back button. The same is true with using the dropdown menu. And, if you navigate away from a question using Back, Next or the dropdown menu, the After logic won’t run either. This tends to happen if you go proceed backwards through a set of questions more than once.
What we’re hoping can be done is some special way of implementing prioritized strings of logic that will always run when you get to a question, regardless of how you arrive there. So, in question 1, we’d want logic which sets all the variables in Qs 2, 3, 4 and 5 to blank. And, in Q 3, the before logic would be set to always run, and would need to check if you are navigating to it via the back button, meaning it should bring you to Q 2 instead of Q 4.

[mitch-mitchel]

this could be solved with the 'always fire logic' option as well, would be author based and could cause unforseen issues as it breaks some social contracts of how navigation works (aka, revisted pages generally don't fire logic again)