Adding further constraints to text outside of xforms

Thanks for all the work put into this project, I've been following it
for some time now and I hope that I'm finally able to use ODK in a
project and begin to contribute in some way.

I would like to know if any known ODK implementations have added in
further constraints on text that (from what I have gathered) would be
considered outside the realm of xform constraints? From what I have
read, xform bindings allow you to restrict based on data type (date),
skip logic (ask questions based on previous answers), making an entry
required, and/or range (between 10 and 20). What if you need to make
sure the text entered matches at least one string found in a database?

One scenario where this would be useful is a text field that allows
the user to enter in some data, and then the user presses a submit
button and that text is checked against a database of valid entries.
This would be useful for making sure text entered in a medication name
field matches one of the known medications, for example. Partial entry
of a medication's name would preferably allow the user to select the
correct medication out of a list of possible matches, but at least
notify the user that what was entered is invalid.

There are other scenarios I had in mind, but this covers most of it. I
would expect this scenario could only be possible by modifying the odk-
collect application (instead of the usual route of creating a new
xform document) and obviously providing the service that does the
database check. Is this above scenario something that has been
considered or is even something that ODK should be used for?

One of the benefits of ODK is that it provides a great way to collect
data in areas that may not have a dependable data connection. My above
scenario would depend on having a data connection at least in order to
get the full functionality, and beginning to depend on a data
connection may lead to either major changes/additions to ODK or an
entirely different project. Thanks for your suggestions and comments.

I thought I'd mention that in the following youtube video, there is
mention of an ODK project called DB:

The presenter describes the DB project as one that allows collecting
data from a database to populate a form, or to check against the newly
collected data to decide further action. This sounds like something
very similar to the scenario I described in the previous comment, but
I don't see any mention of this DB project in the current svn repo or
on the current project website. What has happened to the DB project?
it is mentioned in the above video starting at 13:25.

··· On May 23, 11:54 pm, Josh wrote: > Thanks for all the work put into this project, I've been following it > for some time now and I hope that I'm finally able to use ODK in a > project and begin to contribute in some way. > > I would like to know if any known ODK implementations have added in > further constraints on text that (from what I have gathered) would be > considered outside the realm of xform constraints? From what I have > read, xform bindings allow you to restrict based on data type (date), > skip logic (ask questions based on previous answers), making an entry > required, and/or range (between 10 and 20). What if you need to make > sure the text entered matches at least one string found in a database? > > One scenario where this would be useful is a text field that allows > the user to enter in some data, and then the user presses a submit > button and that text is checked against a database of valid entries. > This would be useful for making sure text entered in a medication name > field matches one of the known medications, for example. Partial entry > of a medication's name would preferably allow the user to select the > correct medication out of a list of possible matches, but at least > notify the user that what was entered is invalid. > > There are other scenarios I had in mind, but this covers most of it. I > would expect this scenario could only be possible by modifying the odk- > collect application (instead of the usual route of creating a new > xform document) and obviously providing the service that does the > database check. Is this above scenario something that has been > considered or is even something that ODK should be used for? > > One of the benefits of ODK is that it provides a great way to collect > data in areas that may not have a dependable data connection. My above > scenario would depend on having a data connection at least in order to > get the full functionality, and beginning to depend on a data > connection may lead to either major changes/additions to ODK or an > entirely different project. Thanks for your suggestions and comments.

hey josh,

ampath has code that does something like this database match. we are
working on a more generic framework that allows this (as described in
the video) but it's a few months away from release. if you are
building your own fork of collect, it's pretty easy to add a quick
hack to do it -- this is how we added regex support in earlier
versions of collect.

as to the scenario you describe, we generally recommend people don't
do that sort of free-text entry -- you get tons of mistakes. the
javarosa core supports itemsets and we are rolling that into odk
collect now. it should allow you to do dropdown lists where you have
data elements autocomplete from a list in the form.

both of these assume the list of names has offline support -- either
having the data in a local db or in the form itself. doing online
support is a little trickier but if you can certainly imagine the
local db being a cache of your online db and doing some background
syncing.

hope that helps,

yaw

··· On Sun, May 23, 2010 at 22:46, Josh wrote: > I thought I'd mention that in the following youtube video, there is > mention of an ODK project called DB: > http://www.youtube.com/watch?v=dskC7E6QESg > > The presenter describes the DB project as one that allows collecting > data from a database to populate a form, or to check against the newly > collected data to decide further action. This sounds like something > very similar to the scenario I described in the previous comment, but > I don't see any mention of this DB project in the current svn repo or > on the current project website. What has happened to the DB project? > it is mentioned in the above video starting at 13:25. > > On May 23, 11:54 pm, Josh wrote: >> Thanks for all the work put into this project, I've been following it >> for some time now and I hope that I'm finally able to use ODK in a >> project and begin to contribute in some way. >> >> I would like to know if any known ODK implementations have added in >> further constraints on text that (from what I have gathered) would be >> considered outside the realm of xform constraints? From what I have >> read, xform bindings allow you to restrict based on data type (date), >> skip logic (ask questions based on previous answers), making an entry >> required, and/or range (between 10 and 20). What if you need to make >> sure the text entered matches at least one string found in a database? >> >> One scenario where this would be useful is a text field that allows >> the user to enter in some data, and then the user presses a submit >> button and that text is checked against a database of valid entries. >> This would be useful for making sure text entered in a medication name >> field matches one of the known medications, for example. Partial entry >> of a medication's name would preferably allow the user to select the >> correct medication out of a list of possible matches, but at least >> notify the user that what was entered is invalid. >> >> There are other scenarios I had in mind, but this covers most of it. I >> would expect this scenario could only be possible by modifying the odk- >> collect application (instead of the usual route of creating a new >> xform document) and obviously providing the service that does the >> database check. Is this above scenario something that has been >> considered or is even something that ODK should be used for? >> >> One of the benefits of ODK is that it provides a great way to collect >> data in areas that may not have a dependable data connection. My above >> scenario would depend on having a data connection at least in order to >> get the full functionality, and beginning to depend on a data >> connection may lead to either major changes/additions to ODK or an >> entirely different project. Thanks for your suggestions and comments. >

Thanks for pointing me to ampath-odk, the functionality found in that
collect client is very similar to what I was hoping could be possible.
I agree about limiting (or better eliminating) free text entry as a
rule, and I'll continue to look into the options that will help avoid
this type of input. The autocompleting itemset provided by javarosa
may be exactly what I need. Thanks for the very helpful info! I'll
post more about how we are able to work with ODK if it is chosen for
our project.

··· On May 24, 10:17 pm, Yaw Anokwa wrote: > hey josh, > > ampath has code that does something like this database match. we are > working on a more generic framework that allows this (as described in > the video) but it's a few months away from release. if you are > building your own fork of collect, it's pretty easy to add a quick > hack to do it -- this is how we added regex support in earlier > versions of collect. > > as to the scenario you describe, we generally recommend people don't > do that sort of free-text entry -- you get tons of mistakes. the > javarosa core supports itemsets and we are rolling that into odk > collect now. it should allow you to do dropdown lists where you have > data elements autocomplete from a list in the form. > > both of these assume the list of names has offline support -- either > having the data in a local db or in the form itself. doing online > support is a little trickier but if you can certainly imagine the > local db being a cache of your online db and doing some background > syncing. > > hope that helps, > > yaw > > On Sun, May 23, 2010 at 22:46, Josh wrote: > > I thought I'd mention that in the following youtube video, there is > > mention of an ODK project called DB: > >http://www.youtube.com/watch?v=dskC7E6QESg > > > The presenter describes the DB project as one that allows collecting > > data from a database to populate a form, or to check against the newly > > collected data to decide further action. This sounds like something > > very similar to the scenario I described in the previous comment, but > > I don't see any mention of this DB project in the current svn repo or > > on the current project website. What has happened to the DB project? > > it is mentioned in the above video starting at 13:25. > > > On May 23, 11:54 pm, Josh wrote: > >> Thanks for all the work put into this project, I've been following it > >> for some time now and I hope that I'm finally able to use ODK in a > >> project and begin to contribute in some way. > > >> I would like to know if any known ODK implementations have added in > >> further constraints on text that (from what I have gathered) would be > >> considered outside the realm of xform constraints? From what I have > >> read, xform bindings allow you to restrict based on data type (date), > >> skip logic (ask questions based on previous answers), making an entry > >> required, and/or range (between 10 and 20). What if you need to make > >> sure the text entered matches at least one string found in a database? > > >> One scenario where this would be useful is a text field that allows > >> the user to enter in some data, and then the user presses a submit > >> button and that text is checked against a database of valid entries. > >> This would be useful for making sure text entered in a medication name > >> field matches one of the known medications, for example. Partial entry > >> of a medication's name would preferably allow the user to select the > >> correct medication out of a list of possible matches, but at least > >> notify the user that what was entered is invalid. > > >> There are other scenarios I had in mind, but this covers most of it. I > >> would expect this scenario could only be possible by modifying the odk- > >> collect application (instead of the usual route of creating a new > >> xform document) and obviously providing the service that does the > >> database check. Is this above scenario something that has been > >> considered or is even something that ODK should be used for? > > >> One of the benefits of ODK is that it provides a great way to collect > >> data in areas that may not have a dependable data connection. My above > >> scenario would depend on having a data connection at least in order to > >> get the full functionality, and beginning to depend on a data > >> connection may lead to either major changes/additions to ODK or an > >> entirely different project. Thanks for your suggestions and comments.

Hi ODK implementers,

I am from a team of a graduate students who are planning a large survey
(over 10,000 surveys in the course of a year) in southern India. We're still
deciding whether to use ODK and I have a few questions that hopefully those
with experience implementing this can help us out with.

  • Language support. We'll have the survey prepared in 4 languages (Kannada
    mainly, but also Hindi, Urdu, and English). I'm assuming script-based
    fonts, including Kannada (since it's supported by google) should be easy.
    Has anyone had experience using script-based languages on ODK, and also
    with switching through multiple languages when going from survey household
    to survey household? Is this easy to do or were there any challenges with
    it?

  • Timeline. We're 3 PhD students on a very limited budget who are pretty
    solid at overall surveying process (piloting, training, etc), but only one
    of has some programming experience (with all 3 willing to learn). How long,
    realistically, would it take us to do just the ODK part of the survey setup
    (assuming our survey itself is finished/piloted/field issues worked
    out/etc), including learning the systems, learning XForms/JavaRosa, learning
    how to making changes, inputting our survey, etc?

  • Privacy. How can we use ODKCollect in a manner that ensures privacy of
    the data? In a paper-based system we'd be using a numeric key to identify
    households and not have any identifying information attached to the data
    itself, and the surveys would be kept in a locked cabine, etc.. What would
    be the equivalent procedure for using ODK collect? Also, we'd like to be
    able to mark houses with GPS information and photos for easy recognition
    since we'll have a survey team re-visiting the same households; however, to
    protect privacy of households we'll need to keep GPS coordinates separate
    from the data itself (ie marked by a key kept securely elsewhere). Has
    anyone had experience with this and recommendations for ensuring security of
    the data?

  • QA/QC. Is there the ability to time how long it takes for an enumerator
    to get through certain questions or parts of the survey as a means of
    quality control on the data collection/entry process? Or what other methods
    have implementers used to ensure quality of data collection?

Thanks!
Emily

good set of questions, emily.

language support.

there are three levels of language support -- in the android operating
system itself, in the odk collect application, and in the form you are
using.

for android, you only have the popular languages available -- chinese,
dutch, english, french, japanese, etc (see
http://developer.android.com/sdk/android-2.2.html#locs for the full
list). pretty hard to add to that list and this is what controls the
language of the phone itself with no applications.

for odk collect, we currently have english, swahili, french, spanish,
and chinese translations. if you want to translate into more
languages, it's very easy to add more and this is what controls what
the buttons and dialog messages in odk collect say.

for the form, you can support any language that can be encoded as
unicode. you can translate individual questions or the entire form.
you toggle languages at any point in the survey. see
http://www.youtube.com/watch?v=lo8LaFFSkV8 (at 1:34). there is a catch
in that android has to have the font to display the script. i'm pretty
sure you should be fine, but if you have some sample text, i can try
it out for you.

timeline

neil and sam can speak on this a bit more, but with the community's
help and an understanding of xml, it shouldn't take you more than a
few hours to get a grasp of how to work with odk -- particularly the
format of the forms and workflow. if you have a more complex form with
logic, then it depends on how clever you are :). folks who have been
exposed to programming tend to grasp these things (loops, variable
assignment, etc.) much faster than civilians. we have sample forms at
http://code.google.com/p/opendatakit/source/browse?repo=forms.

privacy

you can have two forms per household. form 1 would have the gps
coordinates, photo and the household key, form 2 would have the
household key and the other data. results from both forms would have
to be stored on the sdcard of the phone, but in separate plaintext
files. once you send the files to the server or local machine, you can
delete them off the phone. there are countless ways to you can make
this process more secure (separate servers per form, encryption of the
sd card, etc) -- just depends what you consider secure and are willing
to build...

qa/qc

you can add time stamps at any point of the survey. you can even put
hidden location coordinates on each question if you so choose. neil
and sam can talk about quality control, but a lot of this is in how
you design the survey. limiting free text and using the logic to check
for ranges, etc.

hope that helps. keep the questions coming!

··· On Tue, May 25, 2010 at 15:13, Emily Kumpel wrote: > Hi ODK implementers, > I am from a team of a graduate students who are planning a large survey > (over 10,000 surveys in the course of a year) in southern India. We're still > deciding whether to use ODK and I have a few questions that hopefully those > with experience implementing this can help us out with. > - Language support. We'll have the survey prepared in 4 languages (Kannada > mainly, but also Hindi, Urdu, and English). I'm assuming script-based > fonts, including Kannada (since it's supported by google) should be easy. > Has anyone had experience using script-based languages on ODK, and also > with switching through multiple languages when going from survey household > to survey household? Is this easy to do or were there any challenges with > it? > - Timeline. We're 3 PhD students on a very limited budget who are pretty > solid at overall surveying process (piloting, training, etc), but only one > of has some programming experience (with all 3 willing to learn). How long, > realistically, would it take us to do just the ODK part of the survey setup > (assuming our survey itself is finished/piloted/field issues worked > out/etc), including learning the systems, learning XForms/JavaRosa, learning > how to making changes, inputting our survey, etc? > - Privacy. How can we use ODKCollect in a manner that ensures privacy of > the data? In a paper-based system we'd be using a numeric key to identify > households and not have any identifying information attached to the data > itself, and the surveys would be kept in a locked cabine, etc.. What would > be the equivalent procedure for using ODK collect? Also, we'd like to be > able to mark houses with GPS information and photos for easy recognition > since we'll have a survey team re-visiting the same households; however, to > protect privacy of households we'll need to keep GPS coordinates separate > from the data itself (ie marked by a key kept securely elsewhere). Has > anyone had experience with this and recommendations for ensuring security of > the data? > - QA/QC. Is there the ability to time how long it takes for an enumerator > to get through certain questions or parts of the survey as a means of > quality control on the data collection/entry process? Or what other methods > have implementers used to ensure quality of data collection? > Thanks! > Emily > > > > > > >