Please add in odk collect
When we select 'ignore changes' in a form, it would be useful if there is a prompt that warns the user before going to the home page. The prompt can have the following warning:
'Are you sure you want to discard all entered data and return to home page'
Thanks for your reply
I am using ODK Collect V1.21.2
I want if I click ignore changes then show again new message
Are you sure you want to discard all entered data
but currently, ODK not asked
Thanks for the clarification, @azam_iqbal. Can you please describe what problems you have run into that lead to this request? It sounds like you have data collectors who tap the back button on their devices and lose data by ignoring changes. Is that because they don't understand the options made available to them or because they try to tap "Save" and miss? Is exiting part way through filling out a form a common part of their workflow or is the back button tap also a mistake? Is losing data this way something that data collectors do over and over again or that they do once and then learn not to do?
Saw the link to this with the hide ignore changes post and thought I'd follow up with our experience from the equivalent issue in ODK-X. In early versions we had enumerators both plain old hit the wrong button as well as not understand what ignore changes meant; adding a little confirm message of "Are you sure you want to exit and lose all changes?" was super helpful and solved both problems. No more data loss!
We noticed that trying to save progress with the two options of “save changes” and “ignore changes,” “ignore changes” deletes ALL the data, regardless of whether the assessor is half way through and wants to only ignore some changes, etc. In short, the option is just deleting all the data.
In the interim we’ve told all our assessors to just not use the option and only mark “saved changes.” We understand if you cannot remedy this overall but wanted to ask if it was possible.
So it sounds like it may be a misunderstanding of the functionality of the options.
Every year I have a case of loss of data on large forms that loop, today a form pointing to 70 trees over 1h30 of field work.
The user forgets to regularly save his input via the diskette button. (0 time)
And despite the automatic saving after each screen change, the user hastily exits ODK and presses canceled instead of saved.
I insist on these 2 points at the beginning of the campaign, but despite this I always have a beginner who is hurry, commits these two negligence! Then he thinks about doing it!
It could be interesting to save severals versions of "last-saved.xml" file (last-saved.xml01,...,last-saved.xml10), so that an IT managercan intervene on the equipment back in the office. ODK collect use only the last version but a humain could read / acces severals versions in order to rescue data.
Or it could be insteresting that after each group of a form (in order to aims large form), the save fonction writing in xml was launch, and form goes in Edition form.
Why not have 2 confirmations, it's always better, since everything can be lost.
However I think it would be canceled twice because they don't understand what is going on.
Why not keep a hard record of the form when exit even if cancelled is choose. Let it go in the trash or a temporary folder.
I use a form where there is a general definition of the place, then we collect (tip) the trees by georeferencing as well as a small questionnaire, or even information on a sample, so there are loops (group). This is a big form that can point 300 trees and can be open all morning or day.
So it is essential that the user uses the save button regularly, I recommend a save for each tree.
But I always have a case where the person doesn't do the backup, then due to a phone call or other manipulation outside of ODK, they do a wrong manipulation when they come back and I feel like they press cancel without reading anything because they are a bit lost when returning to ODK.
I think that the UI is well designed because you can save manually at any time, moreover if you don't save manually ODK offers to reload the data once, but if you read badly you lose everything. I tried without saving to take off the battery out of the phone, when opening the blank form it offers to reload the input. It's nice.
I think an additional option in the admin interface to check save after each screen? every 10 screens... every group (if there are loops in the form)?
Or to keep in a temporary folder a certain number of "unfinished" forms, we can intervene manually at worst.
From my point of view, the possibility of a forced save for each group (loop) would be a plus, because some forms with this choice of operation can become quite large and therefore contain a lot of collected data. (work time).
Reviving this thread because we have some upcoming work that intersects with this.
This is an interesting insight, thank you.
We agree that this behavior is not explained very well to the user currently and that it's easy to get confused and lose work. We are working on communicating better with the user that an automatic savepoint has been recovered. We'll share proposed mockups as we create them.
There is an old, undocumented feature called "save incomplete". I hesitate to mention this because the feature's design has issues but we have no immediate plans to replace it and won't remove it until we have an alternative. To use it, add an XLSForm column bind::saveIncomplete and put a value of true() in it for any question that you want to trigger a save. This save will overwrite the draft instance. If you put it on a question that is in a repeat, it will happen when the question is visited for each repeat instance.
I did not know this possibility, indeed I think it will be useful for my team that i integrate this option.
It's a very good idea to tag an autosave on a question, it helps to secure the loss of work on a form with repeat groups
After testing on the last question of a repeat group, this is exactly an option I wanted to have to limit losses. The form once the auto-save has been carried out is correctly placed in the "Edit a saved form" section.
I'm sure it will be used once or twice this year on large forms.