The problem with static data collection forms

The standard for mobile field data collection for a long time has been the creation of a predefined form with predefined fields for the input of field data.

To many people this makes sense. "How else am I going to know what data to collect if it's not predefined??" While this is true, static forms can pose problems for those collecting data in the real world.

Ask any researcher that has ever run an experiment that requires field data and they will tell you that it is impossible to understand all variables before heading to the field.

In another life I was working as a research technician for a large research agency. During each field season our team would hold long meetings to define the methodology for field data collection. A critical thing to do. However we all understood that once data collection was underway we needed to leave room for the unexpected.

Perhaps the species of aphid that we thought was going to be prevalent, actually wasn't and another species was. If a researcher were to head to the field with a predefined data form in this instance, they would surely need to include all sorts of notes and additional information on the fly to account for the unexpected turn of events.

This is not ideal, but it is manageable for a single individual. However it raises big problems if data is being collected by a team, which brings me to problem 2.

So our team of researchers is happily counting species 'x' aphids (an unenviable task) and they soon discover that species 'y' has made an appearance. Not only that but this new species is prevalent on a weed that shouldn't even be in this location! (very exciting stuff if you're an entomologist).

It just so happens that aphid populations are very fickle and can change overnight - so no time to head back to the lab, have another meeting, redesign the data form and come back to the field. They need to sample now! What do they do? They want to sample both species and also collect aphid data at new data points - the mysterious weed.

Scientists are very good at improvisation. So what they do is hack together a solution that involves paper notes, really tight naming conventions, and their static mobile data collection form. This may work but it is highly inefficient and leaves the data that is collected open to a massive risk of human error, not only in the field, but back at the lab during post-processing. These issues are only exacerbated the bigger and more distributed a team is.

Using Locus Field Assets and Data gets around the problems above and provides a tool for what is truly agile data collection. Let's visit our friends in the field once more, this time they are using the Locus app.

Back at the lab they used Locus to set up their sampling methodology for species 'x' and they predefined data collection points where sampling would take place. As we know, they now want to sample the mysterious weed for species 'y' (and probably 'x' too).

Once everyone has downed tools the person with the correct Locus permissions to create sample types adds the “species y” sample type in their app - immediately the rest of the team can see this in their various accounts.

The Project Owner can now give permission to whoever they choose to be able to create new Assets in the map interface which will become the data collection points for the mysterious weed. Whenever these are added to the map they are visible to the team in real-time. All of this can take place in a matter of minutes.

Locus allows teams to reduce human error and get the job done fast! (Although, we can't help you if you still want to have long meetings in the field).