ODK Best Practices

(Abel Melquiades Callejo) #1


We all have different kinds and practices in implementing ODK. Please share stuffs like:

  1. What worked best for you?
  2. What are the things your learned the hard-way?
  3. Etc, something that can act as pointers for the community's sake

Looking forward to your epic responses :slight_smile:


My two cent:

  1. 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.

  2. 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.

(Abel Melquiades Callejo) #3

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...

  1. 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.

  2. 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.

  1. 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.

  2. 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?

(Abdoulaye Diallo) #5

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.

(Hélène Martin) #6

Really good thread, @Abel_Melquiades_Call, thanks for starting it!!

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:

(Abel Melquiades Callejo) #7

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.

(Jonathan Niles) #8

Hello All!

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.

Printing GPS co-ordinates+date/time on the picture