Involving people early on and explain over and over again why using ODK. If you go to the field, use a child-protection app and have ODK Collect/Kobo Collect as the only accessible app to enumerators, as otherwise, battery drains by youtube and what not.
Test download of the form and uploading finalised forms. This is not an issue so much anymore. But that had hurt a lot in the field, when you had an upload error, and had to do all by hand.
That's great @arqaam! I looked at child-protection apps available and there's this app that could limit the user into using certain apps only. Really cool! That should help maximize battery power.
I have to agree on the testing part. Super heavy testing needs to be done before pushing a finalized e-form. Even though it can be exhaustingly boring but it has to be done. Publishing an e-form with a bug is so painful for everybody -- from end-users to people handling the back-end servers and database -- when dealing with regular expressions, etc.
Anyways, I forgot to put the obligatory example. So, here it is...
What really worked for us is the use of barcodes and barcode readers to easily identify things uniquely. We setup barcodes on the farm fields, and when we get to the fields, all we have to do is to fire up the ODK collect and scan the barcode. Now on the development of the form, this can be easily setup in XLSForm by setting barcode as the question type.
By the way, I am a back-end database person. What we learned the hard-way is that... e-form development has to be planned carefully. As much as possible:
DO NOT USE NESTED FIELD GROUPINGS as this result to possible wrong-spelled database table field names
Example: Group Acme > Group Capsule > Your Field Name becomes GRP_ACM_GROUP_CPSLE_YOUR_FLD_NAME in the database table field name. I don't know why it is happening.
DO NOT USE LONG NAMES FOR GROUPS AND FIELDS because long ones may also result to possible wrong-spelled database table field names
DO NOT USE LONG FORM NAMES because long ones may also result to possible wrong-spelled database table names
Example: My epic very long name form name becomes MY_EPC_VRY_LONG_NME_FORM_NAME_CORE in the database table name. I also don't know why it is happening.
In e-form development, make the e-form as minimal media upload as possible (image, audio,video) as they are heavy data for end-users that are on mobile. Images and video are also very heavy by default if the device's camera has a high default resolution.
In e-form development, be wary that e-form fields that have select_multiple create a new database table rather than a table field attached to the core table.
I hope some people would find it as a handy guide.
Hi @Abel_Melquiades_Call,
Regarding your #4, I am not sure what you mean. I think it's not "select_multiple" that creates a new database table, but whatever would be in a "begin repeat". And that would be rather logical, as a lot of times repeat is not pre-defined and therefore the main database would be screwed?
Hello, first thank you @Abel_Melquiades_Call for this topic.
I've not yet used ODK for long, but I've experienced two things.
I'ts easy to easy as starter but as you said it when you've many nested group your variable name become very long. Sometimes too, when I use relevance into group like it doesn't work until I put the "relevant question out the group.
Secondly when I want to use a table to fill multiple row for same question with begin repeat, when I retrieve data by Briefcase it separate it in two files with keys. it's the worst thing that i've seen in ODK.
There's some unexpected behavior in some of the posts that have come out that could be bugs. If you're not sure and you can't find an explanation for it, do post to support so we can dig into the code and see whether it's intentional or not.
Here are a few I'm thinking of:
Make sure to understand the paper form deeply and to verify it has no mistakes before digitizing it. It's not very useful to collect bad data faster!
Only include questions that are actually going to be analyzed. Because digital forms don't have a space limit, it's tempting to keep throwing in questions but that may just make analysis more burdensome and annoy the enumerators.
Hello @arqaam, maybe that is also the reason because we also used a begin-repeat style. However, I really think it should be because of the select_multiple for a reason that each selected value should be taken into account. Recording those values in a separate table makes a perfect sense to treat it that way.
Just chiming in to add: for additional audit-ability, use OpenCamera with a custom text, timestamp, and gps stamp embedded into the photo. For those stuck on older Collect versions, it also compresses photos to reduce bandwidth.