Randomizing select and select1 options

Hi,

We're working on a new Enketo feature to randomize select and select1
options. I imagine this would be interesting for ODK Collect as well at
some point in the future, or maybe somebody has already done it.

The proposed syntax is to add appearance="random" to a select or select1
question.

The proposed behaviour is:

  • randomize displayed options upon form loading, including when loading
    an existing record for editing
  • values in a (multiple) select are stored in the XML document order
    (i.e. same as without appearance="random")

Any feedback would be welcome, in particular to avoid future unnecessary
incompatibilities with ODK Collect and ODK Collect-based tools.

Thanks,
Martijn

1 Like

Great idea!

However, you know that it is technically possible to randomize order using
cascading-select filters, right? Basically, you repeat your choice set x
times, in x orders, with filters set to just show one group. The advantage
of using that is (a) you have a lot of flexibility to define the
randomization scheme (e.g., weighting orderings as you wish), (b) you can
easily remember what order was shown and the random draw used, depending on
how you code it, and (c) this method of randomizing choices is basically
parallel to how you randomize field order (by repeating and selectively
showing). We have a sample form that demonstrates these kinds of techniques
for our users.

The big disadvantage of this method, of course, is that it's laborious.

But, I guess I'd suggest that being able to weight the probabilities is
pretty important, and the ability to record the randomized order is even
more important. So you'd want to accommodate those requirements into any
new, more-convenient randomization support. You might also face immediate
pressure to, e.g., be able to always have "other", "don't know", or
whatever else as the last options, only randomizing the first x choices.
This is also something you can do with the existing cascading-select
approach, but which might be hard using a single appearance the way you're
describing.

Easier randomization options for both choices and fields would be very much
welcomed by users, but I do think it's a bit of a big project with a pretty
slippery slope...

Best,

Chris

ยทยทยท On Tue, Apr 5, 2016 at 12:24 PM Martijn van de Rijdt wrote:

Hi,

We're working on a new Enketo feature to randomize select and select1
options. I imagine this would be interesting for ODK Collect as well at
some point in the future, or maybe somebody has already done it.

The proposed syntax is to add appearance="random" to a select or
select1 question.

The proposed behaviour is:

  • randomize displayed options upon form loading, including when
    loading an existing record for editing
  • values in a (multiple) select are stored in the XML document order
    (i.e. same as without appearance="random")

Any feedback would be welcome, in particular to avoid future unnecessary
incompatibilities with ODK Collect and ODK Collect-based tools.

Thanks,
Martijn

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thanks Chris!

I'd suggest that being able to weight the probabilities is pretty

important, and the ability to record the randomized order

It sounds like you have a specific real-life use-case in mind where those 2
pieces of information are crucial, or maybe we're talking about subtly
different things. However, this feature will cater to those use cases where
the form designer simply wants to order select options randomly, and
doesn't require anything else.

You might also face immediate pressure to, e.g., be able to always have

"other", "don't know", or whatever else as the last options, only
randomizing the first x choices.

Yes, that may happen. I don't think that can be supported in a sane manner,
but who knows we may find a clever way to add that in the future. It would
be great if we could.

Best regards,
Martijn

ยทยทยท On Tue, Apr 5, 2016 at 11:10 AM, Christopher Robert wrote:

Great idea!

However, you know that it is technically possible to randomize order using
cascading-select filters, right? Basically, you repeat your choice set x
times, in x orders, with filters set to just show one group. The advantage
of using that is (a) you have a lot of flexibility to define the
randomization scheme (e.g., weighting orderings as you wish), (b) you can
easily remember what order was shown and the random draw used, depending on
how you code it, and (c) this method of randomizing choices is basically
parallel to how you randomize field order (by repeating and selectively
showing). We have a sample form that demonstrates these kinds of techniques
for our users.

The big disadvantage of this method, of course, is that it's laborious.

But, I guess I'd suggest that being able to weight the probabilities is
pretty important, and the ability to record the randomized order is even
more important. So you'd want to accommodate those requirements into any
new, more-convenient randomization support. You might also face immediate
pressure to, e.g., be able to always have "other", "don't know", or
whatever else as the last options, only randomizing the first x choices.
This is also something you can do with the existing cascading-select
approach, but which might be hard using a single appearance the way you're
describing.

Easier randomization options for both choices and fields would be very
much welcomed by users, but I do think it's a bit of a big project with a
pretty slippery slope...

Best,

Chris

On Tue, Apr 5, 2016 at 12:24 PM Martijn van de Rijdt martijn@enketo.org wrote:

Hi,

We're working on a new Enketo feature to randomize select and select1
options. I imagine this would be interesting for ODK Collect as well at
some point in the future, or maybe somebody has already done it.

The proposed syntax is to add appearance="random" to a select or
select1 question.

The proposed behaviour is:

  • randomize displayed options upon form loading, including when
    loading an existing record for editing
  • values in a (multiple) select are stored in the XML document order
    (i.e. same as without appearance="random")

Any feedback would be welcome, in particular to avoid future unnecessary
incompatibilities with ODK Collect and ODK Collect-based tools.

Thanks,
Martijn

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

Hi Martijn,

Yes, sorry, I meant to be talking about the order. In terms of real-life
use cases, doesn't pretty much anybody who randomizes the order of
something want to keep a record of which order applied for each submission?
Without that, you wouldn't be able to detect or analyze any question- or
option-order effect that might be present.

Alternatively, without recording the order, you wouldn't be able to audit
the sanctity of the randomization process. We've had lots of people pretty
distrustful about the randomness of randomization, so they're always
wanting a lot of visibility into the empirical distribution.

I guess all of these are concerns that researchers in particular have.
Practitioners may not care about whether there were or weren't option-order
effects, and they may just be happy to trust that the random distribution
was uniform (or "proper" in some general sense). So for practitioners maybe
you're right that something simple and non-transparent would be enough..!

Best,

Chris

P.S. You know that I won't object to this use of the "appearance" attribute
since I love using those appearances for all kinds of things!

P.P.S. Would the next logical step be supporting this appearance for
groups, for ordering questions?

ยทยทยท On Tue, Apr 5, 2016 at 7:08 PM Martijn van de Rijdt wrote:

Thanks Chris!

I'd suggest that being able to weight the probabilities is pretty

important, and the ability to record the randomized order

It sounds like you have a specific real-life use-case in mind where those
2 pieces of information are crucial, or maybe we're talking about subtly
different things. However, this feature will cater to those use cases where
the form designer simply wants to order select options randomly, and
doesn't require anything else.

You might also face immediate pressure to, e.g., be able to always have

"other", "don't know", or whatever else as the last options, only
randomizing the first x choices.

Yes, that may happen. I don't think that can be supported in a sane
manner, but who knows we may find a clever way to add that in the future.
It would be great if we could.

Best regards,
Martijn

On Tue, Apr 5, 2016 at 11:10 AM, Christopher Robert <crobert@surveycto.com wrote:

Great idea!

However, you know that it is technically possible to randomize order
using cascading-select filters, right? Basically, you repeat your choice
set x times, in x orders, with filters set to just show one group. The
advantage of using that is (a) you have a lot of flexibility to define the
randomization scheme (e.g., weighting orderings as you wish), (b) you can
easily remember what order was shown and the random draw used, depending on
how you code it, and (c) this method of randomizing choices is basically
parallel to how you randomize field order (by repeating and selectively
showing). We have a sample form that demonstrates these kinds of techniques
for our users.

The big disadvantage of this method, of course, is that it's laborious.

But, I guess I'd suggest that being able to weight the probabilities is
pretty important, and the ability to record the randomized order is even
more important. So you'd want to accommodate those requirements into any
new, more-convenient randomization support. You might also face immediate
pressure to, e.g., be able to always have "other", "don't know", or
whatever else as the last options, only randomizing the first x choices.
This is also something you can do with the existing cascading-select
approach, but which might be hard using a single appearance the way you're
describing.

Easier randomization options for both choices and fields would be very
much welcomed by users, but I do think it's a bit of a big project with a
pretty slippery slope...

Best,

Chris

On Tue, Apr 5, 2016 at 12:24 PM Martijn van de Rijdt martijn@enketo.org wrote:

Hi,

We're working on a new Enketo feature to randomize select and select1
options. I imagine this would be interesting for ODK Collect as well at
some point in the future, or maybe somebody has already done it.

The proposed syntax is to add appearance="random" to a select or
select1 question.

The proposed behaviour is:

  • randomize displayed options upon form loading, including when
    loading an existing record for editing
  • values in a (multiple) select are stored in the XML document order
    (i.e. same as without appearance="random")

Any feedback would be welcome, in particular to avoid future unnecessary
incompatibilities with ODK Collect and ODK Collect-based tools.

Thanks,
Martijn

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

doesn't pretty much anybody ... want

I agree with your own answer to this question re. the type of users. With
the current proposal I don't think there is a path towards recording the
randomized list.

P.P.S. Would the next logical step be supporting this appearance for

groups, for ordering questions?

Yes, and maybe for the form as a whole. I look forward to discussing that
in the future. Very difficult, I think.

P.S. You know that I won't object to this use of the "appearance" attribute

since I love using those appearances for all kinds of things!

Haha. I know that indeed. :slight_smile: And as you know, I am prone to objecting to
and not supporting the abuse of appearances... The use of appearance for
this is actually a concern about this proposal that I was really interested
in getting feedback on in this forum. I think it's either borderline
acceptable or not acceptable. We want to do this properly and are not very
much in a hurry (as the client we're developing this for can just use a
temporary (appearance) solution that doesn't ever have to be merged into
master).

I think there are 3 ways of doing this: appearance, xpath function, or a
new attribute. To me they all seem equally easy to implement in Enketo but
some require multiple tools (Validate, XLSForm) to be updated.

XPath function option:

Just adds a new randomize() function with a nodeset argument, to be used in
itemsets like this
<itemset nodeset="randomize(instance('cities')/root/item[country='india'])"

  • elegant, and probably fewest doubts about deviation from XForms
  • maybe there is a way to record the whole randomized list (in the future)
  • select (multiple) order of the values will not be document order (I
    think technically that's totally fine for itemsets, but am not sure if some
    servers would have a problem with this for export and analysis)
  • requires ODK Validate support
  • won't work with regular select and select1 so we would need to create a
    shortcut in PyxForm (e.g. types random_select_one and
    random_select_multiple) that forces an itemset output and wraps the
    predicate with this function

appearance:

  • no need for ODK Validate or PyxForm changes
  • could be used on all select and select1 questions (not just those with
    itemsets)
  • abuse of appearance attribute?
  • no path towards also recording the random order

new random attribute:

  • creating new attributes should be a last resort imo, probably not
    necessary here

Looking forward to hearing your opinions about the best way to implement
this, if this is something you'd like to see implemented in ODK Collect one
day.

Martijn

ยทยทยท On Tuesday, April 5, 2016 at 5:28:52 PM UTC-6, Christopher Robert wrote: > > Hi Martijn, > > Yes, sorry, I meant to be talking about the order. In terms of real-life > use cases, doesn't pretty much anybody who randomizes the order of > something want to keep a record of which order applied for each submission? > Without that, you wouldn't be able to detect or analyze any question- or > option-order effect that might be present. > > Alternatively, without recording the order, you wouldn't be able to audit > the sanctity of the randomization process. We've had lots of people pretty > distrustful about the randomness of randomization, so they're always > wanting a lot of visibility into the empirical distribution. > > I guess all of these are concerns that researchers in particular have. > Practitioners may not care about whether there were or weren't option-order > effects, and they may just be happy to trust that the random distribution > was uniform (or "proper" in some general sense). So for practitioners maybe > you're right that something simple and non-transparent would be enough..! > > Best, > > Chris > > P.S. You know that I won't object to this use of the "appearance" > attribute since I love using those appearances for all kinds of things! > > P.P.S. Would the next logical step be supporting this appearance for > groups, for ordering questions? > > On Tue, Apr 5, 2016 at 7:08 PM Martijn van de Rijdt <mar...@enketo.org > wrote: > >> Thanks Chris! >> >> I'd suggest that being able to weight the probabilities is pretty >>> important, and the ability to record the randomized order >> >> >> It sounds like you have a specific real-life use-case in mind where those >> 2 pieces of information are crucial, or maybe we're talking about subtly >> different things. However, this feature will cater to those use cases where >> the form designer simply wants *to order* select options randomly, and >> doesn't require anything else. >> >> You might also face immediate pressure to, e.g., be able to always have >>> "other", "don't know", or whatever else as the last options, only >>> randomizing the first x choices. >>> >> >> Yes, that may happen. I don't think that can be supported in a sane >> manner, but who knows we may find a clever way to add that in the future. >> It would be great if we could. >> >> Best regards, >> Martijn >> >> On Tue, Apr 5, 2016 at 11:10 AM, Christopher Robert <cro...@surveycto.com > wrote: >> >>> Great idea! >>> >>> However, you know that it is technically possible to randomize order >>> using cascading-select filters, right? Basically, you repeat your choice >>> set x times, in x orders, with filters set to just show one group. The >>> advantage of using that is (a) you have a lot of flexibility to define the >>> randomization scheme (e.g., weighting orderings as you wish), (b) you can >>> easily remember what order was shown and the random draw used, depending on >>> how you code it, and (c) this method of randomizing choices is basically >>> parallel to how you randomize field order (by repeating and selectively >>> showing). We have a sample form that demonstrates these kinds of techniques >>> for our users. >>> >>> The big disadvantage of this method, of course, is that it's laborious. >>> >>> But, I guess I'd suggest that being able to weight the probabilities is >>> pretty important, and the ability to record the randomized order is even >>> more important. So you'd want to accommodate those requirements into any >>> new, more-convenient randomization support. You might also face immediate >>> pressure to, e.g., be able to always have "other", "don't know", or >>> whatever else as the last options, only randomizing the first x choices. >>> This is also something you can do with the existing cascading-select >>> approach, but which might be hard using a single appearance the way you're >>> describing. >>> >>> Easier randomization options for both choices and fields would be very >>> much welcomed by users, but I do think it's a bit of a big project with a >>> pretty slippery slope... >>> >>> Best, >>> >>> Chris >>> >>> On Tue, Apr 5, 2016 at 12:24 PM Martijn van de Rijdt <mar...@enketo.org > wrote: >>> >>>> Hi, >>>> >>>> We're working on a new Enketo feature to randomize select and select1 >>>> options. I imagine this would be interesting for ODK Collect as well at >>>> some point in the future, or maybe somebody has already done it. >>>> >>>> The proposed syntax is to add *appearance="random"* to a select or >>>> select1 question. >>>> >>>> The proposed behaviour is: >>>> >>>> - randomize displayed options upon form loading, including when >>>> loading an existing record for editing >>>> - values in a (multiple) select are stored in the XML document >>>> order (i.e. same as without appearance="random") >>>> >>>> Any feedback would be welcome, in particular to avoid future >>>> unnecessary incompatibilities with ODK Collect and ODK Collect-based tools. >>>> >>>> Thanks, >>>> Martijn >>>> >>>> -- >>>> *Revolutionizing data collection since 2012.* >>>> >>>> Enketo | LinkedIn >>>> | GitHub >>>> | Twitter >>>> | Blog >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ODK Developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to opendatakit-developers+unsubscribe@googlegroups.com >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "ODK Developers" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> opendatakit-developers+unsubscribe@googlegroups.com . >> >> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> *Revolutionizing data collection since 2012.* >> >> Enketo | LinkedIn >> | GitHub >> | Twitter >> | Blog >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> >

Hi Martijn,

We have implemented this randomization of options within our own fork of
ODK Collect and we wouldn't mind contributing it back to the ODK Repo.
Some points regarding our implementation:

  1. We did not need to record the sequence of options shown to the user. The
    only requirement was to randomize the options so that there is no bias on
    the part of the user to make a choice. In fact, the way the widget works is
    that every time you swipe to the same question, it shows a different order
    of options, even when an answer has already been selected.
  2. We used a separate attribute called 'random' to make it work. Of course,
    given the +/- points you have listed, it seems that going the attribute way
    seems to be the best.
  3. All options are indeed randomized, so if we have 'other', 'none' etc.
    they will not be put at the bottom.

Chris, what you say is interesting, regarding randomizing using
cascading-select. But I didn't get how this will work. Can you explain? Or
maybe, just send me a link to the sample form you were mentioning and I
could try that out.

Thanks,
Raghu

Hi Raghu,

Attached is an old sample form of ours that demonstrates the basic
technique: you repeat your choices x times, in x different orderings, and
then you use a choice filter to only show the randomly-selected ordering.
It's laborious in that it requires a bunch of permutations, but you can do
something similar with a pre-loaded .csv file and it can be pretty quick
and easy once you're familiar with the technique.

I'm still having a hard time figuring out how many of our potential users
might see value in a simpler method, provided that they can't know what the
order was ex post.

One implementation approach could store the ordering somehow in the data. I
suppose that that approach could work whether it was an attribute or an
appearance, but then an appearance would seem less suitable (since the
response data would be encoded differently). If the response data were
changing format somehow, an attribute or even a different field type would
seem in order (pun intended).

Best,

Chris

SampleRandomizedChoiceForm.xlsx (52.9 KB)

ยทยทยท On Thu, Apr 7, 2016 at 8:31 AM Raghu Mittal wrote:

Hi Martijn,

We have implemented this randomization of options within our own fork of
ODK Collect and we wouldn't mind contributing it back to the ODK Repo.
Some points regarding our implementation:

  1. We did not need to record the sequence of options shown to the user.
    The only requirement was to randomize the options so that there is no bias
    on the part of the user to make a choice. In fact, the way the widget works
    is that every time you swipe to the same question, it shows a different
    order of options, even when an answer has already been selected.
  2. We used a separate attribute called 'random' to make it work. Of
    course, given the +/- points you have listed, it seems that going the
    attribute way seems to be the best.
  3. All options are indeed randomized, so if we have 'other', 'none' etc.
    they will not be put at the bottom.

Chris, what you say is interesting, regarding randomizing using
cascading-select. But I didn't get how this will work. Can you explain? Or
maybe, just send me a link to the sample form you were mentioning and I
could try that out.

Thanks,
Raghu

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Raghu,

Thanks for sharing that! Great to hear this is working in your port. Can
you share the XForm syntax you are supporting?

Cheers,
Martijn

ยทยทยท On Thursday, April 7, 2016 at 9:23:17 PM UTC-6, Christopher Robert wrote: > > Hi Raghu, > > Attached is an old sample form of ours that demonstrates the basic > technique: you repeat your choices x times, in x different orderings, and > then you use a choice filter to only show the randomly-selected ordering. > It's laborious in that it requires a bunch of permutations, but you can do > something similar with a pre-loaded .csv file and it can be pretty quick > and easy once you're familiar with the technique. > > I'm still having a hard time figuring out how many of our potential users > might see value in a simpler method, provided that they can't know what the > order was *ex post*. > > One implementation approach could store the ordering somehow in the data. > I suppose that that approach could work whether it was an attribute or an > appearance, but then an appearance would seem less suitable (since the > response data would be encoded differently). If the response data were > changing format somehow, an attribute or even a different field type would > seem in order (pun intended). > > Best, > > Chris > > On Thu, Apr 7, 2016 at 8:31 AM Raghu Mittal <raghu....@gmail.com > wrote: > >> Hi Martijn, >> >> We have implemented this randomization of options within our own fork of >> ODK Collect and we wouldn't mind contributing it back to the ODK Repo. >> Some points regarding our implementation: >> 1. We did not need to record the sequence of options shown to the user. >> The only requirement was to randomize the options so that there is no bias >> on the part of the user to make a choice. In fact, the way the widget works >> is that every time you swipe to the same question, it shows a different >> order of options, even when an answer has already been selected. >> 2. We used a separate attribute called 'random' to make it work. Of >> course, given the +/- points you have listed, it seems that going the >> attribute way seems to be the best. >> 3. All options are indeed randomized, so if we have 'other', 'none' etc. >> they will not be put at the bottom. >> >> Chris, what you say is interesting, regarding randomizing using >> cascading-select. But I didn't get how this will work. Can you explain? Or >> maybe, just send me a link to the sample form you were mentioning and I >> could try that out. >> >> Thanks, >> Raghu >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> >

Hi Chris,

Thanks for sharing the sample form. I tried running this through an online
XLSForm converter, but it showed these errors:
Error: ODK Validate Errors: Error evaluating field
'SampleRandomizedChoiceForm': The problem was located in calculate
expression for /SampleRandomizedChoiceForm XPath evaluation: cannot handle
function 'random-once' Error evaluating field 'SampleRandomizedChoiceForm':
The problem was located in calculate expression for
/SampleRandomizedChoiceForm XPath evaluation: cannot handle function
'random-once' Caused by: org.javarosa.xpath.XPathUnhandledException: The
problem was located in calculate expression for /SampleRandomizedChoiceForm
XPath evaluation: cannot handle function 'random-once' ... 14 more >>
Something broke the parser. See above for a hint. Result: Invalid

Even when I somehow forced conversion to Xforms xml and put it on the ODK
Collect app, it again threw an error saying that it cannot handle function
'random-once'. Any ideas why 'random-once' is not being recognized?

Martijn,

We supported the random as an attribute. So it looks something like this:
<bind id="mc_factors4" nodeset="/raghu_mrdemo_v1/mc_factors4"
constraint="count-selected(.) = 4" jr:constraintMsg="Please select exactly
4 options" type="xsd:string" random="true()"/>

The random attribute is recognized for Select One and Select Multiple
widgets.

Regards,
Raghu

ยทยทยท On Fri, Apr 8, 2016 at 9:00 PM, Martijn van de Rijdt wrote:

Hi Raghu,

Thanks for sharing that! Great to hear this is working in your port. Can
you share the XForm syntax you are supporting?

Cheers,
Martijn

On Thursday, April 7, 2016 at 9:23:17 PM UTC-6, Christopher Robert wrote:

Hi Raghu,

Attached is an old sample form of ours that demonstrates the basic
technique: you repeat your choices x times, in x different orderings, and
then you use a choice filter to only show the randomly-selected ordering.
It's laborious in that it requires a bunch of permutations, but you can do
something similar with a pre-loaded .csv file and it can be pretty quick
and easy once you're familiar with the technique.

I'm still having a hard time figuring out how many of our potential users
might see value in a simpler method, provided that they can't know what the
order was ex post.

One implementation approach could store the ordering somehow in the data.
I suppose that that approach could work whether it was an attribute or an
appearance, but then an appearance would seem less suitable (since the
response data would be encoded differently). If the response data were
changing format somehow, an attribute or even a different field type would
seem in order (pun intended).

Best,

Chris

On Thu, Apr 7, 2016 at 8:31 AM Raghu Mittal raghu....@gmail.com wrote:

Hi Martijn,

We have implemented this randomization of options within our own fork of
ODK Collect and we wouldn't mind contributing it back to the ODK Repo.
Some points regarding our implementation:

  1. We did not need to record the sequence of options shown to the user.
    The only requirement was to randomize the options so that there is no bias
    on the part of the user to make a choice. In fact, the way the widget works
    is that every time you swipe to the same question, it shows a different
    order of options, even when an answer has already been selected.
  2. We used a separate attribute called 'random' to make it work. Of
    course, given the +/- points you have listed, it seems that going the
    attribute way seems to be the best.
  3. All options are indeed randomized, so if we have 'other', 'none' etc.
    they will not be put at the bottom.

Chris, what you say is interesting, regarding randomizing using
cascading-select. But I didn't get how this will work. Can you explain? Or
maybe, just send me a link to the sample form you were mentioning and I
could try that out.

Thanks,
Raghu

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Raghu,

Yes, sorry, you can change those calls to this instead:

once(random())

That's an old sample from before we settled on once(random()) for ODK and
SurveyCTO.

Best,

Chris

ยทยทยท --- Christopher Robert Dobility, Inc. (SurveyCTO) http://www.surveycto.com/ http://blog.surveycto.com/

On Mon, Apr 11, 2016 at 6:45 AM Raghu Mittal raghu.mittal@gmail.com wrote:

Hi Chris,

Thanks for sharing the sample form. I tried running this through an online
XLSForm converter, but it showed these errors:
Error: ODK Validate Errors: Error evaluating field
'SampleRandomizedChoiceForm': The problem was located in calculate
expression for /SampleRandomizedChoiceForm XPath evaluation: cannot handle
function 'random-once' Error evaluating field 'SampleRandomizedChoiceForm':
The problem was located in calculate expression for
/SampleRandomizedChoiceForm XPath evaluation: cannot handle function
'random-once' Caused by: org.javarosa.xpath.XPathUnhandledException: The
problem was located in calculate expression for /SampleRandomizedChoiceForm
XPath evaluation: cannot handle function 'random-once' ... 14 more >>
Something broke the parser. See above for a hint. Result: Invalid

Even when I somehow forced conversion to Xforms xml and put it on the ODK
Collect app, it again threw an error saying that it cannot handle function
'random-once'. Any ideas why 'random-once' is not being recognized?

Martijn,

We supported the random as an attribute. So it looks something like this:
<bind id="mc_factors4" nodeset="/raghu_mrdemo_v1/mc_factors4"
constraint="count-selected(.) = 4" jr:constraintMsg="Please select exactly
4 options" type="xsd:string" random="true()"/>

The random attribute is recognized for Select One and Select Multiple
widgets.

Regards,
Raghu

On Fri, Apr 8, 2016 at 9:00 PM, Martijn van de Rijdt martijn@enketo.org wrote:

Hi Raghu,

Thanks for sharing that! Great to hear this is working in your port. Can
you share the XForm syntax you are supporting?

Cheers,
Martijn

On Thursday, April 7, 2016 at 9:23:17 PM UTC-6, Christopher Robert wrote:

Hi Raghu,

Attached is an old sample form of ours that demonstrates the basic
technique: you repeat your choices x times, in x different orderings, and
then you use a choice filter to only show the randomly-selected ordering.
It's laborious in that it requires a bunch of permutations, but you can do
something similar with a pre-loaded .csv file and it can be pretty quick
and easy once you're familiar with the technique.

I'm still having a hard time figuring out how many of our potential
users might see value in a simpler method, provided that they can't know
what the order was ex post.

One implementation approach could store the ordering somehow in the
data. I suppose that that approach could work whether it was an attribute
or an appearance, but then an appearance would seem less suitable (since
the response data would be encoded differently). If the response data were
changing format somehow, an attribute or even a different field type would
seem in order (pun intended).

Best,

Chris

On Thu, Apr 7, 2016 at 8:31 AM Raghu Mittal raghu....@gmail.com wrote:

Hi Martijn,

We have implemented this randomization of options within our own fork
of ODK Collect and we wouldn't mind contributing it back to the ODK Repo.
Some points regarding our implementation:

  1. We did not need to record the sequence of options shown to the user.
    The only requirement was to randomize the options so that there is no bias
    on the part of the user to make a choice. In fact, the way the widget works
    is that every time you swipe to the same question, it shows a different
    order of options, even when an answer has already been selected.
  2. We used a separate attribute called 'random' to make it work. Of
    course, given the +/- points you have listed, it seems that going the
    attribute way seems to be the best.
  3. All options are indeed randomized, so if we have 'other', 'none'
    etc. they will not be put at the bottom.

Chris, what you say is interesting, regarding randomizing using
cascading-select. But I didn't get how this will work. Can you explain? Or
maybe, just send me a link to the sample form you were mentioning and I
could try that out.

Thanks,
Raghu

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--

You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Raghu,

Thanks for the syntax explanation. Did you choose to add it to the bind
instead of the body (select/select1 element) for ease-of-implementation, or
for another reason perhaps?

Cheers,
Martijn

ยทยทยท On Monday, April 11, 2016 at 4:55:33 AM UTC-6, Christopher Robert wrote: > > Hi Raghu, > > Yes, sorry, you can change those calls to this instead: > > once(random()) > > That's an old sample from before we settled on once(random()) for ODK and > SurveyCTO. > > Best, > > Chris > > --- > Christopher Robert > Dobility, Inc. (SurveyCTO) > http://www.surveycto.com/ > http://blog.surveycto.com/ > > On Mon, Apr 11, 2016 at 6:45 AM Raghu Mittal <raghu....@gmail.com > wrote: > >> Hi Chris, >> >> Thanks for sharing the sample form. I tried running this through an >> online XLSForm converter, but it showed these errors: >> Error: ODK Validate Errors: Error evaluating field >> 'SampleRandomizedChoiceForm': The problem was located in calculate >> expression for /SampleRandomizedChoiceForm XPath evaluation: cannot handle >> function 'random-once' Error evaluating field 'SampleRandomizedChoiceForm': >> The problem was located in calculate expression for >> /SampleRandomizedChoiceForm XPath evaluation: cannot handle function >> 'random-once' Caused by: org.javarosa.xpath.XPathUnhandledException: The >> problem was located in calculate expression for /SampleRandomizedChoiceForm >> XPath evaluation: cannot handle function 'random-once' ... 14 more >> >> Something broke the parser. See above for a hint. Result: Invalid >> >> Even when I somehow forced conversion to Xforms xml and put it on the ODK >> Collect app, it again threw an error saying that it cannot handle function >> 'random-once'. Any ideas why 'random-once' is not being recognized? >> >> Martijn, >> >> We supported the random as an attribute. So it looks something like this: >> > constraint="count-selected(.) = 4" jr:constraintMsg="Please select exactly >> 4 options" type="xsd:string" *random="true()"*/> >> >> The random attribute is recognized for Select One and Select Multiple >> widgets. >> >> Regards, >> Raghu >> >> >> On Fri, Apr 8, 2016 at 9:00 PM, Martijn van de Rijdt <mar...@enketo.org > wrote: >> >>> Hi Raghu, >>> >>> Thanks for sharing that! Great to hear this is working in your port. Can >>> you share the XForm syntax you are supporting? >>> >>> Cheers, >>> Martijn >>> >>> >>> On Thursday, April 7, 2016 at 9:23:17 PM UTC-6, Christopher Robert wrote: >>>> >>>> Hi Raghu, >>>> >>>> Attached is an old sample form of ours that demonstrates the basic >>>> technique: you repeat your choices x times, in x different orderings, and >>>> then you use a choice filter to only show the randomly-selected ordering. >>>> It's laborious in that it requires a bunch of permutations, but you can do >>>> something similar with a pre-loaded .csv file and it can be pretty quick >>>> and easy once you're familiar with the technique. >>>> >>>> I'm still having a hard time figuring out how many of our potential >>>> users might see value in a simpler method, provided that they can't know >>>> what the order was *ex post*. >>>> >>>> One implementation approach could store the ordering somehow in the >>>> data. I suppose that that approach could work whether it was an attribute >>>> or an appearance, but then an appearance would seem less suitable (since >>>> the response data would be encoded differently). If the response data were >>>> changing format somehow, an attribute or even a different field type would >>>> seem in order (pun intended). >>>> >>>> Best, >>>> >>>> Chris >>>> >>>> On Thu, Apr 7, 2016 at 8:31 AM Raghu Mittal wrote: >>>> >>>>> Hi Martijn, >>>>> >>>>> We have implemented this randomization of options within our own fork >>>>> of ODK Collect and we wouldn't mind contributing it back to the ODK Repo. >>>>> Some points regarding our implementation: >>>>> 1. We did not need to record the sequence of options shown to the >>>>> user. The only requirement was to randomize the options so that there is no >>>>> bias on the part of the user to make a choice. In fact, the way the widget >>>>> works is that every time you swipe to the same question, it shows a >>>>> different order of options, even when an answer has already been selected. >>>>> 2. We used a separate attribute called 'random' to make it work. Of >>>>> course, given the +/- points you have listed, it seems that going the >>>>> attribute way seems to be the best. >>>>> 3. All options are indeed randomized, so if we have 'other', 'none' >>>>> etc. they will not be put at the bottom. >>>>> >>>>> Chris, what you say is interesting, regarding randomizing using >>>>> cascading-select. But I didn't get how this will work. Can you explain? Or >>>>> maybe, just send me a link to the sample form you were mentioning and I >>>>> could try that out. >>>>> >>>>> Thanks, >>>>> Raghu >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "ODK Developers" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>> -- >>> *Revolutionizing data collection since 2012.* >>> >>> Enketo | LinkedIn >>> | GitHub >>> | Twitter >>> | Blog >>> >> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "ODK Developers" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> opendatakit-developers+unsubscribe@googlegroups.com . >>> >> >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> >

Hi Chris,

After doing the correction, the form works well, thanks. Its interesting
for me to see how the randomization works in this case.

@Martijn,

I don't think there will be much difference in terms of ease of
implementation between adding it to bind or putting in the body. We did
this implementation because putting it in bind as an attribute made it
clear for anybody reading the Xform xml that a particular question was
randomized.

In this regard, I should mention that we use ODK Collect with an OpenXData
server, hence we don't use any of the other software like Aggregate or ODK
Validate. Correspondingly, it was easy for us to put it as an attribute,
because there were no changes required anywhere else, apart from our own
Forms designer, and of course, our fork of ODK Collect.

Regards,
Raghu

ยทยทยท On Tue, Apr 12, 2016 at 1:03 AM, Martijn van de Rijdt wrote:

Hi Raghu,

Thanks for the syntax explanation. Did you choose to add it to the bind
instead of the body (select/select1 element) for ease-of-implementation, or
for another reason perhaps?

Cheers,
Martijn

On Monday, April 11, 2016 at 4:55:33 AM UTC-6, Christopher Robert wrote:

Hi Raghu,

Yes, sorry, you can change those calls to this instead:

once(random())

That's an old sample from before we settled on once(random()) for ODK and
SurveyCTO.

Best,

Chris


Christopher Robert
Dobility, Inc. (SurveyCTO)
http://www.surveycto.com/
http://blog.surveycto.com/

On Mon, Apr 11, 2016 at 6:45 AM Raghu Mittal raghu....@gmail.com wrote:

Hi Chris,

Thanks for sharing the sample form. I tried running this through an
online XLSForm converter, but it showed these errors:
Error: ODK Validate Errors: Error evaluating field
'SampleRandomizedChoiceForm': The problem was located in calculate
expression for /SampleRandomizedChoiceForm XPath evaluation: cannot handle
function 'random-once' Error evaluating field 'SampleRandomizedChoiceForm':
The problem was located in calculate expression for
/SampleRandomizedChoiceForm XPath evaluation: cannot handle function
'random-once' Caused by: org.javarosa.xpath.XPathUnhandledException: The
problem was located in calculate expression for /SampleRandomizedChoiceForm
XPath evaluation: cannot handle function 'random-once' ... 14 more >>
Something broke the parser. See above for a hint. Result: Invalid

Even when I somehow forced conversion to Xforms xml and put it on the
ODK Collect app, it again threw an error saying that it cannot handle
function 'random-once'. Any ideas why 'random-once' is not being recognized?

Martijn,

We supported the random as an attribute. So it looks something like this:
<bind id="mc_factors4" nodeset="/raghu_mrdemo_v1/mc_factors4"
constraint="count-selected(.) = 4" jr:constraintMsg="Please select exactly
4 options" type="xsd:string" random="true()"/>

The random attribute is recognized for Select One and Select Multiple
widgets.

Regards,
Raghu

On Fri, Apr 8, 2016 at 9:00 PM, Martijn van de Rijdt mar...@enketo.org wrote:

Hi Raghu,

Thanks for sharing that! Great to hear this is working in your port.
Can you share the XForm syntax you are supporting?

Cheers,
Martijn

On Thursday, April 7, 2016 at 9:23:17 PM UTC-6, Christopher Robert wrote:

Hi Raghu,

Attached is an old sample form of ours that demonstrates the basic
technique: you repeat your choices x times, in x different orderings, and
then you use a choice filter to only show the randomly-selected ordering.
It's laborious in that it requires a bunch of permutations, but you can do
something similar with a pre-loaded .csv file and it can be pretty quick
and easy once you're familiar with the technique.

I'm still having a hard time figuring out how many of our potential
users might see value in a simpler method, provided that they can't know
what the order was ex post.

One implementation approach could store the ordering somehow in the
data. I suppose that that approach could work whether it was an attribute
or an appearance, but then an appearance would seem less suitable (since
the response data would be encoded differently). If the response data were
changing format somehow, an attribute or even a different field type would
seem in order (pun intended).

Best,

Chris

On Thu, Apr 7, 2016 at 8:31 AM Raghu Mittal raghu....@gmail.com wrote:

Hi Martijn,

We have implemented this randomization of options within our own fork
of ODK Collect and we wouldn't mind contributing it back to the ODK Repo.
Some points regarding our implementation:

  1. We did not need to record the sequence of options shown to the
    user. The only requirement was to randomize the options so that there is no
    bias on the part of the user to make a choice. In fact, the way the widget
    works is that every time you swipe to the same question, it shows a
    different order of options, even when an answer has already been selected.
  2. We used a separate attribute called 'random' to make it work. Of
    course, given the +/- points you have listed, it seems that going the
    attribute way seems to be the best.
  3. All options are indeed randomized, so if we have 'other', 'none'
    etc. they will not be put at the bottom.

Chris, what you say is interesting, regarding randomizing using
cascading-select. But I didn't get how this will work. Can you explain? Or
maybe, just send me a link to the sample form you were mentioning and I
could try that out.

Thanks,
Raghu

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter
https://twitter.com/enketo | Blog http://blog.enketo.org/

--

You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thanks Raghu!

@all

After this discussion, I reject my own proposal. My conclusion is that this
functionality should be added in a new randomize() XPath function that
takes a nodeset argument. I think it's the only proper non-hacky way to
randomize items. It seems easy to implement in Enketo. Hopefully also in
JavaRosa. I'm sure we could find somebody to help out with pyxform syntax
shortcuts, if we decide we want to move forward and add this to the spec.

Yaw, Mitch, your inputs would naturally also be very welcome!

ยทยทยท On Tuesday, April 12, 2016 at 6:25:09 AM UTC-6, Raghu Mittal wrote: > > Hi Chris, > > After doing the correction, the form works well, thanks. Its interesting > for me to see how the randomization works in this case. > > @Martijn, > > I don't think there will be much difference in terms of ease of > implementation between adding it to bind or putting in the body. We did > this implementation because putting it in bind as an attribute made it > clear for anybody reading the Xform xml that a particular question was > randomized. > > In this regard, I should mention that we use ODK Collect with an OpenXData > server, hence we don't use any of the other software like Aggregate or ODK > Validate. Correspondingly, it was easy for us to put it as an attribute, > because there were no changes required anywhere else, apart from our own > Forms designer, and of course, our fork of ODK Collect. > > Regards, > Raghu > > > On Tue, Apr 12, 2016 at 1:03 AM, Martijn van de Rijdt <mar...@enketo.org > wrote: > >> Hi Raghu, >> >> Thanks for the syntax explanation. Did you choose to add it to the bind >> instead of the body (select/select1 element) for ease-of-implementation, or >> for another reason perhaps? >> >> Cheers, >> Martijn >> >> On Monday, April 11, 2016 at 4:55:33 AM UTC-6, Christopher Robert wrote: >>> >>> Hi Raghu, >>> >>> Yes, sorry, you can change those calls to this instead: >>> >>> once(random()) >>> >>> That's an old sample from before we settled on once(random()) for ODK >>> and SurveyCTO. >>> >>> Best, >>> >>> Chris >>> >>> --- >>> Christopher Robert >>> Dobility, Inc. (SurveyCTO) >>> http://www.surveycto.com/ >>> http://blog.surveycto.com/ >>> >>> On Mon, Apr 11, 2016 at 6:45 AM Raghu Mittal wrote: >>> >>>> Hi Chris, >>>> >>>> Thanks for sharing the sample form. I tried running this through an >>>> online XLSForm converter, but it showed these errors: >>>> Error: ODK Validate Errors: Error evaluating field >>>> 'SampleRandomizedChoiceForm': The problem was located in calculate >>>> expression for /SampleRandomizedChoiceForm XPath evaluation: cannot handle >>>> function 'random-once' Error evaluating field 'SampleRandomizedChoiceForm': >>>> The problem was located in calculate expression for >>>> /SampleRandomizedChoiceForm XPath evaluation: cannot handle function >>>> 'random-once' Caused by: org.javarosa.xpath.XPathUnhandledException: The >>>> problem was located in calculate expression for /SampleRandomizedChoiceForm >>>> XPath evaluation: cannot handle function 'random-once' ... 14 more >> >>>> Something broke the parser. See above for a hint. Result: Invalid >>>> >>>> Even when I somehow forced conversion to Xforms xml and put it on the >>>> ODK Collect app, it again threw an error saying that it cannot handle >>>> function 'random-once'. Any ideas why 'random-once' is not being recognized? >>>> >>>> Martijn, >>>> >>>> We supported the random as an attribute. So it looks something like >>>> this: >>>> >>> constraint="count-selected(.) = 4" jr:constraintMsg="Please select exactly >>>> 4 options" type="xsd:string" *random="true()"*/> >>>> >>>> The random attribute is recognized for Select One and Select Multiple >>>> widgets. >>>> >>>> Regards, >>>> Raghu >>>> >>>> >>>> On Fri, Apr 8, 2016 at 9:00 PM, Martijn van de Rijdt >>> >>>>> Hi Raghu, >>>>> >>>>> Thanks for sharing that! Great to hear this is working in your port. >>>>> Can you share the XForm syntax you are supporting? >>>>> >>>>> Cheers, >>>>> Martijn >>>>> >>>>> >>>>> On Thursday, April 7, 2016 at 9:23:17 PM UTC-6, Christopher Robert wrote: >>>>>> >>>>>> Hi Raghu, >>>>>> >>>>>> Attached is an old sample form of ours that demonstrates the basic >>>>>> technique: you repeat your choices x times, in x different orderings, and >>>>>> then you use a choice filter to only show the randomly-selected ordering. >>>>>> It's laborious in that it requires a bunch of permutations, but you can do >>>>>> something similar with a pre-loaded .csv file and it can be pretty quick >>>>>> and easy once you're familiar with the technique. >>>>>> >>>>>> I'm still having a hard time figuring out how many of our potential >>>>>> users might see value in a simpler method, provided that they can't know >>>>>> what the order was *ex post*. >>>>>> >>>>>> One implementation approach could store the ordering somehow in the >>>>>> data. I suppose that that approach could work whether it was an attribute >>>>>> or an appearance, but then an appearance would seem less suitable (since >>>>>> the response data would be encoded differently). If the response data were >>>>>> changing format somehow, an attribute or even a different field type would >>>>>> seem in order (pun intended). >>>>>> >>>>>> Best, >>>>>> >>>>>> Chris >>>>>> >>>>>> On Thu, Apr 7, 2016 at 8:31 AM Raghu Mittal wrote: >>>>>> >>>>>>> Hi Martijn, >>>>>>> >>>>>>> We have implemented this randomization of options within our own >>>>>>> fork of ODK Collect and we wouldn't mind contributing it back to the ODK >>>>>>> Repo. >>>>>>> Some points regarding our implementation: >>>>>>> 1. We did not need to record the sequence of options shown to the >>>>>>> user. The only requirement was to randomize the options so that there is no >>>>>>> bias on the part of the user to make a choice. In fact, the way the widget >>>>>>> works is that every time you swipe to the same question, it shows a >>>>>>> different order of options, even when an answer has already been selected. >>>>>>> 2. We used a separate attribute called 'random' to make it work. Of >>>>>>> course, given the +/- points you have listed, it seems that going the >>>>>>> attribute way seems to be the best. >>>>>>> 3. All options are indeed randomized, so if we have 'other', 'none' >>>>>>> etc. they will not be put at the bottom. >>>>>>> >>>>>>> Chris, what you say is interesting, regarding randomizing using >>>>>>> cascading-select. But I didn't get how this will work. Can you explain? Or >>>>>>> maybe, just send me a link to the sample form you were mentioning and I >>>>>>> could try that out. >>>>>>> >>>>>>> Thanks, >>>>>>> Raghu >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "ODK Developers" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to opendatakit-developers+unsubscribe@googlegroups.com >>>>>>> . >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>> -- >>>>> *Revolutionizing data collection since 2012.* >>>>> >>>>> Enketo | LinkedIn >>>>> | GitHub >>>>> | Twitter >>>>> | Blog >>>>> >>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "ODK Developers" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe >>>>> . >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> opendatakit-developers+unsubscribe@googlegroups.com. >>>>> >>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ODK Developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >> -- >> *Revolutionizing data collection since 2012.* >> >> Enketo | LinkedIn >> | GitHub >> | Twitter >> | Blog >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "ODK Developers" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> opendatakit-developers+unsubscribe@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > >
1 Like

Martijn,

If most of the users who have requested this feature want some way to
record the ordering, then XPath function is the best bet. If not, then
I like putting it in appearance.

Yaw

ยทยทยท -- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Tue, Apr 19, 2016 at 4:48 PM, Martijn van de Rijdt martijn@enketo.org wrote:

Thanks Raghu!

@all

After this discussion, I reject my own proposal. My conclusion is that this
functionality should be added in a new randomize() XPath function that takes
a nodeset argument. I think it's the only proper non-hacky way to randomize
items. It seems easy to implement in Enketo. Hopefully also in JavaRosa. I'm
sure we could find somebody to help out with pyxform syntax shortcuts, if we
decide we want to move forward and add this to the spec.

Yaw, Mitch, your inputs would naturally also be very welcome!

On Tuesday, April 12, 2016 at 6:25:09 AM UTC-6, Raghu Mittal wrote:

Hi Chris,

After doing the correction, the form works well, thanks. Its interesting
for me to see how the randomization works in this case.

@Martijn,

I don't think there will be much difference in terms of ease of
implementation between adding it to bind or putting in the body. We did this
implementation because putting it in bind as an attribute made it clear for
anybody reading the Xform xml that a particular question was randomized.

In this regard, I should mention that we use ODK Collect with an OpenXData
server, hence we don't use any of the other software like Aggregate or ODK
Validate. Correspondingly, it was easy for us to put it as an attribute,
because there were no changes required anywhere else, apart from our own
Forms designer, and of course, our fork of ODK Collect.

Regards,
Raghu

On Tue, Apr 12, 2016 at 1:03 AM, Martijn van de Rijdt mar...@enketo.org wrote:

Hi Raghu,

Thanks for the syntax explanation. Did you choose to add it to the bind
instead of the body (select/select1 element) for ease-of-implementation, or
for another reason perhaps?

Cheers,
Martijn

On Monday, April 11, 2016 at 4:55:33 AM UTC-6, Christopher Robert wrote:

Hi Raghu,

Yes, sorry, you can change those calls to this instead:

once(random())

That's an old sample from before we settled on once(random()) for ODK
and SurveyCTO.

Best,

Chris


Christopher Robert
Dobility, Inc. (SurveyCTO)
http://www.surveycto.com/
http://blog.surveycto.com/

On Mon, Apr 11, 2016 at 6:45 AM Raghu Mittal raghu....@gmail.com wrote:

Hi Chris,

Thanks for sharing the sample form. I tried running this through an
online XLSForm converter, but it showed these errors:
Error: ODK Validate Errors: Error evaluating field
'SampleRandomizedChoiceForm': The problem was located in calculate
expression for /SampleRandomizedChoiceForm XPath evaluation: cannot handle
function 'random-once' Error evaluating field 'SampleRandomizedChoiceForm':
The problem was located in calculate expression for
/SampleRandomizedChoiceForm XPath evaluation: cannot handle function
'random-once' Caused by: org.javarosa.xpath.XPathUnhandledException: The
problem was located in calculate expression for /SampleRandomizedChoiceForm
XPath evaluation: cannot handle function 'random-once' ... 14 more >>
Something broke the parser. See above for a hint. Result: Invalid

Even when I somehow forced conversion to Xforms xml and put it on the
ODK Collect app, it again threw an error saying that it cannot handle
function 'random-once'. Any ideas why 'random-once' is not being recognized?

Martijn,

We supported the random as an attribute. So it looks something like
this:

The random attribute is recognized for Select One and Select Multiple
widgets.

Regards,
Raghu

On Fri, Apr 8, 2016 at 9:00 PM, Martijn van de Rijdt mar...@enketo.org wrote:

Hi Raghu,

Thanks for sharing that! Great to hear this is working in your port.
Can you share the XForm syntax you are supporting?

Cheers,
Martijn

On Thursday, April 7, 2016 at 9:23:17 PM UTC-6, Christopher Robert wrote:

Hi Raghu,

Attached is an old sample form of ours that demonstrates the basic
technique: you repeat your choices x times, in x different orderings, and
then you use a choice filter to only show the randomly-selected ordering.
It's laborious in that it requires a bunch of permutations, but you can do
something similar with a pre-loaded .csv file and it can be pretty quick and
easy once you're familiar with the technique.

I'm still having a hard time figuring out how many of our potential
users might see value in a simpler method, provided that they can't know
what the order was ex post.

One implementation approach could store the ordering somehow in the
data. I suppose that that approach could work whether it was an attribute or
an appearance, but then an appearance would seem less suitable (since the
response data would be encoded differently). If the response data were
changing format somehow, an attribute or even a different field type would
seem in order (pun intended).

Best,

Chris

On Thu, Apr 7, 2016 at 8:31 AM Raghu Mittal raghu....@gmail.com wrote:

Hi Martijn,

We have implemented this randomization of options within our own
fork of ODK Collect and we wouldn't mind contributing it back to the ODK
Repo.
Some points regarding our implementation:

  1. We did not need to record the sequence of options shown to the
    user. The only requirement was to randomize the options so that there is no
    bias on the part of the user to make a choice. In fact, the way the widget
    works is that every time you swipe to the same question, it shows a
    different order of options, even when an answer has already been selected.
  2. We used a separate attribute called 'random' to make it work. Of
    course, given the +/- points you have listed, it seems that going the
    attribute way seems to be the best.
  3. All options are indeed randomized, so if we have 'other', 'none'
    etc. they will not be put at the bottom.

Chris, what you say is interesting, regarding randomizing using
cascading-select. But I didn't get how this will work. Can you explain? Or
maybe, just send me a link to the sample form you were mentioning and I
could try that out.

Thanks,
Raghu

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi

Probably out of scope here but to me it is probably not just recording the
order but carrying that same order over as well into subsequent questions.
I have never been personally asked for that but I could see it being useful

Regards

ยทยทยท On Tue, May 3, 2016 at 10:07 AM, Yaw Anokwa wrote:

Martijn,

If most of the users who have requested this feature want some way to
record the ordering, then XPath function is the best bet. If not, then
I like putting it in appearance.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Tue, Apr 19, 2016 at 4:48 PM, Martijn van de Rijdt martijn@enketo.org wrote:

Thanks Raghu!

@all

After this discussion, I reject my own proposal. My conclusion is that
this
functionality should be added in a new randomize() XPath function that
takes
a nodeset argument. I think it's the only proper non-hacky way to
randomize
items. It seems easy to implement in Enketo. Hopefully also in JavaRosa.
I'm
sure we could find somebody to help out with pyxform syntax shortcuts,
if we
decide we want to move forward and add this to the spec.

Yaw, Mitch, your inputs would naturally also be very welcome!

On Tuesday, April 12, 2016 at 6:25:09 AM UTC-6, Raghu Mittal wrote:

Hi Chris,

After doing the correction, the form works well, thanks. Its interesting
for me to see how the randomization works in this case.

@Martijn,

I don't think there will be much difference in terms of ease of
implementation between adding it to bind or putting in the body. We did
this

implementation because putting it in bind as an attribute made it clear
for

anybody reading the Xform xml that a particular question was randomized.

In this regard, I should mention that we use ODK Collect with an
OpenXData

server, hence we don't use any of the other software like Aggregate or
ODK

Validate. Correspondingly, it was easy for us to put it as an attribute,
because there were no changes required anywhere else, apart from our own
Forms designer, and of course, our fork of ODK Collect.

Regards,
Raghu

On Tue, Apr 12, 2016 at 1:03 AM, Martijn van de Rijdt < mar...@enketo.org> wrote:

Hi Raghu,

Thanks for the syntax explanation. Did you choose to add it to the bind
instead of the body (select/select1 element) for
ease-of-implementation, or

for another reason perhaps?

Cheers,
Martijn

On Monday, April 11, 2016 at 4:55:33 AM UTC-6, Christopher Robert wrote:

Hi Raghu,

Yes, sorry, you can change those calls to this instead:

once(random())

That's an old sample from before we settled on once(random()) for ODK
and SurveyCTO.

Best,

Chris


Christopher Robert
Dobility, Inc. (SurveyCTO)
http://www.surveycto.com/
http://blog.surveycto.com/

On Mon, Apr 11, 2016 at 6:45 AM Raghu Mittal raghu....@gmail.com wrote:

Hi Chris,

Thanks for sharing the sample form. I tried running this through an
online XLSForm converter, but it showed these errors:
Error: ODK Validate Errors: Error evaluating field
'SampleRandomizedChoiceForm': The problem was located in calculate
expression for /SampleRandomizedChoiceForm XPath evaluation: cannot
handle

function 'random-once' Error evaluating field
'SampleRandomizedChoiceForm':

The problem was located in calculate expression for
/SampleRandomizedChoiceForm XPath evaluation: cannot handle function
'random-once' Caused by: org.javarosa.xpath.XPathUnhandledException:
The

problem was located in calculate expression for
/SampleRandomizedChoiceForm

XPath evaluation: cannot handle function 'random-once' ... 14 more >>
Something broke the parser. See above for a hint. Result: Invalid

Even when I somehow forced conversion to Xforms xml and put it on the
ODK Collect app, it again threw an error saying that it cannot handle
function 'random-once'. Any ideas why 'random-once' is not being
recognized?

Martijn,

We supported the random as an attribute. So it looks something like
this:
<bind id="mc_factors4" nodeset="/raghu_mrdemo_v1/mc_factors4"
constraint="count-selected(.) = 4" jr:constraintMsg="Please select
exactly 4

options" type="xsd:string" random="true()"/>

The random attribute is recognized for Select One and Select Multiple
widgets.

Regards,
Raghu

On Fri, Apr 8, 2016 at 9:00 PM, Martijn van de Rijdt mar...@enketo.org wrote:

Hi Raghu,

Thanks for sharing that! Great to hear this is working in your port.
Can you share the XForm syntax you are supporting?

Cheers,
Martijn

On Thursday, April 7, 2016 at 9:23:17 PM UTC-6, Christopher Robert wrote:

Hi Raghu,

Attached is an old sample form of ours that demonstrates the basic
technique: you repeat your choices x times, in x different
orderings, and

then you use a choice filter to only show the randomly-selected
ordering.

It's laborious in that it requires a bunch of permutations, but
you can do

something similar with a pre-loaded .csv file and it can be pretty
quick and

easy once you're familiar with the technique.

I'm still having a hard time figuring out how many of our potential
users might see value in a simpler method, provided that they
can't know

what the order was ex post.

One implementation approach could store the ordering somehow in the
data. I suppose that that approach could work whether it was an
attribute or

an appearance, but then an appearance would seem less suitable
(since the

response data would be encoded differently). If the response data
were

changing format somehow, an attribute or even a different field
type would

seem in order (pun intended).

Best,

Chris

On Thu, Apr 7, 2016 at 8:31 AM Raghu Mittal raghu....@gmail.com wrote:

Hi Martijn,

We have implemented this randomization of options within our own
fork of ODK Collect and we wouldn't mind contributing it back to
the ODK

Repo.
Some points regarding our implementation:

  1. We did not need to record the sequence of options shown to the
    user. The only requirement was to randomize the options so that
    there is no

bias on the part of the user to make a choice. In fact, the way
the widget

works is that every time you swipe to the same question, it shows
a

different order of options, even when an answer has already been
selected.

  1. We used a separate attribute called 'random' to make it work.
    Of

course, given the +/- points you have listed, it seems that going
the

attribute way seems to be the best.
3. All options are indeed randomized, so if we have 'other',
'none'

etc. they will not be put at the bottom.

Chris, what you say is interesting, regarding randomizing using
cascading-select. But I didn't get how this will work. Can you
explain? Or

maybe, just send me a link to the sample form you were mentioning
and I

could try that out.

Thanks,
Raghu

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to a topic in
the

Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe
.

To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe
.

To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thanks Yaw, Ian,

An additional reason for using an XPath function, is that it just isn't
right to shuffle fixed body elements in an XForm. For me that's the main
reason to only do this with itemsets.

I think from the Enketo side, we'll probably wait with implementing this
until we hear this is going ahead on the ODK side at some point in the
future, or until we can provide a PR for this function in JavaRosa (and
pyxform). I hope we'll get there, as it opens up some very interesting
usage possibilities.

I have created an issue for it for Enketo which can be tracked here
https://github.com/kobotoolbox/enketo-express/issues/363#issuecomment-208580501
.

Best,
Martijn

ยทยทยท On Tuesday, May 3, 2016 at 8:30:57 AM UTC-6, Ian Lawrence wrote: > > Hi > > Probably out of scope here but to me it is probably not just recording the > order but carrying that same order over as well into subsequent questions. > I have never been personally asked for that but I could see it being useful > > Regards > > On Tue, May 3, 2016 at 10:07 AM, Yaw Anokwa <yan...@nafundi.com > wrote: > >> Martijn, >> >> If most of the users who have requested this feature want some way to >> record the ordering, then XPath function is the best bet. If not, then >> I like putting it in appearance. >> >> Yaw >> -- >> Need ODK consultants? Nafundi provides form design, server setup, >> in-field training, and software development for ODK. Go to >> https://nafundi.com to get started. >> >> On Tue, Apr 19, 2016 at 4:48 PM, Martijn van de Rijdt <mar...@enketo.org > wrote: >> > Thanks Raghu! >> > >> > @all >> > >> > After this discussion, I reject my own proposal. My conclusion is that >> this >> > functionality should be added in a new randomize() XPath function that >> takes >> > a nodeset argument. I think it's the only proper non-hacky way to >> randomize >> > items. It seems easy to implement in Enketo. Hopefully also in >> JavaRosa. I'm >> > sure we could find somebody to help out with pyxform syntax shortcuts, >> if we >> > decide we want to move forward and add this to the spec. >> > >> > Yaw, Mitch, your inputs would naturally also be very welcome! >> > >> > On Tuesday, April 12, 2016 at 6:25:09 AM UTC-6, Raghu Mittal wrote: >> >> >> >> Hi Chris, >> >> >> >> After doing the correction, the form works well, thanks. Its >> interesting >> >> for me to see how the randomization works in this case. >> >> >> >> @Martijn, >> >> >> >> I don't think there will be much difference in terms of ease of >> >> implementation between adding it to bind or putting in the body. We >> did this >> >> implementation because putting it in bind as an attribute made it >> clear for >> >> anybody reading the Xform xml that a particular question was >> randomized. >> >> >> >> In this regard, I should mention that we use ODK Collect with an >> OpenXData >> >> server, hence we don't use any of the other software like Aggregate or >> ODK >> >> Validate. Correspondingly, it was easy for us to put it as an >> attribute, >> >> because there were no changes required anywhere else, apart from our >> own >> >> Forms designer, and of course, our fork of ODK Collect. >> >> >> >> Regards, >> >> Raghu >> >> >> >> >> >> On Tue, Apr 12, 2016 at 1:03 AM, Martijn van de Rijdt < mar...@enketo.org> wrote: >> >>> >> >>> Hi Raghu, >> >>> >> >>> Thanks for the syntax explanation. Did you choose to add it to the >> bind >> >>> instead of the body (select/select1 element) for >> ease-of-implementation, or >> >>> for another reason perhaps? >> >>> >> >>> Cheers, >> >>> Martijn >> >>> >> >>> On Monday, April 11, 2016 at 4:55:33 AM UTC-6, Christopher Robert wrote: >> >>>> >> >>>> Hi Raghu, >> >>>> >> >>>> Yes, sorry, you can change those calls to this instead: >> >>>> >> >>>> once(random()) >> >>>> >> >>>> That's an old sample from before we settled on once(random()) for ODK >> >>>> and SurveyCTO. >> >>>> >> >>>> Best, >> >>>> >> >>>> Chris >> >>>> >> >>>> --- >> >>>> Christopher Robert >> >>>> Dobility, Inc. (SurveyCTO) >> >>>> http://www.surveycto.com/ >> >>>> http://blog.surveycto.com/ >> >>>> >> >>>> On Mon, Apr 11, 2016 at 6:45 AM Raghu Mittal wrote: >> >>>>> >> >>>>> Hi Chris, >> >>>>> >> >>>>> Thanks for sharing the sample form. I tried running this through an >> >>>>> online XLSForm converter, but it showed these errors: >> >>>>> Error: ODK Validate Errors: Error evaluating field >> >>>>> 'SampleRandomizedChoiceForm': The problem was located in calculate >> >>>>> expression for /SampleRandomizedChoiceForm XPath evaluation: cannot >> handle >> >>>>> function 'random-once' Error evaluating field >> 'SampleRandomizedChoiceForm': >> >>>>> The problem was located in calculate expression for >> >>>>> /SampleRandomizedChoiceForm XPath evaluation: cannot handle function >> >>>>> 'random-once' Caused by: >> org.javarosa.xpath.XPathUnhandledException: The >> >>>>> problem was located in calculate expression for >> /SampleRandomizedChoiceForm >> >>>>> XPath evaluation: cannot handle function 'random-once' ... 14 more >> >> >> >>>>> Something broke the parser. See above for a hint. Result: Invalid >> >>>>> >> >>>>> Even when I somehow forced conversion to Xforms xml and put it on >> the >> >>>>> ODK Collect app, it again threw an error saying that it cannot >> handle >> >>>>> function 'random-once'. Any ideas why 'random-once' is not being >> recognized? >> >>>>> >> >>>>> Martijn, >> >>>>> >> >>>>> We supported the random as an attribute. So it looks something like >> >>>>> this: >> >>>>> > >>>>> constraint="count-selected(.) = 4" jr:constraintMsg="Please select >> exactly 4 >> >>>>> options" type="xsd:string" random="true()"/> >> >>>>> >> >>>>> The random attribute is recognized for Select One and Select >> Multiple >> >>>>> widgets. >> >>>>> >> >>>>> Regards, >> >>>>> Raghu >> >>>>> >> >>>>> >> >>>>> On Fri, Apr 8, 2016 at 9:00 PM, Martijn van de Rijdt wrote: >> >>>>>> >> >>>>>> Hi Raghu, >> >>>>>> >> >>>>>> Thanks for sharing that! Great to hear this is working in your >> port. >> >>>>>> Can you share the XForm syntax you are supporting? >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Martijn >> >>>>>> >> >>>>>> >> >>>>>> On Thursday, April 7, 2016 at 9:23:17 PM UTC-6, Christopher Robert wrote: >> >>>>>>> >> >>>>>>> Hi Raghu, >> >>>>>>> >> >>>>>>> Attached is an old sample form of ours that demonstrates the basic >> >>>>>>> technique: you repeat your choices x times, in x different >> orderings, and >> >>>>>>> then you use a choice filter to only show the randomly-selected >> ordering. >> >>>>>>> It's laborious in that it requires a bunch of permutations, but >> you can do >> >>>>>>> something similar with a pre-loaded .csv file and it can be >> pretty quick and >> >>>>>>> easy once you're familiar with the technique. >> >>>>>>> >> >>>>>>> I'm still having a hard time figuring out how many of our >> potential >> >>>>>>> users might see value in a simpler method, provided that they >> can't know >> >>>>>>> what the order was ex post. >> >>>>>>> >> >>>>>>> One implementation approach could store the ordering somehow in >> the >> >>>>>>> data. I suppose that that approach could work whether it was an >> attribute or >> >>>>>>> an appearance, but then an appearance would seem less suitable >> (since the >> >>>>>>> response data would be encoded differently). If the response data >> were >> >>>>>>> changing format somehow, an attribute or even a different field >> type would >> >>>>>>> seem in order (pun intended). >> >>>>>>> >> >>>>>>> Best, >> >>>>>>> >> >>>>>>> Chris >> >>>>>>> >> >>>>>>> On Thu, Apr 7, 2016 at 8:31 AM Raghu Mittal wrote: >> >>>>>>>> >> >>>>>>>> Hi Martijn, >> >>>>>>>> >> >>>>>>>> We have implemented this randomization of options within our own >> >>>>>>>> fork of ODK Collect and we wouldn't mind contributing it back to >> the ODK >> >>>>>>>> Repo. >> >>>>>>>> Some points regarding our implementation: >> >>>>>>>> 1. We did not need to record the sequence of options shown to the >> >>>>>>>> user. The only requirement was to randomize the options so that >> there is no >> >>>>>>>> bias on the part of the user to make a choice. In fact, the way >> the widget >> >>>>>>>> works is that every time you swipe to the same question, it >> shows a >> >>>>>>>> different order of options, even when an answer has already been >> selected. >> >>>>>>>> 2. We used a separate attribute called 'random' to make it work. >> Of >> >>>>>>>> course, given the +/- points you have listed, it seems that >> going the >> >>>>>>>> attribute way seems to be the best. >> >>>>>>>> 3. All options are indeed randomized, so if we have 'other', >> 'none' >> >>>>>>>> etc. they will not be put at the bottom. >> >>>>>>>> >> >>>>>>>> Chris, what you say is interesting, regarding randomizing using >> >>>>>>>> cascading-select. But I didn't get how this will work. Can you >> explain? Or >> >>>>>>>> maybe, just send me a link to the sample form you were >> mentioning and I >> >>>>>>>> could try that out. >> >>>>>>>> >> >>>>>>>> Thanks, >> >>>>>>>> Raghu >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> You received this message because you are subscribed to the >> Google >> >>>>>>>> Groups "ODK Developers" group. >> >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >> >>>>>>>> send an email to >> opendatakit-developers+unsubscribe@googlegroups.com . >> >>>>>>>> For more options, visit https://groups.google.com/d/optout. >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Revolutionizing data collection since 2012. >> >>>>>> >> >>>>>> Enketo | LinkedIn | GitHub | Twitter | Blog >> >>>>>> >> >>>>>> -- >> >>>>>> You received this message because you are subscribed to a topic in >> the >> >>>>>> Google Groups "ODK Developers" group. >> >>>>>> To unsubscribe from this topic, visit >> >>>>>> >> https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe >> . >> >>>>>> To unsubscribe from this group and all its topics, send an email to >> >>>>>> opendatakit-developers+unsubscribe@googlegroups.com . >> >>>>>> >> >>>>>> >> >>>>>> For more options, visit https://groups.google.com/d/optout. >> >>>>> >> >>>>> -- >> >>>>> You received this message because you are subscribed to the Google >> >>>>> Groups "ODK Developers" group. >> >>>>> To unsubscribe from this group and stop receiving emails from it, >> send >> >>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> >>>>> For more options, visit https://groups.google.com/d/optout. >> >>> >> >>> >> >>> -- >> >>> Revolutionizing data collection since 2012. >> >>> >> >>> Enketo | LinkedIn | GitHub | Twitter | Blog >> >>> >> >>> -- >> >>> You received this message because you are subscribed to a topic in the >> >>> Google Groups "ODK Developers" group. >> >>> To unsubscribe from this topic, visit >> >>> >> https://groups.google.com/d/topic/opendatakit-developers/plutkYCqWB4/unsubscribe >> . >> >>> To unsubscribe from this group and all its topics, send an email to >> >>> opendatakit-developers+unsubscribe@googlegroups.com . >> >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> > >> > -- >> > Revolutionizing data collection since 2012. >> > >> > Enketo | LinkedIn | GitHub | Twitter | Blog >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "ODK Developers" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > >