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,
MartijnOn 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
forattribute 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/