One ODK development to rule them all? - Build, Validate, Purcforms, XLS 2 Xform Converter, Kobo Forms Builder

Dear ODKers,

As a newbie to the software, I have noticed that ODK seems to have
both a fragmented development environment (i.e., one may need to
deploy Build, Validate, and Collect to test a single application) and
a relatively balkanized universe of form builders (Build, Purcforms,
XLS 2 XForms Converter, and Kobo Form Builder, to name only those I
know).. This is, on one hand, a considerable strength. End users
have strong single-purpose tools for different pieces of the
development process (i.e. Build for constructing a form, Validate for
testing syntax, and Collect to see how a valid XForm works) and an
array of choices for developing questionnaire applications (i.e.
Build, PurcForms, and others do essentially the same thing, but
slightly differently). But, on the other hand, this could also be a
significant weakness. Less tech savvy users may get confused about
which software does what, and how. More tech savvy users may get
annoyed at needing to use several tools to get the job done.

For the developers, are there any plans to build on development
environment to rule them all? Is this something the user community
should want?

For the users, what are your tools of choice? What are the relative
merits of the various different options? And how much do you usually
just code XForms "by hand" in Notepad++?

Best,
Arthur

good question.

the core team doesn't believe in monolithic systems. we believe that
organizations prefer to pick and choose appropriate components instead
of having one system that does everything poorly. we have a paper at
ictd2010 that gets into details
http://opendatakit.org/about/research/.

i don't buy the notion that more tech savvy users will be annoyed. i
think those are the users who want to pick and choose the tools that
do each individual task the best. to make those users happy, we spend
a ton of time working on well-defined apis so all the tools in this
community can work together.

for less technical users, i do agree that there is value in having end
to end systems that address the common case and we are working on
making that easier -- not just with odk, but with everything we could
interact with. for example, build now does some validation and will
soon publish directly to aggregate (among other services). that said,
we try to provide such functionality using well-defined apis in
de-coupled tools...

so with that, i doubt anyone on the core team will be building one
environment to rule them all. if we hear complaints from our users to
provide such functionality, we'll be glad to reconsider. until then,
we'll be looking for ways to break up some of the tools even more and
rely on apis to connect them when needed...

··· On Tue, Nov 16, 2010 at 11:13, Arthur wrote: > Dear ODKers, > > As a newbie to the software, I have noticed that ODK seems to have > both a fragmented development environment (i.e., one may need to > deploy Build, Validate, and Collect to test a single application) and > a relatively balkanized universe of form builders (Build, Purcforms, > XLS 2 XForms Converter, and Kobo Form Builder, to name only those I > know).. This is, on one hand, a considerable strength. End users > have strong single-purpose tools for different pieces of the > development process (i.e. Build for constructing a form, Validate for > testing syntax, and Collect to see how a valid XForm works) and an > array of choices for developing questionnaire applications (i.e. > Build, PurcForms, and others do essentially the same thing, but > slightly differently). But, on the other hand, this could also be a > significant weakness. Less tech savvy users may get confused about > which software does what, and how. More tech savvy users may get > annoyed at needing to use several tools to get the job done. > > For the developers, are there any plans to build on development > environment to rule them all? Is this something the user community > should want? > > For the users, what are your tools of choice? What are the relative > merits of the various different options? And how much do you usually > just code XForms "by hand" in Notepad++? > > Best, > Arthur > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en >

Arthur:

as our software matures, we certainly expect that some patterns or
combinations
will become more common than others. As we see these develop, we will
package
these ensembles into a single tool (as much as possible given client
and server
components) and make many of the setup steps invisible to the less
interested
user. However, we don't feel we are at that point yet but can
certainly work with
an organization that feels this is in their best interest sooner
rather than later.

Thanks for your interest in ODK and keep up the good questions.

Gaetano

··· On Nov 16, 12:55 pm, Yaw Anokwa wrote: > good question. > > the core team doesn't believe in monolithic systems. we believe that > organizations prefer to pick and choose appropriate components instead > of having one system that does everything poorly. we have a paper at > ictd2010 that gets into detailshttp://opendatakit.org/about/research/. > > i don't buy the notion that more tech savvy users will be annoyed. i > think those are the users who want to pick and choose the tools that > do each individual task the best. to make those users happy, we spend > a ton of time working on well-defined apis so all the tools in this > community can work together. > > for less technical users, i do agree that there is value in having end > to end systems that address the common case and we are working on > making that easier -- not just with odk, but with everything we could > interact with. for example, build now does some validation and will > soon publish directly to aggregate (among other services). that said, > we try to provide such functionality using well-defined apis in > de-coupled tools... > > so with that, i doubt anyone on the core team will be building one > environment to rule them all. if we hear complaints from our users to > provide such functionality, we'll be glad to reconsider. until then, > we'll be looking for ways to break up some of the tools even more and > rely on apis to connect them when needed... > > > > > > > > On Tue, Nov 16, 2010 at 11:13, Arthur wrote: > > Dear ODKers, > > > As a newbie to the software, I have noticed that ODK seems to have > > both a fragmented development environment (i.e., one may need to > > deploy Build, Validate, and Collect to test a single application) and > > a relatively balkanized universe of form builders (Build, Purcforms, > > XLS 2 XForms Converter, and Kobo Form Builder, to name only those I > > know).. This is, on one hand, a considerable strength. End users > > have strong single-purpose tools for different pieces of the > > development process (i.e. Build for constructing a form, Validate for > > testing syntax, and Collect to see how a valid XForm works) and an > > array of choices for developing questionnaire applications (i.e. > > Build, PurcForms, and others do essentially the same thing, but > > slightly differently). But, on the other hand, this could also be a > > significant weakness. Less tech savvy users may get confused about > > which software does what, and how. More tech savvy users may get > > annoyed at needing to use several tools to get the job done. > > > For the developers, are there any plans to build on development > > environment to rule them all? Is this something the user community > > should want? > > > For the users, what are your tools of choice? What are the relative > > merits of the various different options? And how much do you usually > > just code XForms "by hand" in Notepad++? > > > Best, > > Arthur > > > -- > > Post: opendatakit@googlegroups.com > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > > Options:http://groups.google.com/group/opendatakit?hl=en