Hi all!
I am implementing a household survey using ODK/SurveyCTO. It contains
different types of informations on household members (rosters in the
survey), implemented using repeat groups. That is, there is a repeat group
"Members names", followed by a repeat group "Members basic information"
(like age), and a repeat group "Members education". Each of these repeat
groups considers the same household members, so they are of the same length
and reference each other using indexed-repeat (the same line number in each
repeat group refers to the same household member)
My current implementations runs into trouble when a group instance is
deleted. Suppose an enumerator first enters two names (John and Sarah) in
the first repeat group and then enters their ages (10 and 20) in the second
repeat group. Now he realizes that John is not part of the household,
returns and deletes the group instance in "Members names" for John.
When he now goes to the repeat group "Members education" and starts filling
the first line the program pulls up the first line of the previous repeat
groups ("Sarah" from "members names"; and age 10 from "members ages"). So
he is combining information about different people and the survey starts
asking the wrong questions about the wrong people.
I think I understand what is happening. But I don't see a clean way to
solve the problem. Do you have any suggestions? Here are the (bad)
solutions I currently see:
- Insist that enumerators never-ever go back to a previous repeat group
and delete an instance (there is no way to disallow them to do so, right?)
- Put all the information which needs to be referenced later on in the
first repeat group. In my case this is however not really an option as the
survey is more complex than the example suggests and multiple repeat groups
are referencing each other in different places
Anyway, I was wondering if there was some kind of best-practice to deal
with multiple repeat groups which reference each other. Any help is much
appreciated!
Thanks!
Wouter
1 Like
Wouter,
You raise a very important issue with references across repeat groups.
To me, this seems like yet another reason to prefer avoiding the dynamic
repeat group UI (i.e., the "add another x?" UI). Could you structure your
survey to use repeat_count instead (e.g., by asking first how many
household members there are, then specifying that as the repeat_count)?
That approach has its own idiosyncrasies -- such as how it handles the case
where a user goes back and reduces the count -- but it seems, on the whole,
safer. At least sequencing can never get mixed up, and the logic of Collect
is designed to avoid any accidental data loss.
With the repeat_count approach, it's not at all easy to go back and remove
a household member from the middle -- but then you could provide explicit
support for such things in your survey, if you thought it important.
Another approach, of course, would be to just never teach enumerators how
to remove groups (a variation of your Option 1), and instead build in
explicit support for "deleting" a household member. The simplest system
would be: if you want to go back and remove a member, change his or her
name to "-111"; then you could deal with such cases carefully in your
back-end processing.
Best,
Chris
···
On Mon, Dec 9, 2013 at 1:08 PM, Wouter Gelade wrote:
Hi all!
I am implementing a household survey using ODK/SurveyCTO. It contains
different types of informations on household members (rosters in the
survey), implemented using repeat groups. That is, there is a repeat group
"Members names", followed by a repeat group "Members basic information"
(like age), and a repeat group "Members education". Each of these repeat
groups considers the same household members, so they are of the same length
and reference each other using indexed-repeat (the same line number in each
repeat group refers to the same household member)
My current implementations runs into trouble when a group instance is
deleted. Suppose an enumerator first enters two names (John and Sarah) in
the first repeat group and then enters their ages (10 and 20) in the second
repeat group. Now he realizes that John is not part of the household,
returns and deletes the group instance in "Members names" for John.
When he now goes to the repeat group "Members education" and starts
filling the first line the program pulls up the first line of the previous
repeat groups ("Sarah" from "members names"; and age 10 from "members
ages"). So he is combining information about different people and the
survey starts asking the wrong questions about the wrong people.
I think I understand what is happening. But I don't see a clean way to
solve the problem. Do you have any suggestions? Here are the (bad)
solutions I currently see:
- Insist that enumerators never-ever go back to a previous repeat group
and delete an instance (there is no way to disallow them to do so, right?)
- Put all the information which needs to be referenced later on in the
first repeat group. In my case this is however not really an option as the
survey is more complex than the example suggests and multiple repeat groups
are referencing each other in different places
Anyway, I was wondering if there was some kind of best-practice to deal
with multiple repeat groups which reference each other. Any help is much
appreciated!
Thanks!
Wouter
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Hi Wouter, I think you have a few options. You could combine the 3 repeats
into one larger repeat so the full record is deleted. You could create a
"soft delete" flag question in the first repeat and have users use that
instead of doing hard deletion, then use that flag as a relevance for later
repeats; or maybe use something else as a relevance to skip the later
repeats. Chris' idea is a fine one as well.
Jason
···
On Monday, December 9, 2013 1:55:47 PM UTC-5, Christopher Robert wrote:
>
> Wouter,
>
> You raise a very important issue with references across repeat groups.
>
> To me, this seems like yet another reason to prefer avoiding the dynamic
> repeat group UI (i.e., the "add another x?" UI). Could you structure your
> survey to use repeat_count instead (e.g., by asking first how many
> household members there are, then specifying that as the repeat_count)?
> That approach has its own idiosyncrasies -- such as how it handles the case
> where a user goes back and reduces the count -- but it seems, on the whole,
> safer. At least sequencing can never get mixed up, and the logic of Collect
> is designed to avoid any accidental data loss.
>
> With the repeat_count approach, it's not at all easy to go back and remove
> a household member from the middle -- but then you could provide explicit
> support for such things in your survey, if you thought it important.
>
> Another approach, of course, would be to just never teach enumerators how
> to remove groups (a variation of your Option 1), and instead build in
> explicit support for "deleting" a household member. The simplest system
> would be: if you want to go back and remove a member, change his or her
> name to "-111"; then you could deal with such cases carefully in your
> back-end processing.
>
> Best,
>
> Chris
>
>
>
> On Mon, Dec 9, 2013 at 1:08 PM, Wouter Gelade <wouter...@gmail.com wrote:
>
>> Hi all!
>>
>> I am implementing a household survey using ODK/SurveyCTO. It contains
>> different types of informations on household members (rosters in the
>> survey), implemented using repeat groups. That is, there is a repeat group
>> "Members names", followed by a repeat group "Members basic information"
>> (like age), and a repeat group "Members education". Each of these repeat
>> groups considers the same household members, so they are of the same length
>> and reference each other using indexed-repeat (the same line number in each
>> repeat group refers to the same household member)
>>
>> My current implementations runs into trouble when a group instance is
>> deleted. Suppose an enumerator first enters two names (John and Sarah) in
>> the first repeat group and then enters their ages (10 and 20) in the second
>> repeat group. Now he realizes that John is not part of the household,
>> returns and deletes the group instance in "Members names" for John.
>>
>> When he now goes to the repeat group "Members education" and starts
>> filling the first line the program pulls up the first line of the previous
>> repeat groups ("Sarah" from "members names"; and age 10 from "members
>> ages"). So he is combining information about different people and the
>> survey starts asking the wrong questions about the wrong people.
>>
>> I think I understand what is happening. But I don't see a clean way to
>> solve the problem. Do you have any suggestions? Here are the (bad)
>> solutions I currently see:
>>
>> 1) Insist that enumerators never-ever go back to a previous repeat group
>> and delete an instance (there is no way to disallow them to do so, right?)
>> 2) Put all the information which needs to be referenced later on in the
>> first repeat group. In my case this is however not really an option as the
>> survey is more complex than the example suggests and multiple repeat groups
>> are referencing each other in different places
>>
>> Anyway, I was wondering if there was some kind of best-practice to deal
>> with multiple repeat groups which reference each other. Any help is much
>> appreciated!
>>
>> Thanks!
>> Wouter
>>
>> --
>> --
>> Post: opend...@googlegroups.com
>> Unsubscribe: opendatakit...@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ODK Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to opendatakit...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
Hi Jason and Chris,
Thanks for your replies. Unfortunately the easy solutions are not possible:
asking for the number of people (too many people in the household) and
putting all questions in one repeat group (too many questions on very
different topics).
I'll go for the soft-delete flag together with relevance. Additionally, I
think I will pull all the necessary information of the first dynamics
repeat group into the second repeat_count group and reference this second
repeat_count group in the rest of the questionnaire. While enumerators will
not be able to see consequences of changes in the first group (e.g.,
changing the name), it feels somewhat safer to me.
Thanks again,
Wouter
···
On Tuesday, December 10, 2013 3:02:09 PM UTC+1, Jason Ives wrote:
>
> Hi Wouter, I think you have a few options. You could combine the 3
> repeats into one larger repeat so the full record is deleted. You could
> create a "soft delete" flag question in the first repeat and have users use
> that instead of doing hard deletion, then use that flag as a relevance for
> later repeats; or maybe use something else as a relevance to skip the later
> repeats. Chris' idea is a fine one as well.
>
> Jason
>
> On Monday, December 9, 2013 1:55:47 PM UTC-5, Christopher Robert wrote:
>>
>> Wouter,
>>
>> You raise a very important issue with references across repeat groups.
>>
>> To me, this seems like yet another reason to prefer avoiding the dynamic
>> repeat group UI (i.e., the "add another x?" UI). Could you structure your
>> survey to use repeat_count instead (e.g., by asking first how many
>> household members there are, then specifying that as the repeat_count)?
>> That approach has its own idiosyncrasies -- such as how it handles the case
>> where a user goes back and reduces the count -- but it seems, on the whole,
>> safer. At least sequencing can never get mixed up, and the logic of Collect
>> is designed to avoid any accidental data loss.
>>
>> With the repeat_count approach, it's not at all easy to go back and
>> remove a household member from the middle -- but then you could provide
>> explicit support for such things in your survey, if you thought it
>> important.
>>
>> Another approach, of course, would be to just never teach enumerators how
>> to remove groups (a variation of your Option 1), and instead build in
>> explicit support for "deleting" a household member. The simplest system
>> would be: if you want to go back and remove a member, change his or her
>> name to "-111"; then you could deal with such cases carefully in your
>> back-end processing.
>>
>> Best,
>>
>> Chris
>>
>>
>>
>> On Mon, Dec 9, 2013 at 1:08 PM, Wouter Gelade wrote:
>>
>>> Hi all!
>>>
>>> I am implementing a household survey using ODK/SurveyCTO. It contains
>>> different types of informations on household members (rosters in the
>>> survey), implemented using repeat groups. That is, there is a repeat group
>>> "Members names", followed by a repeat group "Members basic information"
>>> (like age), and a repeat group "Members education". Each of these repeat
>>> groups considers the same household members, so they are of the same length
>>> and reference each other using indexed-repeat (the same line number in each
>>> repeat group refers to the same household member)
>>>
>>> My current implementations runs into trouble when a group instance is
>>> deleted. Suppose an enumerator first enters two names (John and Sarah) in
>>> the first repeat group and then enters their ages (10 and 20) in the second
>>> repeat group. Now he realizes that John is not part of the household,
>>> returns and deletes the group instance in "Members names" for John.
>>>
>>> When he now goes to the repeat group "Members education" and starts
>>> filling the first line the program pulls up the first line of the previous
>>> repeat groups ("Sarah" from "members names"; and age 10 from "members
>>> ages"). So he is combining information about different people and the
>>> survey starts asking the wrong questions about the wrong people.
>>>
>>> I think I understand what is happening. But I don't see a clean way to
>>> solve the problem. Do you have any suggestions? Here are the (bad)
>>> solutions I currently see:
>>>
>>> 1) Insist that enumerators never-ever go back to a previous repeat group
>>> and delete an instance (there is no way to disallow them to do so, right?)
>>> 2) Put all the information which needs to be referenced later on in the
>>> first repeat group. In my case this is however not really an option as the
>>> survey is more complex than the example suggests and multiple repeat groups
>>> are referencing each other in different places
>>>
>>> Anyway, I was wondering if there was some kind of best-practice to deal
>>> with multiple repeat groups which reference each other. Any help is much
>>> appreciated!
>>>
>>> Thanks!
>>> Wouter
>>>
>>> --
>>> --
>>> Post: opend...@googlegroups.com
>>> Unsubscribe: opendatakit...@googlegroups.com
>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ODK Community" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to opendatakit...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>