chrislrobert
commented
7 years ago My primary argument for essentially ignoring XForms compliance has been user experience: we want to add features in a way that's as easy as possible for users. And here, I mean "easy to use" to broadly include not just being simple to learn and use, but relatively efficient, not too error-prone, etc. Since users aren't coding in XML, we're generally concerned about their XLSForm (or drag-and-drop) experience -- but there are lots of ways that the underlying XML code influences those users. Primarily, constraint, relevance, and calculation expressions: we optimize functional forms for XLSForm, not for the underlying XForms. (Right now, XLSForm expressions are XForms expressions, except that ${name} references are expanded to XPaths automatically.)
My secondary argument concerns time/effort/cost. We're a small private business subjected to intense market pressures. The pressures are particularly intense specifically because we are a social enterprise focused on delivering a social mission. Our goal is to offer -- and support! for no extra charge! -- an incredibly stable and useful product for the lowest possible cost. So if we have 12 ways to implement something and one way is cheaper (considering long-term maintenance, support, documentation, etc., etc.), then generally we choose that way. This often pushes us away from XForms compliance because the costs of compliance have not seemed worth it (or relevant to our users).
Other issues that come up, very broadly related to ease-of-use, are backward-compatibility and upgrade-path. When we add functionality, we always try to do so in a manner that causes the least possible implications for backward compatibility, and we also try to make the pathway for existing users to benefit as short and as clear as possible. We have thousands of users to look after, and XForms-compliant designs often seem like total non-starters from the perspective of supporting those existing users.
And okay, if I'm being honest, a big practical issue is this: on our team, we have nobody who likes to modify that pyxform code. We're not python programmers, and even python programmers have a lot of trouble delving into that code. So we're trying to get some decent UX in XLSForm, and in principle we could do something nice in XLSForm (have to discuss that spec too, BTW!) and then have pyxform turn that into whatever XForms code is compliant. In principle that's okay, but in practice it takes us forever to modify that pyxform code, and we're terrified of breaking a zillion things all the while. So the reality is that we minimize the need for pyxform logic, which means keeping the XLSForm->XForms logic as unchanged as possible, while adding new functionality.
On Wed, Jan 11, 2017 at 5:47 PM, Hélène Martin notifications@github.com wrote:
I think interoperability between ODK tools is super valuable, especially for users in the ecosystem but also for developers. We've discussed this a bit in #73 https://github.com/opendatakit/xforms-spec/issues/73.
I think W3C XForms compatibility is desirable to the extent that it can help with design -- clearly a lot of smart people have already thought about how to express forms. We've talked some about compatibility with and possible code leveraging from tools like Orbeon Forms but I wonder how realistic that is given how much broader of a spec they implement.
What are the reasons we'd want to leverage the W3C XForms spec and how important of a consideration should this be when considering adding functionality? I believe @chrislrobert https://github.com/chrislrobert has decided with SurveyCTO that it's not a priority and that's a big reason there have been questions here about how to incorporate their extensions notably from @MartijnR https://github.com/MartijnR . I believe Dimagi has decided that it is important to them and I'd like to hear more about that decision. @ctsims https://github.com/ctsims? Or is there someone else from Dimagi who could comment?
I want to have a clear sense of the arguments on both sides. I think having a relatively clear guiding principle related to this will help evaluate new proposals.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opendatakit/xforms-spec/issues/74, or mute the thread https://github.com/notifications/unsubscribe-auth/AIO0Hh5xDFd5m4dEkiDkrP35et2FsYrtks5rRVwegaJpZM4LhKkL .
dorey
MartijnR
lognaturel
mberg
I think interoperability between ODK tools is super valuable, especially for users in the ecosystem but also for developers. We've discussed this a bit in #73.
I think W3C XForms compatibility is desirable to the extent that it can help with design -- clearly a lot of smart people have already thought about how to express forms. We've talked some about compatibility with and possible code leveraging from tools like Orbeon Forms but I wonder how realistic that is given how much broader of a spec they implement.
What are the reasons we'd want to leverage the W3C XForms spec and how important of a criterion should this be when considering adding functionality? I believe @chrislrobert has decided with SurveyCTO that it's not a priority and that's a big reason there have been questions here about how to incorporate their extensions notably from @MartijnR . I believe Dimagi has decided that it is important to them and I'd like to hear more about that decision. @ctsims? Or is there someone else from Dimagi who could comment?
I want to have a clear sense of the arguments on both sides. I think having a relatively clear guiding principle related to this will help evaluate new proposals.