The latest beta uses the new dialog by default and includes the satellite count.
1 Like
Thanks @ln, this is great! I tested the beta and it looks and works very well. I think some more feedback from others (looking at @chrissyhroberts) might be useful regarding the labels and customization. My first impression was that an accuracy of 12m shouldn't be called "poor accuracy" (anything >5 currently is).
I would vote on removing the "Please wait" part of the label, since whether someone should wait or not is very project dependent. I would, for example, instruct people not to wait once they reach 30m. I'd also prefer changing "unacceptable" to "very poor", since getting a 110m accuracy in a heavy thunderstorm where you hide from the elements is acceptable in my experience.
2 Likes
Just testing, looks great! The new UI feels like an improvement over the old one. Agree with Tino on wording changes.
re "autosave with good enough accuracy if perfect accuracy takes too long": as I wrote earlier in this thread, I could see the benefits of additional and optional parameters to autosave with a lower accuracy after a given time span:
- Wait xx seconds for perfect accuracy (<5m)
- Wait yy seconds for acceptable accuracy (zz=20m)
- Save any location after yy seconds (or not)
With 2 and 3 being controlled through optional additional parameters. This would take one critical and eternally confusing step out of our protocol. We have 400 odd folks per season doing this step 40-50k times all up.
1 Like
I believe that accuracy is a variable that form creators should be able to set - and I am not clear whether this is planned or not.
I currently have two projects. One is to track locations where travelers get sick, the other is to map food stores in densely populated areas. The accuracy of the first is easily 50 km. On the second, if I am more than 5m away, I find my points inside buildings, on the wrong side of the street, or even the wrong street, so I'd like to limit data entry to high resolution. In other words, this is a value I'd like to be able to set when I create the form, or at least when I collect data.
Thanks, Z.
@LN I think that the UI is both neat and intuitive. Looks great in dark mode.
One thing I like less is that if I try to overwrite a previously saved fix, the old data are visible whilst the new fix is stabilising. I find this a bit weird in both look and logic and I wonder if moving the getting location box up to obscure or to blur the old reading would be sensible.
Personally I would like a live updating view of the current gps fix, i.e. in small text under where it says 'satellites : n'.
like
Time elapsed : 01:04
Satellites : 15
GPS : N15°59'54", E13°40'42", 76.4m`
I totally agree with @Tino_Kreutzer about the wording and about the fact that 12m is not bad accuracy, but I'd also like full control of this as a modifier parameter like good=4, poor=10, bad=25
I also agree with @Florian_May that the optional parameters for timeouts or autosaves would be enormously helpful.
IMHO there's not much value in the bit that says Point will be saved at 5m unless this is modifiable.
Thanks again for awesomeness.
2 Likes
We've got one more addition planned for this release plus some possible language tweaks depending on the answers to some follow up questions I have. We'll be introducing an unacceptableAccuracyThreshold attribute (wording for XLSForm is to be determined) to configure when the "unacceptable" message is shown. We expect this to be particularly helpful for organizations that have high accuracy requirements. They'll be able to set it equal to the accuracyThreshold (default of 5m) so that points are shown as "unacceptable" until auto captured.
On the flip side, for contexts that never want an alarmist message, they could set it to some large value (e.g 100000). @Tino_Kreutzer I hope this addresses the concern about the "unacceptable" word which I do understand. The problem we are most trying to address with these changes are data collectors who immediately capture points and don't wait at all to improve accuracy (some analytics about current behavior at the bottom).
If a form doesn't specify an explicit accuracyThreshold then the target accuracy for capture is 5m. 5m before that threshold (so 10m with the default), the message will say "Improving accuracy. Please wait." The idea is that this is relatively neutral message. A 5m difference in the accuracy radius is a significant difference in granularity (it's 5m in every direction). We think/hope the "Please wait" will encourage actually getting to the target accuracy. It sounds like you're concerned that users would end up being stuck for a long time and feeling like they can't save? Is a point taking a really long time to get accurate something you've experienced recently? We believe this to be rare now.
"Poor accuracy" is the message shown between the unacceptable threshold and accuracyThreshold + 5. So indeed, if you have a form without an explicit accuracyThreshold, 12m will be identified as "poor". I think this helps meet the goal of encouraging folks to wait until the desired threshold is met. I agree that there are scenarios in which it would be acceptable. The question is again the one above: what bad behavior do you imagine these messages would lead to. See below for some analytics insights into what users are doing today and the behavior changes we hope for. Do you have a sense of what you'd prefer? Continuing the more neutral "improving accuracy"? Something else?
Could you set an explicit accuracyThreshold of 30 in that case? Or is it more like what @Florian_May describes that yeah, you'd like to get a more accurate point if possible but you don't want people to spend more than N seconds on it? Do you know for sure that people having to wait a long time is a problem today?
accuracyThreshold exists today but requires a new column in XLSForm and is not in the ODK docs. We plan to add it to the parameters column for the next pyxform/Central release to make it more accessible. Using the extra column will continue working so you could run with that now if you want.
I hear you. Let's finish polishing what we have now, get it out out, make sure accuracyThreshold as described above is better documented, keep an eye on analytics, and see what kinds of results you get. More configurability increases our maintenance burden and paradoxically leads to the expectation that it should be infinitely customizable for any scenario. Looking at analytics below, getting low-accuracy points is not a huge problem across points captured (but we know it hits certain contexts disproportionately, e.g. mass surveys with lightly trained staff/volunteers).
Analysis of analytics added Dec 14
We added some analytics to inform this work in the Dec 14 point release. The last month is probably not entirely typical because of several holidays but we have enough points captured to make it worth looking at. Of about 1.3 million points we have data for, 888k were captured automatically when the capture threshold was reached. That's the behavior we generally want so it's good that 68% of this sample are already doing what we hope. Of the remaining 32% points captured manually, 30% of those are captured within 2s meaning data collectors probably didn't even look at the accuracy (that's 10% of the full sample). We tried to bucket the accuracy of captured points into acceptable/poor/unacceptable but unfortunately the analytics interface has changed and I can't easily analyze that right now.
Without the accuracy buckets it's a bit hard to draw strong conclusions around what's going on. But the 68% auto capture is higher than I expected. That's good -- we don't have as broad of a problem as we'd feared. Again, we can't tell conclusively but we believe that certain organizations, devices or physical contexts are particularly hard hit by accuracy issues and those are the folks we want to help. For everyone else, we hope they just continue doing what they've been doing: wait until the point is automatically captured.
We'll know we've had positive impact if the percentage of points captured immediately goes down and the percentage of points captured automatically when the desired accuracy is reached goes up.
2 Likes
I don't have much to contribute here, but the new dialogue is definitely an improvement and much clearer to the enumerator that the value may be poor and they should wait for it to improve.
I was testing with an SM-G900F (no SIM, on wireless):
2 Likes
The new dialog is now available in v2022.1.0 and documentation is updated here. Thanks to all who have pushed to make this even better.
We ended up going back to a gray background instead of showing the activity below.
We discussed this but couldn't come up with a use for it. Do you expect data collectors to know how to recognize a correct location? Or is it more to make it clear that a point is being captured, not just an accuracy?
As your field teams work with this new experience, please consider some of the suggestions made above and my follow-up questions here and we can see about further adjustments!
We're going to add accuracyThreshold and unacceptableAccuracyThreshold as parameters in XLSForm. We are currently planning to use parameter names capture-accuracy and unacceptable-accuracy. Please let us know if you have comments on that naming. unacceptable is unfortunately hard to spell so alternatives would be welcome.
I really like it with the grey background. I think I only wanted the live updating gps fix to counteract the confusion of seeing a static location in the background.
I agree that unacceptable has unacceptable number of letter Cs in it.
how about minimum-accuracy
2 Likes
Another idea is warning-accuracy: the unacceptable threshold represents a threshold above which clients are encouraged to display a warning that the user should change conditions or keep waiting.
1 Like
Unsure if this is intentional or not, but in the new geopoint dialogue, you can't back out of it with the Android soft "<" button, only with the 'Cancel' option on the dialogue. You can back out of placement-map with "<", and take picture/markup image etc.
Good catch! This will be fixed as part of the next release (https://github.com/getodk/collect/issues/5018).
1 Like
A live feedback from an end user 
and in english :
3 Likes
Hi @LN,
I just read the documentation section relative to those new parameters, wich is very clear : https://docs.getodk.org/form-question-types/#geopoint-widget
For the moment I make use of the column "body::accuracyThreshold", can I still use it until the end of the field season, before we upgrade forms to use the new parameters instead of it ?
Even if we update Collect on phones ?
Yes, and in fact you can use it until the end of time. 
The body:: prefix is used to directly populate a body attribute and will continue to be supported. The parameters column makes it possible to configure specific question types without having to make the survey sheet wider and with a little bit more validation. The two end up doing the same thing in the XML form.