Odk

hi dorcas,

we try not to answer support questions through personal email. i'm
cc'ing the mailing list at opendatakit@googlegroups.com so others can
chime in.

(1) Branching - it seems like this is not yet functional on the website.
How have you gotten around this to use skip patterns?

odk supports very complex skip patterns -- complex enough to do
medical protocols.

if you are using odk build, you can do skip patterns using the
relevancy options. there is a reasonable tutorial at
https://bitbucket.org/javarosa/javarosa/wiki/buildxforms that
describes skip logic in xforms.

we designed odk build to support simple forms (not a lot of skip
patterns), so you may also find using something like
http://xls2xform.opendatakit.org (or http://xforms.dimagi.com or
http://code.google.com/p/purcforms/ or
http://formbuilder.koboproject.org) may work better (but may also be
harder to use).

(2) Aggregating data - we've had some difficulties with this. How have you
aggregated the data that has been collected, and do you have any tips for
making this process easier?

what exact difficulties are you having? perhaps you can be more
precise and write this up in a separate email to the list? if you can
describe what version you are using and the platform (app engine,
mysql, etc) that'd be great.

(3) The XLS2XForm Function - have you used it, and would you recommend it?

yup. i've used it. if you are comfortable in excel, it's a great way
to design forms. the other form designers i listed above are all
pretty good. take a look and see if what fits your needs.

(4) Quality control - I'm worried that quality control on ODK will be more
difficult than it is on paper surveys. How have you gotten around this, and
do you have any ODK-specific protocols that you've used for either
administering surveys or ensuring quality control?

you can do a lot more monitoring and evaluation on odk than you can on
paper. in general, i think putting contraints to ensure good response
ranges, making questions required, adding gps locations and timestamps
will help. you can also ask questions a slightly different way to see
if you get different answers that corroborate. other ideas you may
want to consider are in our training guides at
http://code.google.com/p/opendatakit/wiki/TrainingGuide

all that said, this is a survey design and management issue, and
nothing beats a random spot check of an enumerator's data. with odk
you can see the data as it comes in and you should be able to respond
in real time. we are working on techniques that could automatically
detect bad data, but no promises on when that will be ready...

hope that helps,

yaw