6 ms·
I work in a form-heavy industry in which field agents can easily be disconnected, so offline is a must. I play with ODK and it's various client tools every few
by jasonkostempski 8y ago
I work in a form-heavy industry in which field agents can easily be disconnected, so offline is a must. I play with ODK and it's various client tools every few years to see if it offers anything useful, especially above a custom system. I haven't found anything yet. It's relatively easy to make a native app with forms that save to a data file for syncing when online. What's not easy is designing a tight data entry workflow that people will favor over pen and paper in the field. I've come to the conclusion that it's mostly impossible, because pen and paper are pretty awesome. People trying to get work done don't want to deal with: swiping to unlock screens; entering pins; touch input (holding their device in awkward ways so they don't accidentally touch the wrong thing and not turning off the screen so they don't have to swipe and enter a pin again); battery life; risk of damage to expensive equipment; losing an full days work due to a little accident or data killing software update; etc. Mobile devices suck for user interaction, their primary purpose is consumption.
Obviously, data needs to be digitized at some point. In my experience, even though it's duplicate work, users would rather reenter the data when they get home, on a PC, with a keyboard and mouse. ODK does have some decent tools for that, but they're all based on a dead standard, XForms.
- amind 8y agoI worked as a graduate assistant on a project administering a survey on tablets in challenging conditions. Your points are valid, but we found that we could create a streamlined Enketo (https://enketo.org/ https://enketo.org/) form with categorical, quantitative, and Likert scale questions (minimal and optional free text fields) and the enumerator teams were successful. We ended up using Kobo Toolbox, mentioned in another comment, which mates Enketo as a front-end to the ODK set of tools. Running pilot tests and timing the input of each answer of the survey helped to dramatically streamline it, so that seems essential for using digital tools. Two major perks to using the ODK type tools - many folk have smartphones with browsers on them, so running ODKCollect or especially Enketo is accessible, and the logged data gets pushed up to a server as soon as possible. The latter point was really useful for us - I spun up a quick app in Shiny (https://www.shinyapps.io/ https://www.shinyapps.io/) which would give some plots based on the data collected so-far, and after the first day or two the survey administrators found a hiccup in how one of the enumerators was answering a question (they were incorrectly tagging the locations they were visiting, which would have caused havoc to relabel later!) I think that sold a lot of us on the value of these tools. Totally agree about XForms. Shame it's not more widely used. I did get a lot of mileage out of using XLSForm (http://xlsform.org/ http://xlsform.org/) to write the survey first though.
- jasonkostempski 8y agoI worked on a project that built a forms tool around XForms about 4 years ago. It is pretty darn powerful, but finding an engine that can understand all that power and run in all the places offline forms need to run is impossible. Maybe there's something in ODK, I haven't dug that deep into the foundational code, I've only looked at it as a potential turn-key solution.
- yanokwa 8y agoODK founder here. The ODK community maintains a Java XForms engine at https://github.com/opendatakit/javarosa https://github.com/opendatakit/javarosa that powers a lot of the ODK tools. https://github.com/enketo/enketo-core https://github.com/enketo/enketo-core is a compatible engine in JS. If you have an idea on how we could make this foundational tech more visible to other devs, shoot me an message!
- jasonkostempski 8y agoI didn't do the initial foundational research for the project I worked on, but now that you mention it, I think that was discussed. I think the main issue was that Java really does run everywhere, except iOS, which is unfortunately the most popular mobile device choice. In an enterprise environment that can dictate what devices get used in the field, it's not a problem, just force Android or even Windows on a tablet. In a bring-your-own-device environment, iOS support is a must-have. On the other hand, bring-you-own-device is a risky business move anyway because App Store rejection is a very real concern. It was a problem more than once for that project.