Geotrace and geoshape in Collect: specify input method in form design

Collect has two question types for capturing multiple geographic points: geotrace and geoshape. Currently, data collectors can choose how they record points while filling out a form. There are three types of location recording modes:

  • Placement by tapping – the user taps the map to place points.
  • Manual location recording – the user taps the "record a point" button to capture the device’s location at that moment.
  • Automatic location recording – the user sets a recording interval and accuracy requirement, and points are captured automatically.

We're exploring the idea of specifying the recording method within the form design itself, rather than allowing data collectors to choose while filling out the form.

Pain points we've heard from user feedback:

  • Inconsistent data collection – users accidentally or intentionally change the recording method during form filling, making analysis difficult.
  • Unclear terminology – the language used to describe recording methods isn't always intuitive or user friendly, which can lead to mistakes.
  • Usability issues – the automatic recording mode has some UI challenges, particularly with the dropdown in landscape mode.

Potential Solution
What if form designers specified the recording method instead of data collectors to avoid these pain points? We'd love to get your feedback.

  • Do data collectors need to change the input method? If so, why?
  • What challenges have you experienced with this functionality, if any?
  • How would setting the input method in the form design impact your workflow?
1 Like

This is for the majority my use cases...

  • Do data collectors need to change the input method? If so, why?
    • I request manual placement to remove the GPS error, as well as not always being able to have the device where the location of interest is due to inaccessibility. So there would be no need for them to change method with these workflows
  • What challenges have you experienced with this functionality, if any?
    • Geopoint: appearance-map will grab a location from the GPS which requires a delete then create step, would prefer if it was able to be set to not auto grab
    • Geotrace/shape: Annoying to users to have to select the input method (placement by tapping) every time
    • have to have a constraint on the question to ensure the altitude or accuracy = 0 to confirm manually placed points
  • How would setting the input method in the form design impact your workflow?
    • Would this be global (in settings) or per field (appearance), if per field, could it be dynamic (i.e. a question or lookup could change method)?
    • I would set to placement by tapping almost always
2 Likes

Thank you for the thoughtful feedback @ahblake :dizzy:

We are curious to hear what people think! What would work best for you?

1 Like

Per field could be used as different (more) geo questions types and so be very flexible.

1 Like

For me, per field and dynamic offers the most flexibility, but per field would be fine it's a fixed parameter but still allows changing per specific question.

1 Like

My preference would be to set a default in form design - it is tedious to have to complete the settings each time rather than just start recording - most of the time I am recording the same method, but not always.

Also being able to change the frequency of automatic recording can be helpful (so maybe setting a default of 1 second set in xlsform, but able to change it to 20 seconds, so that if it's a big shape simple, the geometry is not overly complex. And if the next item is small and complex I would want to be able to choose - whilst the default 'just works' for most intended cases in that survey).

Personally I think that it would be retrograde step if it were not possible to change any settings in ODK Collect (or Enketo / Web Forms) - but being able to lock them might be okay if there was a strong case. I have forms that are used in the field but also at a desktop for the same data collection exercise, so being UNABLE to manually locate an item / line / shape, for example, would be problematic. And also if the GPS can't get the required accuracy in the field it might still be acceptable to place the point(s) manually to save having to go back to the location.

The accuracy of 0 aspect is really useful to help differentiate whether points are defined by GPS or by tapping. Providing that you have remembered to allow-mock-location in the form if you are using a high-accuracy external GPS. Allegedly.

I have found situations where it is not practical to walk (or ride) the line / area that I am recording - and sometimes I am 'mapping' with a combination of gps and basemap to create the line / shape (so I might have selected placement by tapping, but actually tapping on my location for some of the time, where other parts of the shape might be an inaccessible location and so I tap on a location that corresponds to a visible feature on my basemap, if that makes sense). This can be the case with habitat mapping, for example. But that method obfuscates the 0 accuracy!

From a UI perspective, I think it would still be good to see the different options (and default values for automatic) when you tap 'start', but perhaps changing options for automatic could be a separate pop-up (assuming a pop-up of a pop-up allowed?) or a different button.

I agree that 'manual location recording' and 'placement by tapping' are not intuitively different. Perhaps 'placement by tapping' / 'GPS with manual interval' / ' GPS with automatic interval'?

I think it is good to be able to trust enumerators by default (i.e. give them flexibility in the field) - setting defaults helps them see what / how you as a designer WANT them to record. Locking recording methods can be valid but, in my opinion, is not a helpful default position for a tool as open and flexible as ODK Collect - being able to adapt in the field can be very important for getting some data rather than no data (especially in remote locations) - then we can decide if it's 'good enough' and repeat if required. Reference back to discussions about the introduction of 0 for mock-locations would be insightful - and the parameter value as a great solution to an unintended consequence.

Enhancing this aspect of data collection would be greatly appreciated by me and my enumerators!

2 Likes

Thanks @ahblake, @mathieubossaert, and @seewhy for sharing your feedback!

I wanted to surface this again in case others have thoughts on specifying the recording method in the form design, rather than leaving it up to data collectors during form filling. We’d love to hear your input!