I have this idea. So I have 100 users in the field, and ODK central manages their forms automatically to the latest version present on the central server. There should be a list of app users which should contain the info that how many users are on the latest version of the form, and how many of them are using some older version (as most of the field work is understood to be offline). This way, we can try to communicate with the users which are not updated to the latest form version.
This is not what you asked for, but maybe it addresses the same problem: You could use managed QR codes to let user devices update forms to the latest versions.
A complication is that the same app user can be configured on multiple devices, each of them could have be out of band (and therefore out of form updates) for a different period. So you could see different form versions on the same app user. I have been bitten by devices yanked out of cold storage without notice or updates, then capturing data for long since deactivated forms (and servers) with a system time set to 2010.
Out of interest - how out of sync / offline / not updated would you expect your devices to be at the worst?
Yes, I am already doing this in my forms (You can find my response inside that thread as well). However, There is a critical understanding missing here.
By this way, I will get the form version value only when the user successfully submits some data from the field. If, for some reason, he does not send the data (perhaps using some older version of the form), I will not be knowing his problem, specifically that he is on the old version of the form.
My suggested feature is that, Central should keep track of which user has NOT downloaded the latest form version (or in other words, which user is on which version of the form). This list should appear somewhere in the form management actions, so that it is explicitly available for action. The action might be outside ODK eco-system (like, I know that the user is offline, else his app would have received the update automatically! So I would probably try to call him, or try to reach him through some other means, to instruct him to bring his phone online and let the form versions update themselves).
Thanks. Yes, I brainstormed about the exact same thing while thinking about a solution. You are right that we might be using one single user account on hundreds of phones, and hence the confusion. In fact, this is how I am doing, for a 100 people field survey, using one single user account and QR code (no time for creating 100 separate user accounts on the system), and they are differentiated by an ID question inside the form. However, my idea of unique ID of device is the use of DEVICEID field. Although it is editable, still no one usually gets into that detail of editing it without any solid reason. If Central would keep track of form versions against the DEVICEID, it might be more accurate than the user accounts.
About your last question: Actually we roll out program in phases. At the end of each phase, we analyze the collected data, and improve the form questions (add some new Q and remove some old ones). So in the next phase, we expect to receive the answers to the new form questionnaire. In this scenario, it becomes a big problem if/when you discover that few enumerators are still filling the old forms and sending the data against the retired form version (as it throws off the analysis of 2nd phase). I ran a pretty big sized data collection exercise (300k+ form submissions) pretty recently, and this issue popped up to cause a lot of confusion, as we discovered it very late (at the end of phase 2 actually, so there was no time for asking field staff to go back and re-do the old stuff).
I am coming across this again and again, whereby I need to know which user is on which form version, and/or whether their phone has downloaded the latest form version yet or not. Is there anything in the pipeline for this?
I am concerned about a use case where the device has not sent any data yet (so at the dashboard I have no knowledge which older form version is on their device). It becomes complex when field staff phone has a version 2 or 3 steps older (It's a very common thing in big/national-level remote area projects).
Another use case is the testing. They ask me to make changes to the form. I upload the new version of the form and inform them to upgrade their forms in the apps. But sometimes they keep insisting that their forms are not updated, and/or they again do the testing on the older version of the form without knowing that the form is not properly updated.
This certainly was a common issue before the match exactly form update mode. But it's not one we've heard about much recently. If others are experiencing similar problems, it would be good to hear from you about your context and what you've observed.
When I've worked in contexts where getting form updates are critical, I've put a reminder to update at the start of the form. For example:
Please make sure that you have gone online and tapped the refresh button on Fill Blank Form today
You could add additional information based on the barriers that data collectors face in your specific context. Do they forget to go out of airplane mode? Do they forget to buy credits?
You could also make it even stronger by having the first question be "Have you gone online and refreshed your blank forms this week? Y/N" That way you have a written record of what the data collector believes they have done in case of discrepancies.
If you know what kinds of barriers your data collectors are facing, you could share those experiences here and that might give more ideas for suggestions.
I understand the desire to see what versions are on each device. As I said in Using DEVICE ID more extensively on the Central dashboard, I think it's likely to be an area we explore at some point. However, I'm not convinced it would be the best solution to the problems you're experiencing. I think it's important to fully understand what's going wrong and to explore form design and training options as well.
Does your form definitions have big attachments? Have you told them what version string they should expect? Have they told you which one they see? Have they described exactly what they do to update? Maybe there is a bug or maybe the UI is not clear enough.
Please make sure that you have gone online and tapped the refresh button on Fill Blank Form today