Hi all,

I am trying to add a "Back" button to the result page so that players can decide if they want to change their previous inputs after viewing the result. The ideal situation is that players can move back and forward several times until they confirm their final submissions.

So far by googling, I saw there was a post talking about adding a "Back" button with the bootstrap navigation header. However, I think that is used for instruction pages, which means it will only work when previous pages have no input field. Because I still want the input to be saved every time the player clicks the "Next" button, this method does not seem to work. So I am wondering if there is a way to create a "Back" button for "redo" purposes. (Here is the original post: https://groups.google.com/g/otree/c/0UvDG8mhhcs)

Thank you in advance!

Best,
Alan

Hi Alan -

Generally, oTree is a "forward-only" application.  You can't actually move backwards in the page_sequence.

If I were to try to emulate the functionality of a back button, I would add an additional hidden "redo" form field into my results page, with a default value of False.  Then I would add the "back" button as an input type="button" and have its onclick function set the value of "redo" to True before submitting the form.

Then in my page_sequence I would have several duplicates of the initial Input page and Results page (each with the same form_fields and template_names as the original pages) and use is_displayed to only show the Input2 and Results2 pages if redo==True.

That way, they only see the duplicate pages if they clicked the "back" button on the Results page - and they're skipped if they choose not to.

Thanks,
--Chris

Hi Chris,

Thanks! I think I got it. Just one more quick question: does that mean I need to create enough(many) duplicate pages to make sure they don't get depleted? I feel like that's slightly inefficient, so that's why I am asking. :)

Thanks!

Best,
Alan

Hi Alan -

Yes, that's what it means.

If it's a simple calculation you make (on a single-player decision) you may find it less inefficient to implement a "results calculator" in javascript on your original input page, and that way they can just use the calculator to get the results of their inputs on that page (as many times as they like) and then once they submit they're done.  That's another option.

Thanks,
--Chris