Proposal: linking two questions together visually

[martijnr]

Hi ODK Devs,

We added some functionality to Enketo and wanted to propose a related
addition to the OpenRosa/ODK XForm specification.

If you agree with this addition to the XForms spec (or an alternative),
I'll add it to the documentation and use the OpenRosa namespace. If, not
we'll just consider it an Enketo-specific extension and use an Enketo
namespace. In either case the XForms are functional in ODK Collect, because
the addition is just ignored.

Requirement:

Visually link two questions together. Can be used for various features,
e.g. one question could be a comment on another question.

Proposal:

Add a namespaced `for"bind attribute, like this:

The for attribute contains a relative or absolute path to the question it
links with. So in combination with an appearance you could now visually
link these questions together in creative ways that regular XForm groups do
not allow. E.g. add a button to the linked question that when clicked shows
a modal containing the other question. There are no restrictions, special
assumptions or magic. A question could have multiple questions linked to it
for example.

If there is some enthusiasm for this I'll follow up with another more
specific proposal to build upon this XForm addition to create a very
flexible comment feature.

Cheers,
Martijn

[crobert]

Hi Martijn,

Sounds interesting. Can you say any more about the likely use cases and the
additional specification extensions those might require?

I ask only because it seems a bit difficult to think about this "linking of
questions" issue separated from the nature of the links themselves -- and
what other properties or parameters would be required to support those
types of links. For example, you might say that when field q3 has a
relevance expression like "q1+q2 < 100", then q3 is linked in a way with q1
and q2: its visibility depends on q1 and q2. Likewise, constraints can
include links, labels can include links, and so we have varied ways in
which fields are already related to one another. And in a sense you can say
that all of the fields within a group (with the field-list appearance or
otherwise) are related.

In none of those cases is a separate "for" construct necessary, and so it
gets me thinking about what other kinds of links might or might not require
(or benefit from) a "for" linkage. That's why I thought more use cases
might be useful, to determine whether they share the need for a new
"for"-type linkage, or if, like the existing linkages, they might be
somehow implicit or arranged in some other way. For example, if another
extension might be necessary to support modal pop-ups, then might that
extension itself not have its own way of specifying the linkages?

Thanks,

Chris

···

On Thu, Jun 23, 2016 at 12:57 PM Martijn van de Rijdt wrote:

Hi ODK Devs,

We added some functionality to Enketo and wanted to propose a related
addition to the OpenRosa/ODK XForm specification.

If you agree with this addition to the XForms spec (or an alternative),
I'll add it to the documentation and use the OpenRosa namespace. If, not
we'll just consider it an Enketo-specific extension and use an Enketo
namespace. In either case the XForms are functional in ODK Collect, because
the addition is just ignored.

Requirement:

Visually link two questions together. Can be used for various features,
e.g. one question could be a comment on another question.

Proposal:

Add a namespaced `for"bind attribute, like this:

The for attribute contains a relative or absolute path to the question
it links with. So in combination with an appearance you could now visually
link these questions together in creative ways that regular XForm groups do
not allow. E.g. add a button to the linked question that when clicked shows
a modal containing the other question. There are no restrictions, special
assumptions or magic. A question could have multiple questions linked to it
for example.

If there is some enthusiasm for this I'll follow up with another more
specific proposal to build upon this XForm addition to create a very
flexible comment feature.

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

[martijnr]

Thanks Chris,

The use case that prompted this change was the desire to comment on
questions (similar to what SMAP server is doing on their ODK Collect fork -
but without the limitation it has beyond their use case) and enter those
comments by clicking a button next to the question that would reveal some
kind of modal. In addition, the presence or value of a comment would have
to allow bypassing validation. E.g. question A is required, unless there is
a comment on that question. So eventually after going through many complex
options, we can back to the idea that those comment questions should be
coded into the XForm like any other question. Any validation logic can thus
be coded normally with XPath. The additional benefit is that labels,
translations, hints, etc. are also completely flexible and don't have to be
hardcoded. I should also note that the client that has paid for this, will
have different types of 'comment' questions and one question could even
have multiple comment types. This is far beyond the scope of this proposal,
but it played a role in coming up with this implementation.

So to do this, we could use the "for" attribute to visually link from the
comment question to the question it links with. Any logic (relevant,
constraint) links are separate from that.

A client, such as Enketo or ODK Collect, would require only one more XForm
addition to respond to the use case described above, which is a new
appearance. The one I wanted to propose, if we make the "for" attribute an
official OpenRosa feature, is to use appearance="comment".

A second (optional) additional proposal would be to link the question node
in the model with the comment node(s) (note the link goes in a different
direction here). The objective would be to facilitate the presentation of
submitted data on the OpenRosa server for easy analysis without having to
evaluate the XPath expressions in "for" attributes in the XForm binds. That
addition would not be required or used by Enketo or ODK Collect. It's
purely for the server. Let me know if you want me to elaborate further on
this already.

Cheers,
Martijn

···

On Thursday, June 23, 2016 at 11:12:51 AM UTC-6, Christopher Robert wrote: > > Hi Martijn, > > Sounds interesting. Can you say any more about the likely use cases and > the additional specification extensions those might require? > > I ask only because it seems a bit difficult to think about this "linking > of questions" issue separated from the nature of the links themselves -- > and what other properties or parameters would be required to support those > types of links. For example, you might say that when field q3 has a > relevance expression like "q1+q2 < 100", then q3 is linked in a way with q1 > and q2: its visibility depends on q1 and q2. Likewise, constraints can > include links, labels can include links, and so we have varied ways in > which fields are already related to one another. And in a sense you can say > that all of the fields within a group (with the field-list appearance or > otherwise) are related. > > In none of those cases is a separate "for" construct necessary, and so it > gets me thinking about what other kinds of links might or might not require > (or benefit from) a "for" linkage. That's why I thought more use cases > might be useful, to determine whether they share the need for a new > "for"-type linkage, or if, like the existing linkages, they might be > somehow implicit or arranged in some other way. For example, if another > extension might be necessary to support modal pop-ups, then might that > extension itself not have its own way of specifying the linkages? > > Thanks, > > Chris > > On Thu, Jun 23, 2016 at 12:57 PM Martijn van de Rijdt <mar...@enketo.org > wrote: > >> Hi ODK Devs, >> >> We added some functionality to Enketo and wanted to propose a related >> addition to the OpenRosa/ODK XForm specification. >> >> If you agree with this addition to the XForms spec (or an alternative), >> I'll add it to the documentation and use the OpenRosa namespace. If, not >> we'll just consider it an Enketo-specific extension and use an Enketo >> namespace. In either case the XForms are functional in ODK Collect, because >> the addition is just ignored. >> >> *Requirement:* >> >> Visually link two questions together. Can be used for various features, >> e.g. one question could be a comment on another question. >> >> *Proposal*: >> >> Add a namespaced `for"bind attribute, like this: >> >> >> >> >> The `for` attribute contains a relative or absolute path to the question >> it links with. So in combination with an appearance you could now visually >> link these questions together in creative ways that regular XForm groups do >> not allow. E.g. add a button to the linked question that when clicked shows >> a modal containing the other question. There are no restrictions, special >> assumptions or magic. A question could have multiple questions linked to it >> for example. >> >> If there is some enthusiasm for this I'll follow up with another more >> specific proposal to build upon this XForm addition to create a very >> flexible comment feature. >> >> Cheers, >> 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. >> >

[crobert]

Okay, thanks! That helps.

It's still a bit unclear to me whether appearance+for is ideal vs. some
other way of specifying both the functionality desired and the link(s). For
example, if you wanted a comment on a set of questions rather than just
one, how would that happen? Using "for", you might get locked into a 1-to-1
design that turns out to be less than ideal for comment facilities.

As a point of reference (and, I realize, general irritation), we added
comment capability into SurveyCTO some years back. And we did it by adding
a new field type that would accept comments form-wide. So, essentially, if
you added a "comments" field to your form, then a context-menu option to
add a comment would be available survey-wide, and the comments field would
end up holding a .csv file with comments linked to the fields with which
they were associated. So, you might get no .csv file, a .csv file with a
single comment for a single field, or a .csv file with potentially lots of
comments. These comments were held separately from the core form data, in
separate (but attached) .csv files so that you could import and manage them
separately from your core analysis. It was ad-hoc and designed to meet some
users' needs, though certainly imperfectly. Client UI's could differ in how
they allowed addition of comments, but we used the same basic approach in
both our Android and web UI's (a context menu).

In my view, most users who want to accept comments likely want to accept
them either everywhere or at least in most places -- so having to code
comment fields separately, field-by-field, would be tremendously laborious
to the point of not being useful. That's just my opinion, though, and
obviously you have at least one client willing to pay for the
field-by-field option.

It also seems quite dangerous to allow any kind of blanket bypassing of
validation, so your approach to that (allowing them to code this into the
validation itself) seems like a really smart one. In a great many cases,
forms are designed such that people reasonably expect -- perhaps within the
logic and UI of the form itself, but certainly in the back-end processing
and analysis -- that required fields will be required and that constraints
will be enforced. Once you start allowing people to escape validation, the
design, testing, and analysis tasks become just so much more complex. While
we do have users who occasionally ask for blanket-validation-escape
options, we generally talk them out of it. And we haven't been willing to
build such things into SurveyCTO, believing that even those who request it
would be poorly served by the consequences.

Best,

Chris

···

On Fri, Jun 24, 2016 at 11:36 AM Martijn van de Rijdt wrote:

Thanks Chris,

The use case that prompted this change was the desire to comment on
questions (similar to what SMAP server is doing on their ODK Collect fork -
but without the limitation it has beyond their use case) and enter those
comments by clicking a button next to the question that would reveal some
kind of modal. In addition, the presence or value of a comment would have
to allow bypassing validation. E.g. question A is required, unless there is
a comment on that question. So eventually after going through many complex
options, we can back to the idea that those comment questions should be
coded into the XForm like any other question. Any validation logic can thus
be coded normally with XPath. The additional benefit is that labels,
translations, hints, etc. are also completely flexible and don't have to be
hardcoded. I should also note that the client that has paid for this, will
have different types of 'comment' questions and one question could even
have multiple comment types. This is far beyond the scope of this proposal,
but it played a role in coming up with this implementation.

So to do this, we could use the "for" attribute to visually link from
the comment question to the question it links with. Any logic (relevant,
constraint) links are separate from that.

A client, such as Enketo or ODK Collect, would require only one more XForm
addition to respond to the use case described above, which is a new
appearance. The one I wanted to propose, if we make the "for" attribute an
official OpenRosa feature, is to use appearance="comment".

A second (optional) additional proposal would be to link the question node
in the model with the comment node(s) (note the link goes in a different
direction here). The objective would be to facilitate the presentation of
submitted data on the OpenRosa server for easy analysis without having to
evaluate the XPath expressions in "for" attributes in the XForm binds. That
addition would not be required or used by Enketo or ODK Collect. It's
purely for the server. Let me know if you want me to elaborate further on
this already.

Cheers,
Martijn

On Thursday, June 23, 2016 at 11:12:51 AM UTC-6, Christopher Robert wrote:

Hi Martijn,

Sounds interesting. Can you say any more about the likely use cases and
the additional specification extensions those might require?

I ask only because it seems a bit difficult to think about this "linking
of questions" issue separated from the nature of the links themselves --
and what other properties or parameters would be required to support those
types of links. For example, you might say that when field q3 has a
relevance expression like "q1+q2 < 100", then q3 is linked in a way with q1
and q2: its visibility depends on q1 and q2. Likewise, constraints can
include links, labels can include links, and so we have varied ways in
which fields are already related to one another. And in a sense you can say
that all of the fields within a group (with the field-list appearance or
otherwise) are related.

In none of those cases is a separate "for" construct necessary, and so it
gets me thinking about what other kinds of links might or might not require
(or benefit from) a "for" linkage. That's why I thought more use cases
might be useful, to determine whether they share the need for a new
"for"-type linkage, or if, like the existing linkages, they might be
somehow implicit or arranged in some other way. For example, if another
extension might be necessary to support modal pop-ups, then might that
extension itself not have its own way of specifying the linkages?

Thanks,

Chris

On Thu, Jun 23, 2016 at 12:57 PM Martijn van de Rijdt mar...@enketo.org wrote:

Hi ODK Devs,

We added some functionality to Enketo and wanted to propose a related
addition to the OpenRosa/ODK XForm specification.

If you agree with this addition to the XForms spec (or an alternative),
I'll add it to the documentation and use the OpenRosa namespace. If, not
we'll just consider it an Enketo-specific extension and use an Enketo
namespace. In either case the XForms are functional in ODK Collect, because
the addition is just ignored.

Requirement:

Visually link two questions together. Can be used for various features,
e.g. one question could be a comment on another question.

Proposal:

Add a namespaced `for"bind attribute, like this:

The for attribute contains a relative or absolute path to the question
it links with. So in combination with an appearance you could now visually
link these questions together in creative ways that regular XForm groups do
not allow. E.g. add a button to the linked question that when clicked shows
a modal containing the other question. There are no restrictions, special
assumptions or magic. A question could have multiple questions linked to it
for example.

If there is some enthusiasm for this I'll follow up with another more
specific proposal to build upon this XForm addition to create a very
flexible comment feature.

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

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

[martijnr]

I much appreciate your comments, Chris.

For comments on several questions, this method would facilitate that by
pointing the "for" attribute to a group. It is one of the future
requirements we had in mind as well when designing this. So your past
requirement for one comment field for the whole form, could be met by
placing all questions in a group, and then creating a single comment
question that points to it. In that case, we may want to add flexibility
for positioning the comment button (e.g. with top, bottom appearances).

I agree with the laboriousness for per-question comments. The idea is that
this is only really workable for form-builders where you would just tick a
box and that would generate the XLSForm or XForm output automatically.

Yes, bypassing-validation with regular constraint and required XPath
expressions was really a key advantage that made us decide to go for this
approach, despite the laboriousness of hand-coding individual question
comments (in XForm or XLSForm).

Cheers,
Martijn

···

On Sat, Jun 25, 2016 at 12:10 AM, Christopher Robert wrote:

Okay, thanks! That helps.

It's still a bit unclear to me whether appearance+for is ideal vs. some
other way of specifying both the functionality desired and the link(s). For
example, if you wanted a comment on a set of questions rather than just
one, how would that happen? Using "for", you might get locked into a 1-to-1
design that turns out to be less than ideal for comment facilities.

As a point of reference (and, I realize, general irritation), we added
comment capability into SurveyCTO some years back. And we did it by adding
a new field type that would accept comments form-wide. So, essentially, if
you added a "comments" field to your form, then a context-menu option to
add a comment would be available survey-wide, and the comments field would
end up holding a .csv file with comments linked to the fields with which
they were associated. So, you might get no .csv file, a .csv file with a
single comment for a single field, or a .csv file with potentially lots of
comments. These comments were held separately from the core form data, in
separate (but attached) .csv files so that you could import and manage them
separately from your core analysis. It was ad-hoc and designed to meet some
users' needs, though certainly imperfectly. Client UI's could differ in how
they allowed addition of comments, but we used the same basic approach in
both our Android and web UI's (a context menu).

In my view, most users who want to accept comments likely want to accept
them either everywhere or at least in most places -- so having to code
comment fields separately, field-by-field, would be tremendously laborious
to the point of not being useful. That's just my opinion, though, and
obviously you have at least one client willing to pay for the
field-by-field option.

It also seems quite dangerous to allow any kind of blanket bypassing of
validation, so your approach to that (allowing them to code this into the
validation itself) seems like a really smart one. In a great many cases,
forms are designed such that people reasonably expect -- perhaps within the
logic and UI of the form itself, but certainly in the back-end processing
and analysis -- that required fields will be required and that constraints
will be enforced. Once you start allowing people to escape validation, the
design, testing, and analysis tasks become just so much more complex. While
we do have users who occasionally ask for blanket-validation-escape
options, we generally talk them out of it. And we haven't been willing to
build such things into SurveyCTO, believing that even those who request it
would be poorly served by the consequences.

Best,

Chris

On Fri, Jun 24, 2016 at 11:36 AM Martijn van de Rijdt martijn@enketo.org wrote:

Thanks Chris,

The use case that prompted this change was the desire to comment on
questions (similar to what SMAP server is doing on their ODK Collect fork -
but without the limitation it has beyond their use case) and enter those
comments by clicking a button next to the question that would reveal some
kind of modal. In addition, the presence or value of a comment would have
to allow bypassing validation. E.g. question A is required, unless there is
a comment on that question. So eventually after going through many complex
options, we can back to the idea that those comment questions should be
coded into the XForm like any other question. Any validation logic can thus
be coded normally with XPath. The additional benefit is that labels,
translations, hints, etc. are also completely flexible and don't have to be
hardcoded. I should also note that the client that has paid for this, will
have different types of 'comment' questions and one question could even
have multiple comment types. This is far beyond the scope of this proposal,
but it played a role in coming up with this implementation.

So to do this, we could use the "for" attribute to visually link from
the comment question to the question it links with. Any logic (relevant,
constraint) links are separate from that.

A client, such as Enketo or ODK Collect, would require only one more
XForm addition to respond to the use case described above, which is a new
appearance. The one I wanted to propose, if we make the "for" attribute an
official OpenRosa feature, is to use appearance="comment".

A second (optional) additional proposal would be to link the question
node in the model with the comment node(s) (note the link goes in a
different direction here). The objective would be to facilitate the
presentation of submitted data on the OpenRosa server for easy analysis
without having to evaluate the XPath expressions in "for" attributes in the
XForm binds. That addition would not be required or used by Enketo or ODK
Collect. It's purely for the server. Let me know if you want me to
elaborate further on this already.

Cheers,
Martijn

On Thursday, June 23, 2016 at 11:12:51 AM UTC-6, Christopher Robert wrote:

Hi Martijn,

Sounds interesting. Can you say any more about the likely use cases and
the additional specification extensions those might require?

I ask only because it seems a bit difficult to think about this "linking
of questions" issue separated from the nature of the links themselves --
and what other properties or parameters would be required to support those
types of links. For example, you might say that when field q3 has a
relevance expression like "q1+q2 < 100", then q3 is linked in a way with q1
and q2: its visibility depends on q1 and q2. Likewise, constraints can
include links, labels can include links, and so we have varied ways in
which fields are already related to one another. And in a sense you can say
that all of the fields within a group (with the field-list appearance or
otherwise) are related.

In none of those cases is a separate "for" construct necessary, and so
it gets me thinking about what other kinds of links might or might not
require (or benefit from) a "for" linkage. That's why I thought more use
cases might be useful, to determine whether they share the need for a new
"for"-type linkage, or if, like the existing linkages, they might be
somehow implicit or arranged in some other way. For example, if another
extension might be necessary to support modal pop-ups, then might that
extension itself not have its own way of specifying the linkages?

Thanks,

Chris

On Thu, Jun 23, 2016 at 12:57 PM Martijn van de Rijdt mar...@enketo.org wrote:

Hi ODK Devs,

We added some functionality to Enketo and wanted to propose a related
addition to the OpenRosa/ODK XForm specification.

If you agree with this addition to the XForms spec (or an alternative),
I'll add it to the documentation and use the OpenRosa namespace. If, not
we'll just consider it an Enketo-specific extension and use an Enketo
namespace. In either case the XForms are functional in ODK Collect, because
the addition is just ignored.

Requirement:

Visually link two questions together. Can be used for various features,
e.g. one question could be a comment on another question.

Proposal:

Add a namespaced `for"bind attribute, like this:

The for attribute contains a relative or absolute path to the
question it links with. So in combination with an appearance you could now
visually link these questions together in creative ways that regular XForm
groups do not allow. E.g. add a button to the linked question that when
clicked shows a modal containing the other question. There are no
restrictions, special assumptions or magic. A question could have multiple
questions linked to it for example.

If there is some enthusiasm for this I'll follow up with another more
specific proposal to build upon this XForm addition to create a very
flexible comment feature.

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

--
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/SaNMPr9eSyQ/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/

[martijnr]

Mitch, Yaw, Chris,

I wanted to see if we can come to a conclusion on whether the "for"
attribute should become part of the OpenRosa/ODK XForm spec. If you like
the approach and think you may want to leverage this in a future version of
ODK Collect, I'd say let's do it. Otherwise, we'll just treat this as a
custom Enketo extension, use a different namespace and document it
elsewhere. I'd be happy to discuss further as well of course.

Thanks,
Martijn

···

On Monday, June 27, 2016 at 9:52:11 AM UTC-6, Martijn van de Rijdt wrote: > > I much appreciate your comments, Chris. > > For comments on several questions, this method would facilitate that by > pointing the "for" attribute to a group. It is one of the future > requirements we had in mind as well when designing this. So your past > requirement for one comment field for the whole form, could be met by > placing all questions in a group, and then creating a single comment > question that points to it. In that case, we may want to add flexibility > for positioning the comment button (e.g. with top, bottom appearances). > > I agree with the laboriousness for per-question comments. The idea is that > this is only really workable for form-builders where you would just tick a > box and that would generate the XLSForm or XForm output automatically. > > Yes, bypassing-validation with regular constraint and required XPath > expressions was really a key advantage that made us decide to go for this > approach, despite the laboriousness of hand-coding individual question > comments (in XForm or XLSForm). > > Cheers, > Martijn > > On Sat, Jun 25, 2016 at 12:10 AM, Christopher Robert < crobert@surveycto.com> wrote: > >> Okay, thanks! That helps. >> >> It's still a bit unclear to me whether appearance+for is ideal vs. some >> other way of specifying both the functionality desired and the link(s). For >> example, if you wanted a comment on a set of questions rather than just >> one, how would that happen? Using "for", you might get locked into a 1-to-1 >> design that turns out to be less than ideal for comment facilities. >> >> As a point of reference (and, I realize, general irritation), we added >> comment capability into SurveyCTO some years back. And we did it by adding >> a new field type that would accept comments form-wide. So, essentially, if >> you added a "comments" field to your form, then a context-menu option to >> add a comment would be available survey-wide, and the comments field would >> end up holding a .csv file with comments linked to the fields with which >> they were associated. So, you might get no .csv file, a .csv file with a >> single comment for a single field, or a .csv file with potentially lots of >> comments. These comments were held separately from the core form data, in >> separate (but attached) .csv files so that you could import and manage them >> separately from your core analysis. It was ad-hoc and designed to meet some >> users' needs, though certainly imperfectly. Client UI's could differ in how >> they allowed addition of comments, but we used the same basic approach in >> both our Android and web UI's (a context menu). >> >> In my view, most users who want to accept comments likely want to accept >> them either everywhere or at least in most places -- so having to code >> comment fields separately, field-by-field, would be tremendously laborious >> to the point of not being useful. That's just my opinion, though, and >> obviously you have at least one client willing to pay for the >> field-by-field option. >> >> It also seems quite dangerous to allow any kind of blanket bypassing of >> validation, so your approach to that (allowing them to code this into the >> validation itself) seems like a really smart one. In a great many cases, >> forms are designed such that people reasonably expect -- perhaps within the >> logic and UI of the form itself, but certainly in the back-end processing >> and analysis -- that required fields will be required and that constraints >> will be enforced. Once you start allowing people to escape validation, the >> design, testing, and analysis tasks become just so much more complex. While >> we do have users who occasionally ask for blanket-validation-escape >> options, we generally talk them out of it. And we haven't been willing to >> build such things into SurveyCTO, believing that even those who request it >> would be poorly served by the consequences. >> >> Best, >> >> Chris >> >> On Fri, Jun 24, 2016 at 11:36 AM Martijn van de Rijdt wrote: >> >>> Thanks Chris, >>> >>> The use case that prompted this change was the desire to comment on >>> questions (similar to what SMAP server is doing on their ODK Collect fork - >>> but without the limitation it has beyond their use case) and enter those >>> comments by clicking a button next to the question that would reveal some >>> kind of modal. In addition, the presence or value of a comment would have >>> to allow bypassing validation. E.g. question A is required, unless there is >>> a comment on that question. So eventually after going through many complex >>> options, we can back to the idea that those comment questions should be >>> coded into the XForm like any other question. Any validation logic can thus >>> be coded normally with XPath. The additional benefit is that labels, >>> translations, hints, etc. are also completely flexible and don't have to be >>> hardcoded. I should also note that the client that has paid for this, will >>> have different types of 'comment' questions and one question could even >>> have multiple comment types. This is far beyond the scope of this proposal, >>> but it played a role in coming up with this implementation. >>> >>> So to do this, we could use the "for" attribute to *visually* link from >>> the comment question to the question it links with. Any logic (relevant, >>> constraint) links are separate from that. >>> >>> A client, such as Enketo or ODK Collect, would require only one more >>> XForm addition to respond to the use case described above, which is a new >>> appearance. The one I wanted to propose, if we make the "for" attribute an >>> official OpenRosa feature, is to use appearance="comment". >>> >>> A second (optional) additional proposal would be to link the question >>> node in the model with the comment node(s) (note the link goes in a >>> different direction here). The objective would be to facilitate the >>> presentation of submitted data on the OpenRosa server for easy analysis >>> without having to evaluate the XPath expressions in "for" attributes in the >>> XForm binds. That addition would not be required or used by Enketo or ODK >>> Collect. It's purely for the server. Let me know if you want me to >>> elaborate further on this already. >>> >>> Cheers, >>> Martijn >>> >>> >>> On Thursday, June 23, 2016 at 11:12:51 AM UTC-6, Christopher Robert wrote: >>> >>>> Hi Martijn, >>>> >>>> Sounds interesting. Can you say any more about the likely use cases and >>>> the additional specification extensions those might require? >>>> >>>> I ask only because it seems a bit difficult to think about this >>>> "linking of questions" issue separated from the nature of the links >>>> themselves -- and what other properties or parameters would be required to >>>> support those types of links. For example, you might say that when field q3 >>>> has a relevance expression like "q1+q2 < 100", then q3 is linked in a way >>>> with q1 and q2: its visibility depends on q1 and q2. Likewise, constraints >>>> can include links, labels can include links, and so we have varied ways in >>>> which fields are already related to one another. And in a sense you can say >>>> that all of the fields within a group (with the field-list appearance or >>>> otherwise) are related. >>>> >>>> In none of those cases is a separate "for" construct necessary, and so >>>> it gets me thinking about what other kinds of links might or might not >>>> require (or benefit from) a "for" linkage. That's why I thought more use >>>> cases might be useful, to determine whether they share the need for a new >>>> "for"-type linkage, or if, like the existing linkages, they might be >>>> somehow implicit or arranged in some other way. For example, if another >>>> extension might be necessary to support modal pop-ups, then might that >>>> extension itself not have its own way of specifying the linkages? >>>> >>>> Thanks, >>>> >>>> Chris >>>> >>> >>>> >>>> On Thu, Jun 23, 2016 at 12:57 PM Martijn van de Rijdt < mar...@enketo.org> wrote: >>>> >>>>> Hi ODK Devs, >>>>> >>>>> We added some functionality to Enketo and wanted to propose a related >>>>> addition to the OpenRosa/ODK XForm specification. >>>>> >>>>> If you agree with this addition to the XForms spec (or an >>>>> alternative), I'll add it to the documentation and use the OpenRosa >>>>> namespace. If, not we'll just consider it an Enketo-specific extension and >>>>> use an Enketo namespace. In either case the XForms are functional in ODK >>>>> Collect, because the addition is just ignored. >>>>> >>>>> *Requirement:* >>>>> >>>>> Visually link two questions together. Can be used for various >>>>> features, e.g. one question could be a comment on another question. >>>>> >>>>> *Proposal*: >>>>> >>>>> Add a namespaced `for"bind attribute, like this: >>>>> >>>>> >>>>> >>>>> >>>>> The `for` attribute contains a relative or absolute path to the >>>>> question it links with. So in combination with an appearance you could now >>>>> visually link these questions together in creative ways that regular XForm >>>>> groups do not allow. E.g. add a button to the linked question that when >>>>> clicked shows a modal containing the other question. There are no >>>>> restrictions, special assumptions or magic. A question could have multiple >>>>> questions linked to it for example. >>>>> >>>>> If there is some enthusiasm for this I'll follow up with another more >>>>> specific proposal to build upon this XForm addition to create a very >>>>> flexible comment feature. >>>>> >>>>> Cheers, >>>>> 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. >>>>> >>>> >>> -- >>> *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/SaNMPr9eSyQ/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 >

[crobert]

Hi Martijn,

Thanks for always getting input -- even when it means you'll get random and
differing opinions!

Even if this became part of the spec, I don't honestly think that we'd
spend the time to integrate or document it in SurveyCTO. We just have about
600 higher priorities from users, and our desire to support commenting was
more or less addressed by our form-wide comment facility long ago.

While I agree in principle with the idea that comments should be better
supported in-spec, we'd still push for something simpler and form-wide,
just because we've gotten consistent positive or neutral feedback on that
(never had anybody want group-by-group or field-by-field that I can
remember). But that's just my opinion based on our interactions with
SurveyCTO users.

Best,

Chris

···

On Tue, Jul 12, 2016 at 11:44 AM Martijn van de Rijdt wrote:

Mitch, Yaw, Chris,

I wanted to see if we can come to a conclusion on whether the "for"
attribute should become part of the OpenRosa/ODK XForm spec. If you like
the approach and think you may want to leverage this in a future version of
ODK Collect, I'd say let's do it. Otherwise, we'll just treat this as a
custom Enketo extension, use a different namespace and document it
elsewhere. I'd be happy to discuss further as well of course.

Thanks,
Martijn

On Monday, June 27, 2016 at 9:52:11 AM UTC-6, Martijn van de Rijdt wrote:

I much appreciate your comments, Chris.

For comments on several questions, this method would facilitate that by
pointing the "for" attribute to a group. It is one of the future
requirements we had in mind as well when designing this. So your past
requirement for one comment field for the whole form, could be met by
placing all questions in a group, and then creating a single comment
question that points to it. In that case, we may want to add flexibility
for positioning the comment button (e.g. with top, bottom appearances).

I agree with the laboriousness for per-question comments. The idea is
that this is only really workable for form-builders where you would just
tick a box and that would generate the XLSForm or XForm output
automatically.

Yes, bypassing-validation with regular constraint and required XPath
expressions was really a key advantage that made us decide to go for this
approach, despite the laboriousness of hand-coding individual question
comments (in XForm or XLSForm).

Cheers,
Martijn

On Sat, Jun 25, 2016 at 12:10 AM, Christopher Robert < crobert@surveycto.com> wrote:

Okay, thanks! That helps.

It's still a bit unclear to me whether appearance+for is ideal vs. some
other way of specifying both the functionality desired and the link(s). For
example, if you wanted a comment on a set of questions rather than just
one, how would that happen? Using "for", you might get locked into a 1-to-1
design that turns out to be less than ideal for comment facilities.

As a point of reference (and, I realize, general irritation), we added
comment capability into SurveyCTO some years back. And we did it by adding
a new field type that would accept comments form-wide. So, essentially, if
you added a "comments" field to your form, then a context-menu option to
add a comment would be available survey-wide, and the comments field would
end up holding a .csv file with comments linked to the fields with which
they were associated. So, you might get no .csv file, a .csv file with a
single comment for a single field, or a .csv file with potentially lots of
comments. These comments were held separately from the core form data, in
separate (but attached) .csv files so that you could import and manage them
separately from your core analysis. It was ad-hoc and designed to meet some
users' needs, though certainly imperfectly. Client UI's could differ in how
they allowed addition of comments, but we used the same basic approach in
both our Android and web UI's (a context menu).

In my view, most users who want to accept comments likely want to accept
them either everywhere or at least in most places -- so having to code
comment fields separately, field-by-field, would be tremendously laborious
to the point of not being useful. That's just my opinion, though, and
obviously you have at least one client willing to pay for the
field-by-field option.

It also seems quite dangerous to allow any kind of blanket bypassing of
validation, so your approach to that (allowing them to code this into the
validation itself) seems like a really smart one. In a great many cases,
forms are designed such that people reasonably expect -- perhaps within the
logic and UI of the form itself, but certainly in the back-end processing
and analysis -- that required fields will be required and that constraints
will be enforced. Once you start allowing people to escape validation, the
design, testing, and analysis tasks become just so much more complex. While
we do have users who occasionally ask for blanket-validation-escape
options, we generally talk them out of it. And we haven't been willing to
build such things into SurveyCTO, believing that even those who request it
would be poorly served by the consequences.

Best,

Chris

On Fri, Jun 24, 2016 at 11:36 AM Martijn van de Rijdt < martijn@enketo.org> wrote:

Thanks Chris,

The use case that prompted this change was the desire to comment on
questions (similar to what SMAP server is doing on their ODK Collect fork -
but without the limitation it has beyond their use case) and enter those
comments by clicking a button next to the question that would reveal some
kind of modal. In addition, the presence or value of a comment would have
to allow bypassing validation. E.g. question A is required, unless there is
a comment on that question. So eventually after going through many complex
options, we can back to the idea that those comment questions should be
coded into the XForm like any other question. Any validation logic can thus
be coded normally with XPath. The additional benefit is that labels,
translations, hints, etc. are also completely flexible and don't have to be
hardcoded. I should also note that the client that has paid for this, will
have different types of 'comment' questions and one question could even
have multiple comment types. This is far beyond the scope of this proposal,
but it played a role in coming up with this implementation.

So to do this, we could use the "for" attribute to visually link
from the comment question to the question it links with. Any logic
(relevant, constraint) links are separate from that.

A client, such as Enketo or ODK Collect, would require only one more
XForm addition to respond to the use case described above, which is a new
appearance. The one I wanted to propose, if we make the "for" attribute an
official OpenRosa feature, is to use appearance="comment".

A second (optional) additional proposal would be to link the question
node in the model with the comment node(s) (note the link goes in a
different direction here). The objective would be to facilitate the
presentation of submitted data on the OpenRosa server for easy analysis
without having to evaluate the XPath expressions in "for" attributes in the
XForm binds. That addition would not be required or used by Enketo or ODK
Collect. It's purely for the server. Let me know if you want me to
elaborate further on this already.

Cheers,
Martijn

On Thursday, June 23, 2016 at 11:12:51 AM UTC-6, Christopher Robert wrote:

Hi Martijn,

Sounds interesting. Can you say any more about the likely use cases
and the additional specification extensions those might require?

I ask only because it seems a bit difficult to think about this
"linking of questions" issue separated from the nature of the links
themselves -- and what other properties or parameters would be required to
support those types of links. For example, you might say that when field q3
has a relevance expression like "q1+q2 < 100", then q3 is linked in a way
with q1 and q2: its visibility depends on q1 and q2. Likewise, constraints
can include links, labels can include links, and so we have varied ways in
which fields are already related to one another. And in a sense you can say
that all of the fields within a group (with the field-list appearance or
otherwise) are related.

In none of those cases is a separate "for" construct necessary, and so
it gets me thinking about what other kinds of links might or might not
require (or benefit from) a "for" linkage. That's why I thought more use
cases might be useful, to determine whether they share the need for a new
"for"-type linkage, or if, like the existing linkages, they might be
somehow implicit or arranged in some other way. For example, if another
extension might be necessary to support modal pop-ups, then might that
extension itself not have its own way of specifying the linkages?

Thanks,

Chris

On Thu, Jun 23, 2016 at 12:57 PM Martijn van de Rijdt < mar...@enketo.org> wrote:

Hi ODK Devs,

We added some functionality to Enketo and wanted to propose a related
addition to the OpenRosa/ODK XForm specification.

If you agree with this addition to the XForms spec (or an
alternative), I'll add it to the documentation and use the OpenRosa
namespace. If, not we'll just consider it an Enketo-specific extension and
use an Enketo namespace. In either case the XForms are functional in ODK
Collect, because the addition is just ignored.

Requirement:

Visually link two questions together. Can be used for various
features, e.g. one question could be a comment on another question.

Proposal:

Add a namespaced `for"bind attribute, like this:

The for attribute contains a relative or absolute path to the
question it links with. So in combination with an appearance you could now
visually link these questions together in creative ways that regular XForm
groups do not allow. E.g. add a button to the linked question that when
clicked shows a modal containing the other question. There are no
restrictions, special assumptions or magic. A question could have multiple
questions linked to it for example.

If there is some enthusiasm for this I'll follow up with another more
specific proposal to build upon this XForm addition to create a very
flexible comment feature.

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

--
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/SaNMPr9eSyQ/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/

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

[martijnr]

Thanks Chris,

Thinking some more about form-wide global comment requirement, I think it
would be elegantly covered like this (where "data" is the root node in the
primary instance) without groups:

But indeed for global comments (only), you wouldn't necessarily need the
"for" attribute. Using it you'll be able to extend it further in the future
though, in case users ever want question- or group-level comments. Some
Enketo and SMAP users already have this requirement, so it seems possible
that might happen.

Anyway, no problem to make it an enketo-specific extension either. Will
wait a few days in case Yaw, Mitch, you, and others, have additional input
and otherwise proceed.

Cheers,
Martijn

···

On Tuesday, July 12, 2016 at 10:09:23 AM UTC-6, Christopher Robert wrote: > > Hi Martijn, > > Thanks for always getting input -- even when it means you'll get random > and differing opinions! > > Even if this became part of the spec, I don't honestly think that we'd > spend the time to integrate or document it in SurveyCTO. We just have about > 600 higher priorities from users, and our desire to support commenting was > more or less addressed by our form-wide comment facility long ago. > > While I agree in principle with the idea that comments should be better > supported in-spec, we'd still push for something simpler and form-wide, > just because we've gotten consistent positive or neutral feedback on that > (never had anybody want group-by-group or field-by-field that I can > remember). But that's just my opinion based on our interactions with > SurveyCTO users. > > Best, > > Chris > > On Tue, Jul 12, 2016 at 11:44 AM Martijn van de Rijdt <mar...@enketo.org > wrote: > >> Mitch, Yaw, Chris, >> >> I wanted to see if we can come to a conclusion on whether the "for" >> attribute should become part of the OpenRosa/ODK XForm spec. If you like >> the approach and think you may want to leverage this in a future version of >> ODK Collect, I'd say let's do it. Otherwise, we'll just treat this as a >> custom Enketo extension, use a different namespace and document it >> elsewhere. I'd be happy to discuss further as well of course. >> >> Thanks, >> Martijn >> >> On Monday, June 27, 2016 at 9:52:11 AM UTC-6, Martijn van de Rijdt wrote: >>> >>> I much appreciate your comments, Chris. >>> >>> For comments on several questions, this method would facilitate that by >>> pointing the "for" attribute to a group. It is one of the future >>> requirements we had in mind as well when designing this. So your past >>> requirement for one comment field for the whole form, could be met by >>> placing all questions in a group, and then creating a single comment >>> question that points to it. In that case, we may want to add flexibility >>> for positioning the comment button (e.g. with top, bottom appearances). >>> >>> I agree with the laboriousness for per-question comments. The idea is >>> that this is only really workable for form-builders where you would just >>> tick a box and that would generate the XLSForm or XForm output >>> automatically. >>> >>> Yes, bypassing-validation with regular constraint and required XPath >>> expressions was really a key advantage that made us decide to go for this >>> approach, despite the laboriousness of hand-coding individual question >>> comments (in XForm or XLSForm). >>> >>> Cheers, >>> Martijn >>> >>> On Sat, Jun 25, 2016 at 12:10 AM, Christopher Robert < cro...@surveycto.com > wrote: >>> >>>> Okay, thanks! That helps. >>>> >>>> It's still a bit unclear to me whether appearance+for is ideal vs. some >>>> other way of specifying both the functionality desired and the link(s). For >>>> example, if you wanted a comment on a set of questions rather than just >>>> one, how would that happen? Using "for", you might get locked into a 1-to-1 >>>> design that turns out to be less than ideal for comment facilities. >>>> >>>> As a point of reference (and, I realize, general irritation), we added >>>> comment capability into SurveyCTO some years back. And we did it by adding >>>> a new field type that would accept comments form-wide. So, essentially, if >>>> you added a "comments" field to your form, then a context-menu option to >>>> add a comment would be available survey-wide, and the comments field would >>>> end up holding a .csv file with comments linked to the fields with which >>>> they were associated. So, you might get no .csv file, a .csv file with a >>>> single comment for a single field, or a .csv file with potentially lots of >>>> comments. These comments were held separately from the core form data, in >>>> separate (but attached) .csv files so that you could import and manage them >>>> separately from your core analysis. It was ad-hoc and designed to meet some >>>> users' needs, though certainly imperfectly. Client UI's could differ in how >>>> they allowed addition of comments, but we used the same basic approach in >>>> both our Android and web UI's (a context menu). >>>> >>>> In my view, most users who want to accept comments likely want to >>>> accept them either everywhere or at least in most places -- so having to >>>> code comment fields separately, field-by-field, would be tremendously >>>> laborious to the point of not being useful. That's just my opinion, though, >>>> and obviously you have at least one client willing to pay for the >>>> field-by-field option. >>>> >>>> It also seems quite dangerous to allow any kind of blanket bypassing of >>>> validation, so your approach to that (allowing them to code this into the >>>> validation itself) seems like a really smart one. In a great many cases, >>>> forms are designed such that people reasonably expect -- perhaps within the >>>> logic and UI of the form itself, but certainly in the back-end processing >>>> and analysis -- that required fields will be required and that constraints >>>> will be enforced. Once you start allowing people to escape validation, the >>>> design, testing, and analysis tasks become just so much more complex. While >>>> we do have users who occasionally ask for blanket-validation-escape >>>> options, we generally talk them out of it. And we haven't been willing to >>>> build such things into SurveyCTO, believing that even those who request it >>>> would be poorly served by the consequences. >>>> >>>> Best, >>>> >>>> Chris >>>> >>>> On Fri, Jun 24, 2016 at 11:36 AM Martijn van de Rijdt < mar...@enketo.org > wrote: >>>> >>>>> Thanks Chris, >>>>> >>>>> The use case that prompted this change was the desire to comment on >>>>> questions (similar to what SMAP server is doing on their ODK Collect fork - >>>>> but without the limitation it has beyond their use case) and enter those >>>>> comments by clicking a button next to the question that would reveal some >>>>> kind of modal. In addition, the presence or value of a comment would have >>>>> to allow bypassing validation. E.g. question A is required, unless there is >>>>> a comment on that question. So eventually after going through many complex >>>>> options, we can back to the idea that those comment questions should be >>>>> coded into the XForm like any other question. Any validation logic can thus >>>>> be coded normally with XPath. The additional benefit is that labels, >>>>> translations, hints, etc. are also completely flexible and don't have to be >>>>> hardcoded. I should also note that the client that has paid for this, will >>>>> have different types of 'comment' questions and one question could even >>>>> have multiple comment types. This is far beyond the scope of this proposal, >>>>> but it played a role in coming up with this implementation. >>>>> >>>>> So to do this, we could use the "for" attribute to *visually* link >>>>> from the comment question to the question it links with. Any logic >>>>> (relevant, constraint) links are separate from that. >>>>> >>>>> A client, such as Enketo or ODK Collect, would require only one more >>>>> XForm addition to respond to the use case described above, which is a new >>>>> appearance. The one I wanted to propose, if we make the "for" attribute an >>>>> official OpenRosa feature, is to use appearance="comment". >>>>> >>>>> A second (optional) additional proposal would be to link the question >>>>> node in the model with the comment node(s) (note the link goes in a >>>>> different direction here). The objective would be to facilitate the >>>>> presentation of submitted data on the OpenRosa server for easy analysis >>>>> without having to evaluate the XPath expressions in "for" attributes in the >>>>> XForm binds. That addition would not be required or used by Enketo or ODK >>>>> Collect. It's purely for the server. Let me know if you want me to >>>>> elaborate further on this already. >>>>> >>>>> Cheers, >>>>> Martijn >>>>> >>>>> >>>>> On Thursday, June 23, 2016 at 11:12:51 AM UTC-6, Christopher Robert wrote: >>>>> >>>>>> Hi Martijn, >>>>>> >>>>>> Sounds interesting. Can you say any more about the likely use cases >>>>>> and the additional specification extensions those might require? >>>>>> >>>>>> I ask only because it seems a bit difficult to think about this >>>>>> "linking of questions" issue separated from the nature of the links >>>>>> themselves -- and what other properties or parameters would be required to >>>>>> support those types of links. For example, you might say that when field q3 >>>>>> has a relevance expression like "q1+q2 < 100", then q3 is linked in a way >>>>>> with q1 and q2: its visibility depends on q1 and q2. Likewise, constraints >>>>>> can include links, labels can include links, and so we have varied ways in >>>>>> which fields are already related to one another. And in a sense you can say >>>>>> that all of the fields within a group (with the field-list appearance or >>>>>> otherwise) are related. >>>>>> >>>>>> In none of those cases is a separate "for" construct necessary, and >>>>>> so it gets me thinking about what other kinds of links might or might not >>>>>> require (or benefit from) a "for" linkage. That's why I thought more use >>>>>> cases might be useful, to determine whether they share the need for a new >>>>>> "for"-type linkage, or if, like the existing linkages, they might be >>>>>> somehow implicit or arranged in some other way. For example, if another >>>>>> extension might be necessary to support modal pop-ups, then might that >>>>>> extension itself not have its own way of specifying the linkages? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Chris >>>>>> >>>>> >>>>>> >>>>>> On Thu, Jun 23, 2016 at 12:57 PM Martijn van de Rijdt < mar...@enketo.org> wrote: >>>>>> >>>>>>> Hi ODK Devs, >>>>>>> >>>>>>> We added some functionality to Enketo and wanted to propose a >>>>>>> related addition to the OpenRosa/ODK XForm specification. >>>>>>> >>>>>>> If you agree with this addition to the XForms spec (or an >>>>>>> alternative), I'll add it to the documentation and use the OpenRosa >>>>>>> namespace. If, not we'll just consider it an Enketo-specific extension and >>>>>>> use an Enketo namespace. In either case the XForms are functional in ODK >>>>>>> Collect, because the addition is just ignored. >>>>>>> >>>>>>> *Requirement:* >>>>>>> >>>>>>> Visually link two questions together. Can be used for various >>>>>>> features, e.g. one question could be a comment on another question. >>>>>>> >>>>>>> *Proposal*: >>>>>>> >>>>>>> Add a namespaced `for"bind attribute, like this: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The `for` attribute contains a relative or absolute path to the >>>>>>> question it links with. So in combination with an appearance you could now >>>>>>> visually link these questions together in creative ways that regular XForm >>>>>>> groups do not allow. E.g. add a button to the linked question that when >>>>>>> clicked shows a modal containing the other question. There are no >>>>>>> restrictions, special assumptions or magic. A question could have multiple >>>>>>> questions linked to it for example. >>>>>>> >>>>>>> If there is some enthusiasm for this I'll follow up with another >>>>>>> more specific proposal to build upon this XForm addition to create a very >>>>>>> flexible comment feature. >>>>>>> >>>>>>> Cheers, >>>>>>> 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. >>>>>>> >>>>>> >>>>> -- >>>>> *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/SaNMPr9eSyQ/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 >>> >> >> -- >> *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. >> >

[Mitch_S]

Note that in ODK Collect, in order to have the comment appear on the same
page as the question, it is *required *that they both be wrapped in a begin
group .. end group with "field-list" appearance.

This is also crucial for enabling or disabling constraint checks on the
questions, as the constraints are enforced on forward swipe out of the
page. If the presence of a comment is to disable the constraint, then the
comment field must be filled on the same page as the question or group of
questions it should impact.

This is central to the processing within ODK Collect and would not be
changed.

So any forms generator would need to wrap the question and comment in a
group in order for ODK Collect to properly handle them.

In that context, it seems like the orx:for attribute and comment appearance
wouldn't provide much value-add within ODK Collect. Given how difficult it
is to combine and re-structure the underlying Java views of questions to
produce the "label" and "list-no-label" layouts, I don't envision anyone
contributing an implementation to provide any visual support for this
within ODK Collect.

···

---------- I would have the the for attribute and comment appearance be Enketo extensions.

But you need to think carefully about how to wrap these extensions in
field-list groups if you want your forms to be usable on ODK Collect.

On Tue, Jul 12, 2016 at 10:18 AM, Martijn van de Rijdt martijn@enketo.org wrote:

Thanks Chris,

Thinking some more about form-wide global comment requirement, I think it
would be elegantly covered like this (where "data" is the root node in the
primary instance) without groups:

But indeed for global comments (only), you wouldn't necessarily need the
"for" attribute. Using it you'll be able to extend it further in the future
though, in case users ever want question- or group-level comments. Some
Enketo and SMAP users already have this requirement, so it seems possible
that might happen.

Anyway, no problem to make it an enketo-specific extension either. Will
wait a few days in case Yaw, Mitch, you, and others, have additional input
and otherwise proceed.

Cheers,
Martijn

On Tuesday, July 12, 2016 at 10:09:23 AM UTC-6, Christopher Robert wrote:

Hi Martijn,

Thanks for always getting input -- even when it means you'll get random
and differing opinions!

Even if this became part of the spec, I don't honestly think that we'd
spend the time to integrate or document it in SurveyCTO. We just have about
600 higher priorities from users, and our desire to support commenting was
more or less addressed by our form-wide comment facility long ago.

While I agree in principle with the idea that comments should be better
supported in-spec, we'd still push for something simpler and form-wide,
just because we've gotten consistent positive or neutral feedback on that
(never had anybody want group-by-group or field-by-field that I can
remember). But that's just my opinion based on our interactions with
SurveyCTO users.

Best,

Chris

On Tue, Jul 12, 2016 at 11:44 AM Martijn van de Rijdt mar...@enketo.org wrote:

Mitch, Yaw, Chris,

I wanted to see if we can come to a conclusion on whether the "for"
attribute should become part of the OpenRosa/ODK XForm spec. If you like
the approach and think you may want to leverage this in a future version of
ODK Collect, I'd say let's do it. Otherwise, we'll just treat this as a
custom Enketo extension, use a different namespace and document it
elsewhere. I'd be happy to discuss further as well of course.

Thanks,
Martijn

On Monday, June 27, 2016 at 9:52:11 AM UTC-6, Martijn van de Rijdt wrote:

I much appreciate your comments, Chris.

For comments on several questions, this method would facilitate that by
pointing the "for" attribute to a group. It is one of the future
requirements we had in mind as well when designing this. So your past
requirement for one comment field for the whole form, could be met by
placing all questions in a group, and then creating a single comment
question that points to it. In that case, we may want to add flexibility
for positioning the comment button (e.g. with top, bottom appearances).

I agree with the laboriousness for per-question comments. The idea is
that this is only really workable for form-builders where you would just
tick a box and that would generate the XLSForm or XForm output
automatically.

Yes, bypassing-validation with regular constraint and required XPath
expressions was really a key advantage that made us decide to go for this
approach, despite the laboriousness of hand-coding individual question
comments (in XForm or XLSForm).

Cheers,
Martijn

On Sat, Jun 25, 2016 at 12:10 AM, Christopher Robert < cro...@surveycto.com> wrote:

Okay, thanks! That helps.

It's still a bit unclear to me whether appearance+for is ideal vs.
some other way of specifying both the functionality desired and the
link(s). For example, if you wanted a comment on a set of questions rather
than just one, how would that happen? Using "for", you might get locked
into a 1-to-1 design that turns out to be less than ideal for comment
facilities.

As a point of reference (and, I realize, general irritation), we added
comment capability into SurveyCTO some years back. And we did it by adding
a new field type that would accept comments form-wide. So, essentially, if
you added a "comments" field to your form, then a context-menu option to
add a comment would be available survey-wide, and the comments field would
end up holding a .csv file with comments linked to the fields with which
they were associated. So, you might get no .csv file, a .csv file with a
single comment for a single field, or a .csv file with potentially lots of
comments. These comments were held separately from the core form data, in
separate (but attached) .csv files so that you could import and manage them
separately from your core analysis. It was ad-hoc and designed to meet some
users' needs, though certainly imperfectly. Client UI's could differ in how
they allowed addition of comments, but we used the same basic approach in
both our Android and web UI's (a context menu).

In my view, most users who want to accept comments likely want to
accept them either everywhere or at least in most places -- so having to
code comment fields separately, field-by-field, would be tremendously
laborious to the point of not being useful. That's just my opinion, though,
and obviously you have at least one client willing to pay for the
field-by-field option.

It also seems quite dangerous to allow any kind of blanket bypassing
of validation, so your approach to that (allowing them to code this into
the validation itself) seems like a really smart one. In a great many
cases, forms are designed such that people reasonably expect -- perhaps
within the logic and UI of the form itself, but certainly in the back-end
processing and analysis -- that required fields will be required and that
constraints will be enforced. Once you start allowing people to escape
validation, the design, testing, and analysis tasks become just so much
more complex. While we do have users who occasionally ask for
blanket-validation-escape options, we generally talk them out of it. And we
haven't been willing to build such things into SurveyCTO, believing that
even those who request it would be poorly served by the consequences.

Best,

Chris

On Fri, Jun 24, 2016 at 11:36 AM Martijn van de Rijdt < mar...@enketo.org> wrote:

Thanks Chris,

The use case that prompted this change was the desire to comment on
questions (similar to what SMAP server is doing on their ODK Collect fork -
but without the limitation it has beyond their use case) and enter those
comments by clicking a button next to the question that would reveal some
kind of modal. In addition, the presence or value of a comment would have
to allow bypassing validation. E.g. question A is required, unless there is
a comment on that question. So eventually after going through many complex
options, we can back to the idea that those comment questions should be
coded into the XForm like any other question. Any validation logic can thus
be coded normally with XPath. The additional benefit is that labels,
translations, hints, etc. are also completely flexible and don't have to be
hardcoded. I should also note that the client that has paid for this, will
have different types of 'comment' questions and one question could even
have multiple comment types. This is far beyond the scope of this proposal,
but it played a role in coming up with this implementation.

So to do this, we could use the "for" attribute to visually link
from the comment question to the question it links with. Any logic
(relevant, constraint) links are separate from that.

A client, such as Enketo or ODK Collect, would require only one more
XForm addition to respond to the use case described above, which is a new
appearance. The one I wanted to propose, if we make the "for" attribute an
official OpenRosa feature, is to use appearance="comment".

A second (optional) additional proposal would be to link the question
node in the model with the comment node(s) (note the link goes in a
different direction here). The objective would be to facilitate the
presentation of submitted data on the OpenRosa server for easy analysis
without having to evaluate the XPath expressions in "for" attributes in the
XForm binds. That addition would not be required or used by Enketo or ODK
Collect. It's purely for the server. Let me know if you want me to
elaborate further on this already.

Cheers,
Martijn

On Thursday, June 23, 2016 at 11:12:51 AM UTC-6, Christopher Robert wrote:

Hi Martijn,

Sounds interesting. Can you say any more about the likely use cases
and the additional specification extensions those might require?

I ask only because it seems a bit difficult to think about this
"linking of questions" issue separated from the nature of the links
themselves -- and what other properties or parameters would be required to
support those types of links. For example, you might say that when field q3
has a relevance expression like "q1+q2 < 100", then q3 is linked in a way
with q1 and q2: its visibility depends on q1 and q2. Likewise, constraints
can include links, labels can include links, and so we have varied ways in
which fields are already related to one another. And in a sense you can say
that all of the fields within a group (with the field-list appearance or
otherwise) are related.

In none of those cases is a separate "for" construct necessary, and
so it gets me thinking about what other kinds of links might or might not
require (or benefit from) a "for" linkage. That's why I thought more use
cases might be useful, to determine whether they share the need for a new
"for"-type linkage, or if, like the existing linkages, they might be
somehow implicit or arranged in some other way. For example, if another
extension might be necessary to support modal pop-ups, then might that
extension itself not have its own way of specifying the linkages?

Thanks,

Chris

On Thu, Jun 23, 2016 at 12:57 PM Martijn van de Rijdt < mar...@enketo.org> wrote:

Hi ODK Devs,

We added some functionality to Enketo and wanted to propose a
related addition to the OpenRosa/ODK XForm specification.

If you agree with this addition to the XForms spec (or an
alternative), I'll add it to the documentation and use the OpenRosa
namespace. If, not we'll just consider it an Enketo-specific extension and
use an Enketo namespace. In either case the XForms are functional in ODK
Collect, because the addition is just ignored.

Requirement:

Visually link two questions together. Can be used for various
features, e.g. one question could be a comment on another question.

Proposal:

Add a namespaced `for"bind attribute, like this:

The for attribute contains a relative or absolute path to the
question it links with. So in combination with an appearance you could now
visually link these questions together in creative ways that regular XForm
groups do not allow. E.g. add a button to the linked question that when
clicked shows a modal containing the other question. There are no
restrictions, special assumptions or magic. A question could have multiple
questions linked to it for example.

If there is some enthusiasm for this I'll follow up with another
more specific proposal to build upon this XForm addition to create a very
flexible comment feature.

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

--
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/SaNMPr9eSyQ/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/

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

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

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

[martijnr]

Thanks Mitch. I understand. It will be implemented as a custom extension
(in Enketo) using the http://enketo.org/xforms namespace.

···

On Wednesday, July 13, 2016 at 12:18:43 PM UTC-6, Mitch wrote: > > Note that in ODK Collect, in order to have the comment appear on the same > page as the question, it is *required *that they both be wrapped in a > begin group .. end group with "field-list" appearance. > > This is also crucial for enabling or disabling constraint checks on the > questions, as *the constraints are enforced on forward swipe out of the > page*. If the presence of a comment is to disable the constraint, then > the comment field must be filled on the same page as the question or group > of questions it should impact. > > This is central to the processing within ODK Collect and would not be > changed. > > So any forms generator would need to wrap the question and comment in a > group in order for ODK Collect to properly handle them. > > In that context, it seems like the orx:for attribute and comment > appearance wouldn't provide much value-add within ODK Collect. Given how > difficult it is to combine and re-structure the underlying Java views of > questions to produce the "label" and "list-no-label" layouts, I don't > envision anyone contributing an implementation to provide any visual > support for this within ODK Collect. > > ---------- > I would have the the for attribute and comment appearance be Enketo > extensions. > > But you need to think carefully about how to wrap these extensions in > field-list groups if you want your forms to be usable on ODK Collect. > > > > On Tue, Jul 12, 2016 at 10:18 AM, Martijn van de Rijdt <mar...@enketo.org > wrote: > >> Thanks Chris, >> >> Thinking some more about form-wide global comment requirement, I think it >> would be elegantly covered like this (where "data" is the root node in the >> primary instance) without groups: >> >> >> >> But indeed for global comments (only), you wouldn't necessarily need the >> "for" attribute. Using it you'll be able to extend it further in the future >> though, in case users ever want question- or group-level comments. Some >> Enketo and SMAP users already have this requirement, so it seems possible >> that might happen. >> >> Anyway, no problem to make it an enketo-specific extension either. Will >> wait a few days in case Yaw, Mitch, you, and others, have additional input >> and otherwise proceed. >> >> Cheers, >> Martijn >> >> On Tuesday, July 12, 2016 at 10:09:23 AM UTC-6, Christopher Robert wrote: >>> >>> Hi Martijn, >>> >>> Thanks for always getting input -- even when it means you'll get random >>> and differing opinions! >>> >>> Even if this became part of the spec, I don't honestly think that we'd >>> spend the time to integrate or document it in SurveyCTO. We just have about >>> 600 higher priorities from users, and our desire to support commenting was >>> more or less addressed by our form-wide comment facility long ago. >>> >>> While I agree in principle with the idea that comments should be better >>> supported in-spec, we'd still push for something simpler and form-wide, >>> just because we've gotten consistent positive or neutral feedback on that >>> (never had anybody want group-by-group or field-by-field that I can >>> remember). But that's just my opinion based on our interactions with >>> SurveyCTO users. >>> >>> Best, >>> >>> Chris >>> >>> On Tue, Jul 12, 2016 at 11:44 AM Martijn van de Rijdt wrote: >>> >>>> Mitch, Yaw, Chris, >>>> >>>> I wanted to see if we can come to a conclusion on whether the "for" >>>> attribute should become part of the OpenRosa/ODK XForm spec. If you like >>>> the approach and think you may want to leverage this in a future version of >>>> ODK Collect, I'd say let's do it. Otherwise, we'll just treat this as a >>>> custom Enketo extension, use a different namespace and document it >>>> elsewhere. I'd be happy to discuss further as well of course. >>>> >>>> Thanks, >>>> Martijn >>>> >>>> On Monday, June 27, 2016 at 9:52:11 AM UTC-6, Martijn van de Rijdt wrote: >>>>> >>>>> I much appreciate your comments, Chris. >>>>> >>>>> For comments on several questions, this method would facilitate that >>>>> by pointing the "for" attribute to a group. It is one of the future >>>>> requirements we had in mind as well when designing this. So your past >>>>> requirement for one comment field for the whole form, could be met by >>>>> placing all questions in a group, and then creating a single comment >>>>> question that points to it. In that case, we may want to add flexibility >>>>> for positioning the comment button (e.g. with top, bottom appearances). >>>>> >>>>> I agree with the laboriousness for per-question comments. The idea is >>>>> that this is only really workable for form-builders where you would just >>>>> tick a box and that would generate the XLSForm or XForm output >>>>> automatically. >>>>> >>>>> Yes, bypassing-validation with regular constraint and required XPath >>>>> expressions was really a key advantage that made us decide to go for this >>>>> approach, despite the laboriousness of hand-coding individual question >>>>> comments (in XForm or XLSForm). >>>>> >>>>> Cheers, >>>>> Martijn >>>>> >>>>> On Sat, Jun 25, 2016 at 12:10 AM, Christopher Robert < cro...@surveycto.com> wrote: >>>>> >>>>>> Okay, thanks! That helps. >>>>>> >>>>>> It's still a bit unclear to me whether appearance+for is ideal vs. >>>>>> some other way of specifying both the functionality desired and the >>>>>> link(s). For example, if you wanted a comment on a set of questions rather >>>>>> than just one, how would that happen? Using "for", you might get locked >>>>>> into a 1-to-1 design that turns out to be less than ideal for comment >>>>>> facilities. >>>>>> >>>>>> As a point of reference (and, I realize, general irritation), we >>>>>> added comment capability into SurveyCTO some years back. And we did it by >>>>>> adding a new field type that would accept comments form-wide. So, >>>>>> essentially, if you added a "comments" field to your form, then a >>>>>> context-menu option to add a comment would be available survey-wide, and >>>>>> the comments field would end up holding a .csv file with comments linked to >>>>>> the fields with which they were associated. So, you might get no .csv file, >>>>>> a .csv file with a single comment for a single field, or a .csv file with >>>>>> potentially lots of comments. These comments were held separately from the >>>>>> core form data, in separate (but attached) .csv files so that you could >>>>>> import and manage them separately from your core analysis. It was ad-hoc >>>>>> and designed to meet some users' needs, though certainly imperfectly. >>>>>> Client UI's could differ in how they allowed addition of comments, but we >>>>>> used the same basic approach in both our Android and web UI's (a context >>>>>> menu). >>>>>> >>>>>> In my view, most users who want to accept comments likely want to >>>>>> accept them either everywhere or at least in most places -- so having to >>>>>> code comment fields separately, field-by-field, would be tremendously >>>>>> laborious to the point of not being useful. That's just my opinion, though, >>>>>> and obviously you have at least one client willing to pay for the >>>>>> field-by-field option. >>>>>> >>>>>> It also seems quite dangerous to allow any kind of blanket bypassing >>>>>> of validation, so your approach to that (allowing them to code this into >>>>>> the validation itself) seems like a really smart one. In a great many >>>>>> cases, forms are designed such that people reasonably expect -- perhaps >>>>>> within the logic and UI of the form itself, but certainly in the back-end >>>>>> processing and analysis -- that required fields will be required and that >>>>>> constraints will be enforced. Once you start allowing people to escape >>>>>> validation, the design, testing, and analysis tasks become just so much >>>>>> more complex. While we do have users who occasionally ask for >>>>>> blanket-validation-escape options, we generally talk them out of it. And we >>>>>> haven't been willing to build such things into SurveyCTO, believing that >>>>>> even those who request it would be poorly served by the consequences. >>>>>> >>>>>> Best, >>>>>> >>>>>> Chris >>>>>> >>>>>> On Fri, Jun 24, 2016 at 11:36 AM Martijn van de Rijdt < mar...@enketo.org> wrote: >>>>>> >>>>>>> Thanks Chris, >>>>>>> >>>>>>> The use case that prompted this change was the desire to comment on >>>>>>> questions (similar to what SMAP server is doing on their ODK Collect fork - >>>>>>> but without the limitation it has beyond their use case) and enter those >>>>>>> comments by clicking a button next to the question that would reveal some >>>>>>> kind of modal. In addition, the presence or value of a comment would have >>>>>>> to allow bypassing validation. E.g. question A is required, unless there is >>>>>>> a comment on that question. So eventually after going through many complex >>>>>>> options, we can back to the idea that those comment questions should be >>>>>>> coded into the XForm like any other question. Any validation logic can thus >>>>>>> be coded normally with XPath. The additional benefit is that labels, >>>>>>> translations, hints, etc. are also completely flexible and don't have to be >>>>>>> hardcoded. I should also note that the client that has paid for this, will >>>>>>> have different types of 'comment' questions and one question could even >>>>>>> have multiple comment types. This is far beyond the scope of this proposal, >>>>>>> but it played a role in coming up with this implementation. >>>>>>> >>>>>>> So to do this, we could use the "for" attribute to *visually* link >>>>>>> from the comment question to the question it links with. Any logic >>>>>>> (relevant, constraint) links are separate from that. >>>>>>> >>>>>>> A client, such as Enketo or ODK Collect, would require only one more >>>>>>> XForm addition to respond to the use case described above, which is a new >>>>>>> appearance. The one I wanted to propose, if we make the "for" attribute an >>>>>>> official OpenRosa feature, is to use appearance="comment". >>>>>>> >>>>>>> A second (optional) additional proposal would be to link the >>>>>>> question node in the model with the comment node(s) (note the link goes in >>>>>>> a different direction here). The objective would be to facilitate the >>>>>>> presentation of submitted data on the OpenRosa server for easy analysis >>>>>>> without having to evaluate the XPath expressions in "for" attributes in the >>>>>>> XForm binds. That addition would not be required or used by Enketo or ODK >>>>>>> Collect. It's purely for the server. Let me know if you want me to >>>>>>> elaborate further on this already. >>>>>>> >>>>>>> Cheers, >>>>>>> Martijn >>>>>>> >>>>>>> >>>>>>> On Thursday, June 23, 2016 at 11:12:51 AM UTC-6, Christopher Robert wrote: >>>>>>> >>>>>>>> Hi Martijn, >>>>>>>> >>>>>>>> Sounds interesting. Can you say any more about the likely use cases >>>>>>>> and the additional specification extensions those might require? >>>>>>>> >>>>>>>> I ask only because it seems a bit difficult to think about this >>>>>>>> "linking of questions" issue separated from the nature of the links >>>>>>>> themselves -- and what other properties or parameters would be required to >>>>>>>> support those types of links. For example, you might say that when field q3 >>>>>>>> has a relevance expression like "q1+q2 < 100", then q3 is linked in a way >>>>>>>> with q1 and q2: its visibility depends on q1 and q2. Likewise, constraints >>>>>>>> can include links, labels can include links, and so we have varied ways in >>>>>>>> which fields are already related to one another. And in a sense you can say >>>>>>>> that all of the fields within a group (with the field-list appearance or >>>>>>>> otherwise) are related. >>>>>>>> >>>>>>>> In none of those cases is a separate "for" construct necessary, and >>>>>>>> so it gets me thinking about what other kinds of links might or might not >>>>>>>> require (or benefit from) a "for" linkage. That's why I thought more use >>>>>>>> cases might be useful, to determine whether they share the need for a new >>>>>>>> "for"-type linkage, or if, like the existing linkages, they might be >>>>>>>> somehow implicit or arranged in some other way. For example, if another >>>>>>>> extension might be necessary to support modal pop-ups, then might that >>>>>>>> extension itself not have its own way of specifying the linkages? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Thu, Jun 23, 2016 at 12:57 PM Martijn van de Rijdt < mar...@enketo.org> wrote: >>>>>>>> >>>>>>>>> Hi ODK Devs, >>>>>>>>> >>>>>>>>> We added some functionality to Enketo and wanted to propose a >>>>>>>>> related addition to the OpenRosa/ODK XForm specification. >>>>>>>>> >>>>>>>>> If you agree with this addition to the XForms spec (or an >>>>>>>>> alternative), I'll add it to the documentation and use the OpenRosa >>>>>>>>> namespace. If, not we'll just consider it an Enketo-specific extension and >>>>>>>>> use an Enketo namespace. In either case the XForms are functional in ODK >>>>>>>>> Collect, because the addition is just ignored. >>>>>>>>> >>>>>>>>> *Requirement:* >>>>>>>>> >>>>>>>>> Visually link two questions together. Can be used for various >>>>>>>>> features, e.g. one question could be a comment on another question. >>>>>>>>> >>>>>>>>> *Proposal*: >>>>>>>>> >>>>>>>>> Add a namespaced `for"bind attribute, like this: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The `for` attribute contains a relative or absolute path to the >>>>>>>>> question it links with. So in combination with an appearance you could now >>>>>>>>> visually link these questions together in creative ways that regular XForm >>>>>>>>> groups do not allow. E.g. add a button to the linked question that when >>>>>>>>> clicked shows a modal containing the other question. There are no >>>>>>>>> restrictions, special assumptions or magic. A question could have multiple >>>>>>>>> questions linked to it for example. >>>>>>>>> >>>>>>>>> If there is some enthusiasm for this I'll follow up with another >>>>>>>>> more specific proposal to build upon this XForm addition to create a very >>>>>>>>> flexible comment feature. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> *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/SaNMPr9eSyQ/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 >>>>> >>>> >>>> -- >>>> *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. >>>> >>> >> -- >> *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. >> > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >