When a participant ends an experiment early, we would like to complete the upload for any in-progress recordings. This is not straightforward to implement because:
the obvious place to put this logic is when the users confirms that they want to end the study, but the pop-up messages asking the participant for confirmation before they leave the page are inconsistent, and
we either have to (a) complete the upload while the pop-up message is on the page, in which case the participant can cancel their exit action and continue with the experiment, or (b) try to complete the upload after they confirm the exit action, in which case the AWS request will not have much time to send and will be more likely to fail.
Description
If an in-progress video upload is not completed (or aborted) via a request sent to AWS, then the file parts are stored indefinitely but are not accessible, which is not ideal. It would be better if we could quickly mark any in-progress video recordings as 'completed' (or aborted) when the participant ends the experiment early. The main outcome is that there would be considerably fewer incomplete uploads in AWS. Also, if recordings are completed rather than aborted, then researchers would be able to see recordings that were saved up to the point when the participant ended the experiment early. This latter outcome is particularly useful when a participant completes the main part of an experiment but accidentally leaves the study early towards the end.
Inconsistent exit confirmation pop-ups
The experiment runner has a 'before unload' callback that should produce a pop-up confirmation box when the participant tries to leave the the page (by e.g. closing the browser tab or clicking the browser's 'back' button). Currently the experiment runner's behavior is inconsistent when a user leaves an in-progress experiment - sometimes they see the confirmation pop-ups, and sometimes not. It's not clear whether this inconsistency is caused by the EFP code or something inherent to the browser's before unload event.
Also, there are two separate confirmation pop-ups - one 'default' box that is produced by the browser and not modifiable, and a second one produced by the experiment runner that asks the participant whether they really want to exit the experiment early (in which case they're sent to the exit frame) or continue the study. It's not clear to me whether our custom pop-up box can be shown without also showing the browser's default pop-up first.
Browser's default pop-up. This will either keep the user on the page or complete their action (e.g. close the browser tab, navigate to the previous page).
Our custom confirmation pop-up. If the user selects "Stay on page" in the browser's default pop-up, then this one will appear. Continue = continue with the study, Exit = jump to the exit frame.
Deciding when to complete an in-progress recording
If we do decide to use the 'before unload' event to trigger the handing of in-progress recordings, we will need to decide whether to (1) complete/abort the recording when the pop-up is shown, or (2) only after the user confirms that they really want to leave the page (in response to the first/browser pop-up) or end the experiment early (in response to the second/custom pop-up).
If we complete/abort an in-progress recording when the first (browser default) confirmation pop-up is shown, then the AWS request will have more time to succeed. But at that point it's also possible for the user to cancel the exit action and continue the experiment, in which case we would need to start up a new recording. This will require some kind of event hook that can be triggered in the individual frames so that the frame handle the initiation of the new recording (including naming the file etc.).
If we complete/abort an in-progress recording after the user has confirmed that they want to exit the page (in the first/browser pop-up), then we will not need to handle the problems with re-starting recordings. But the request is more likely to fail because the page will close almost immediately when the user confirms their exit action. (This needs testing to confirm).
Handling in-progress recordings with our custom pop-up ("Really exit study?') is more straightforward, because the choice is to continue with the experiment or jump to the exit frame. In this case, we will not lose any data when the participant decides to end the study early, so we can wait for them to confirm that decision, and then handle the in-progress recording.
Summary
When a participant ends an experiment early, we would like to complete the upload for any in-progress recordings. This is not straightforward to implement because:
Description
If an in-progress video upload is not completed (or aborted) via a request sent to AWS, then the file parts are stored indefinitely but are not accessible, which is not ideal. It would be better if we could quickly mark any in-progress video recordings as 'completed' (or aborted) when the participant ends the experiment early. The main outcome is that there would be considerably fewer incomplete uploads in AWS. Also, if recordings are completed rather than aborted, then researchers would be able to see recordings that were saved up to the point when the participant ended the experiment early. This latter outcome is particularly useful when a participant completes the main part of an experiment but accidentally leaves the study early towards the end.
Inconsistent exit confirmation pop-ups
The experiment runner has a 'before unload' callback that should produce a pop-up confirmation box when the participant tries to leave the the page (by e.g. closing the browser tab or clicking the browser's 'back' button). Currently the experiment runner's behavior is inconsistent when a user leaves an in-progress experiment - sometimes they see the confirmation pop-ups, and sometimes not. It's not clear whether this inconsistency is caused by the EFP code or something inherent to the browser's before unload event.
Also, there are two separate confirmation pop-ups - one 'default' box that is produced by the browser and not modifiable, and a second one produced by the experiment runner that asks the participant whether they really want to exit the experiment early (in which case they're sent to the exit frame) or continue the study. It's not clear to me whether our custom pop-up box can be shown without also showing the browser's default pop-up first.
Browser's default pop-up. This will either keep the user on the page or complete their action (e.g. close the browser tab, navigate to the previous page).
Our custom confirmation pop-up. If the user selects "Stay on page" in the browser's default pop-up, then this one will appear. Continue = continue with the study, Exit = jump to the exit frame.
Deciding when to complete an in-progress recording
If we do decide to use the 'before unload' event to trigger the handing of in-progress recordings, we will need to decide whether to (1) complete/abort the recording when the pop-up is shown, or (2) only after the user confirms that they really want to leave the page (in response to the first/browser pop-up) or end the experiment early (in response to the second/custom pop-up).
If we complete/abort an in-progress recording when the first (browser default) confirmation pop-up is shown, then the AWS request will have more time to succeed. But at that point it's also possible for the user to cancel the exit action and continue the experiment, in which case we would need to start up a new recording. This will require some kind of event hook that can be triggered in the individual frames so that the frame handle the initiation of the new recording (including naming the file etc.).
If we complete/abort an in-progress recording after the user has confirmed that they want to exit the page (in the first/browser pop-up), then we will not need to handle the problems with re-starting recordings. But the request is more likely to fail because the page will close almost immediately when the user confirms their exit action. (This needs testing to confirm).
Handling in-progress recordings with our custom pop-up ("Really exit study?') is more straightforward, because the choice is to continue with the experiment or jump to the exit frame. In this case, we will not lose any data when the participant decides to end the study early, so we can wait for them to confirm that decision, and then handle the in-progress recording.