1. What is the issue? Please be detailed.
Selecting "Start new form" from the main menu of my project doesn't appear to always start a blank new form. If I was filling out the form previously, but had force closed ODK Collect without saving an instance of the form, starting a new form of the same type either takes me to the "Go To" prompt screen (if enabled), or directly to the place that I had previously left off in that same survey type.
Shouldn't starting a new form always open a blank form? Is there a setting to force this behavior?
2. What steps can we take to reproduce this issue?
Start a new form from the main menu in ODK Collect.
Navigate forward to a section other than the opening section of the form; this helps to easily demonstrate the behavior.
Before finalizing or submitting the form, force close ODK Collect.
Open ODK Collect, and select "Start new form", selecting the same form from Step #1.
The "Go To" prompt screen is presented, instead of the first section of a blank form of the same type.
3. What have you tried to fix the issue?
I've disabled moving backwards, which disabled the Go To prompt, and disabled both Draft settings. Nothing seems to either force a blank form to load, or discard the previous form's instance when ODK Collect is force closed.
4. Upload any forms or screenshots you can share publicly below.
None to share. You can reproduce this with the built in Demo project's forms.
Hi @KingBahb
When you get a chance, please introduce yourself here. I'd also encourage you to add a real picture as your avatar because it helps build community!
If during form-filling you kill the app or your device shutdowns the state of your form is saved and then restored when you start a new form next time. It has been working in this way since the beginning so nothing has changed. This is our way of protecting users from losing data.
If you force close the app to just quickly get rid of a form that you don't need then it might be annoying but this is not how you should use ODK Collect and as I said protecting users from losing data is important for us.
That's what I figured was going on. For me, being "new" to ODK / ODK Collect, I struggled with the labeling of the button that start's a new form. "New Form" means "pristine" or "blank" to me. Since ODK Collect has the ability to open instances of a survey, I was hoping that there was a feature to force a blank, new survey to be started.
Could a setting be added to ODK Collect to toggle this behavior? Something like Force Blank Forms on Start. It could default to "unchecked" (or off), but could be toggled on for projects that never want to preserve data on crashes / force closes.
It's definitely what we want to convey! But I can see the confusion in the recovery case. The recovery behavior you describe should happen very rarely. Did you identify it looking for edge cases or is it something you experienced unexpectedly?
We've long wanted to make what's going on more explicit but haven't had a chance to get to it yet. This issue has more details on the current behavior.
Can you please say more about why you wouldn't want recovery? Would something like a dialog explaining what happened and an opportunity to recover or dismiss meet your needs?
Our use case may help explain the "why" behind my initial post.
My team has written an Android app that interoperates with ODK Collect. We use exposed intents by ODK Collect to start new forms, and we use the "Launch" button in surveys to pull data out of our application to use within surveys. That said, we had an edge case during user observation testing that revealed that a user might force close our app (which is a container for ODK Collect), instead of using the Android native back buttons to "exit" ODK Collect, and return to our app. Then, when they relaunched our app, and opened the same survey via intents, the survey "Go To Prompt" would be presented to the user (which was confusing to the user). Even if we eliminate backwards navigation and the "Go To Prompt" via ODK Collect settings, the intent will open the survey at the "save point", which may not be the user experience that we want.
Hope that makes sense. We'd rather force the user to have to re-enter data from the start after an unexpected crash / closure occurs. I recognize that this is not the normal process flow, but it's what we were hoping to provide to our users. There's more to the rationale for this, but I'll stop boring y'all with this blabbering...
Aha! That makes so much sense, thank you. We're going to think about this case and see what we could do. I'm wondering whether maybe Collect should never recover from savepoint when the "start new form" activity is launched from an application other than Collect.
We have now made recovery from savepoint explicit and you can try this out in the latest beta. The user will see a dialog and be prompted to either continue from recovered data or discard it. I think this will improve your scenario -- your users will get information on what's going on and you'll be able to tell them to always discard.
We haven't yet added the intent extra but are considering it. Please let us know how important it feels given the time that has passed and the updates I've described above.
As far as adding a flag in the intent architecture to Discard / Recover any instance related to the form being edited by the intent, I still see value in that, but it could be a consideration for another day. Cheers!!
