Feedback needed: Add default geopoint question type for Web Forms

[Aly_Blenkin]

We now have a preview of the default geopoint question type for ODK Web Forms and we need your feedback to make it even better!

If you’re new to Web Forms, start here:

• Why we are building Web Forms
• Our plan for releasing - we are currently in phase 2
• Web Forms Preview - use to test your XLSForms

Overview & goals
The default geopoint helps data collectors capture the most accurate location possible. It’s the default because it’s the most intuitive geo question in enumerator-led data collection: no map skills or Internet required.

In the table below, you'll find a breakdown of what capturing geopoints looks like in Collect and Enketo (our current web forms stack) today.

Over the past few months, we’ve been interviewing users and running workshops to better understand your needs for capturing locations in Web Forms. Here is what we heard:

• Make the geopoint experience consistent
  • Ensure a seamless experience between Collect and Web Forms.
  • Enketo can be confusing for data collectors because it provides many different ways to capture location.
• Keep it simple
  • Data collectors need clear indicators of accuracy (e.g., “good” vs. “poor”)
  • In Enketo, some users manually enter coordinates, resulting in poor quality data.
• Encourage higher accuracy
  • Prompt users to “Try Again” if accuracy is low.
  • Project managers often have to edit submissions because accuracy wasn’t high enough.

What we built
Capturing a location in Web Forms provides a very similar experience to Collect. An accuracy dialog is displayed, and once the data collector gets a high accuracy point (as determined by the form designer), they can save it.

If they’ve captured a poor accuracy point, they can tap “Try again”. The dialog will show the accuracy of the previous point as a reference so they can decide to use the current point or keep the previous point.

Potential limitations
While the default geopoint experience is great for collecting data on mobile devices and previewing forms, it may not be ideal for filling forms on desktop computers because the accuracy may not improve.

We'll soon implement start-geopoint and the map-based geopoint which might be better for those collecting data on computers.

Try it out
You can try your forms using our Web Forms Preview or the All Question Types form. We would love feedback from data collectors or those that work closely with data collectors. Let us knoww what’s working well and what could be improved!

What’s next?

• Allow admins to opt-in to using Web Forms for specific forms
• Date question type
• Edit submissions in Central with Web Forms

[stijnvh]

This might be a specific use-case, but I hope it is worthwhile to check against the current proposal if you envision to take into account the translation to placement-map as well.

We have currently a campaign where we do not want to capture the current location, but specifically need the 'placement-map' option so users can pin a chosen location (i.e. the location they propose to take a grab water sample). As we just recently gathered feedback from users, I'd like to share it here.

Whereas I think the proposal is a great improvement to capture 'current location', it might become more difficult to support the 'placement-map' option in the use case we are facing. Although I fully understand the scope and purpose of the current (and newly proposed flow), I try to summarize the limitation we are facing with the current version (Enketo online submission on mobile/pc) as it might help in the further development:

• the accuracy/altitude can not be hidden separately, with hide-input also lat/lon is hidden. For the placement-map approach as we need it the altitude/accuracy is not important
• on mobile, the map opens in a separate modal which needs a click on 'map', which was not intuitive for some users
• the UX to choose a custom location on the map seems the main issue (see image below). Users start providing an address, but think the button on the right is 'enter' and they each time go back to their current location. Other users did not understand that they need to go 'back' after choosing their location. Instead of clicking back (red cirlce), they clicked again on the button at the right (get current location) leading to the wrong location in the form (as we do not want the current location, but their proposal). Changing the 'back' button (red circle) in a checkmark or 'confirm location' would improve the UX a lot.

Hopefully this feedback is useful. If there would be the possibility to improve the 'back' button on the short run, that would be great.

[Aly_Blenkin]

Hi @stijnvh, welcome to the community! We really appreciate you sharing feedback directly from users

We started with the default geopoint because it's currently the most distinct from Enketo.

Our goal is to create a different user experience for geo questions with a map, as the user needs in these situations can vary. As you said, the user might not be in the current location, and we want to ensure the experience is intuitive. We intend to support the same appearances as Collect. I'll address each of your points below.

the accuracy/altitude can not be hidden separately, with hide-input also lat/lon is hidden. For the placement-map approach as we need it the altitude/accuracy is not important

Could you tell me a bit more about what you want the user to see and what you want to hide and why. Do your users ever need to enter in latitude and longitude coordinates manually?

on mobile, the map opens in a separate modal which needs a click on 'map', which was not intuitive for some users

I completely agree and have heard this is very difficult to use and causes confusion with other Enketo users. We want to avoid this and show the map inline with a clear action button to make a better experience across devices.

Changing the 'back' button (red circle) in a checkmark or 'confirm location' would improve the UX a lot.

The UX here is very confusing, and we want to make the paths very clear, either capture the current location or enter manually. Here is a screenshot of some early thinking on this concept (this would be similar for mobile, and I'll share more once we have fleshed out the design a bit more)! You'll notice we have this overlay with the two buttons for the different paths, so it’s clear what will happen next.

In your case would people want to manually enter in an address or do you have something else in mind?

Once they have captured the right location, I'm curious to know what the user would want to see to help them verify and confirm this is correct. Do they want to see "Poor" or "Good" accuracy with the coordinates, the address, or something else?

You mentioned water samples above, could you tell us a bit more about your workflow? Understanding what you're trying to achieve is really helpful as a reference point when we are designing and building these features.

If you get a chance, please introduce yourself here.

[stijnvh]

@Aly_Blenkin thanks a lot for the quick and clear response. I do think the proposed UX with an inline workflow would make a huge difference.

I'll start with the workflow

You mentioned water samples above, could you tell us a bit more about your workflow?

We are running the campaign in 2 steps. First, participants can propose a locations they would take a water grab sample in a form. They pick a stream/river in their neighborhood and use the map to propose the location. They do not need to be at that specific location when proposing. Next, a geographical analysis is done to pick the best combination of locations. In a second round, a subset of the participants is asked to effectively take the water sample and run the water quality experiment within a given time frame. This is a separate form. The use case I present is from the first phase.

Could you tell me a bit more about what you want the user to see and what you want to hide and why. Do your users ever need to enter in latitude and longitude coordinates manually?

We currently use 'hide-input' as we indeed also assume that none of the users will manually provide a lon/lat combination. Ideally you can show lon/lat as it would still support a manual workflow. Altitude/accuracy have afaik no usage in the case you ask people to pin a location manually.

Once they have captured the right location, I'm curious to know what the user would want to see to help them verify and confirm this is correct. Do they want to see "Poor" or "Good" accuracy with the coordinates, the address, or something else?

The map itself with the geopoint on a high zoom level is probably the best way to verify and confirm, in combination with the lat/lon. As we aim locations in rivers/streams the address information is typically not relevant/existing.

In your case would people want to manually enter in an address or do you have something else in mind?

Participants start from typing an address manually and than move the geopoint starting from this address to the location of interest (a nearby river). For some, they start at their current location and move the map from directly (if the river is really nearby).

Thanks a lot for the feedback and way forward. I added my introduction.