-
Notifications
You must be signed in to change notification settings - Fork 5
Log location coordinates in the background #28
Comments
Question 1 I got some feedback from @grzesiek2010:
I think this is an improvement we should add. I would put this under On first launch, we'd use a dialog that says...
On second launch, we'd then use a snackbar...
One of the events would then be
And one of the reasons in the snackbar would be
Question 2 I think folks feel strongly that there should always be a notification (e.g., the snackback), so I don't think we should make an option to remove it. @lognaturel @MartijnR @aurdipas Do these changes seem reasonable to you? @adamvert @smoyth does the UX feel good to you? |
Seems sensible. The only suggestion I would make is to extend the option text to something like That's kind of a long setting label, but I can't figure out a way to make it more succinct right now. |
This is looking good to me. How about Does it make sense for this setting to be hide-able by admins? Doesn't that defeat the intent of always having a way to opt out? If we keep this, we should not be displaying instructions for how to disable tracking when the setting is hidden... |
I think that the setting hide-able by the admins makes sense. I want this setting to be the same on all devices for my data collection by default. The enumerator is informed about that with a dialog the first time and then with a snackbar from the second time onwards. |
@aurdipas fair points. How about if the setting is hidden and set to enable tracking, the instructions we give say to turn off tracking by revoking permission or disabling GPS (as Yaw originally planned) instead of pointing them to a setting they can't see? |
Update: I need to think about this a bit more... |
The name of the "age" parameter seems confusing to me. Or, at least, I think it would be pretty hard for someone to see the word "age" and figure out what it means in this context. Can we clarify something about the intended behaviour? Suppose
How many points are stored in the log? (a) Just two points:
(b) 8 points:
|
@grzesiek2010 will be returning in a few days from vacation, so I figure we should have a few things resolved! @zestyping Instead of age, what word would you prefer? Maybe As to the intended behavior, note that we aren't just writing things to a log. We are gathering a set of fixes in a moving window and when an event occurs, we look backwards in that window and pick a point. Let's say an event occurs at 0:02:00, we would look back 60 seconds to |
Ohhh, I see now. Thanks for explaining! Sorry, I hadn't understood from the spec that we're only recording locations when particular other audit events occur, not in their own recurring "location" event. Yes, Given this behaviour, it almost seems like I'd be surprised if a All this makes me wonder—should |
@zestyping Very good question. I'm not an expert here, but I believe depending on location API, interval has a big impact on battery. There are two ways to get location. We currently use LocationManager, but might switch to FusedLocationProvider at some point (see getodk/collect#2717). Either way, we'll be able to set some desired interval and that interval does have an impact on battery life. Or to quote the Android docs, choose your interval wisely. If we could pick a good default, I agree we wouldn't need the |
Or maybe it makes sense to make that payoff explicit, call it Do we want users to have to understand how retrieving GPS locations works in order to make a decision about how much they value accuracy over battery life? (I'm asking that question without assuming an answer... ) |
@adamvert Here's one approach we can start with. Let's use the FusedProvider and instead of These correspond, respectively, with passive listening, city level accuracy (10km), block level (100m) accuracy, and active polling. More on the API at LocationRequest. This approach, will let us see empirically how things behave on a few devices and I think @grzesiek2010 can do technical spike around this idea. If it looks good, then we can codify it in the spec. @smoyth @aurdipas As to the user privacy issues, I think we should put We should then show the warning in snackbar when the form is collecting that data and add a |
I have tested the FusedProvider (only high-accuracy) using three different devices and I can share my insights. I think we should agree on good default values and of course, we can keep that option to use those parameters but we shouldn't require it or even encourage. Using the FusedProvider with the mentioned accuracy levels seems like a good way for saving battery. |
@grzesiek2010 So to be precise here, you think we should add |
I would prefer I think we can use default intervals recommended by Google and agree on default Of course, as I said it's should be possible to pass different values but we shouldn't require that or encourage people. It should be just an option for cases difficult to imagine now which obviously exist. |
I don't understand about why you'd need both mode and interval. If you say interval isn't reliable, why include it at all? As to age, it seems that should be required because how else does a form designer ensure that a point is recent? Am I missing something? |
For example, default interval for
I said that we should agree on default If someone wants to collect more points he might pass a different value (bigger) and if someone wants to log the last point (always) he should pass a value <= default That's why we should allow users to add different values for both |
I've updated the specification with your feedback @grzesiek2010. I think the meat of this is done, so I think you should start implementing it in Collect. If you can split things in separate PRs to make it easier to review, please do. @adamvert @smoyth @zestyping @aurdipas Any final feedback? |
looks very fine to me. I agree on start implementation. |
LGTM! |
I was thinking about default values we should agree on. Google recomends values for some of modes but I think they are not perfect for us. Proposed default values:
What do you think about those values. A user would have to select the mode (depending on his needs and devices he use) and additionaly would have a possibility to set different |
what's the difference between low_power and no_power? (values are the same?) |
As in the description: |
i was confused by a user being able to set values to something other than the default, but then one of the default settings seeming to have details set by something other than the adjustable values. |
It sounds like in @grzesiek2010's proposal there is a third hidden parameter that controls how the location is sensed (GPS vs. wifi vs. passive). |
@zestyping To be precise, the FusedProvider lets us set priority (what we call mode). The priority is...
The FusedProvider also lets us set an interval.
So, @danbjoseph, if a user sets a mode alone, then we are proposing to set what we think is a good interval and age for our use-case. The age isn't used by Android at all, it's used by Collect to put a limit on how old of a location we should consider writing to the log. @grzesiek2010 maybe we should call it priority since we're are adding a level of abstraction that isn't really needed and now that I'm trying to explain it, it doesn't sound that user-friendly. Also, I'm having a really hard time deciding what would be good defaults. How did you decide 40 secs for high_accuracy? Why not 30 seconds? Maybe we should recommend defaults (e.g., in the docs), but not encode them. Encoding them locks a particular version of pyxform/Collect to some magic value and that seems dangerous. |
you mean
|
Ok, when it comes to @yanokwa |
@grzesiek2010 Correct. All three params are required. |
I have a problem with the dialog we display on the first load. But still I don't like it... let's imagine a case: We have a device with Android 6 (permissions not granted and location provider disabled) and our user wants to collect location coordinates.
What doesn't look well itself because the message is just about revoking/disabling and it's already revoked/disabled. As I said our user wants to collect location coordinates. He can click on I think that the first dialog should just contain a message that we collect locations but after closing it a user should be asked for enabling location provider and granting permissions anyway. What do you think? |
There was no answer to my question so I decided to go ahead. Here is the pr getodk/collect#2772 As I said I had a problem with
is displayed (There is an option to go to settings). if it's disabled a dialog is displayed and there is also an option to go to settings (an event is logged as well here). Testing would be appreciated 😄 |
@grzesiek2010 Thanks for your work so far. These features always seem to get more complicated as we dig into them! I think the high-level goal here should be to inform users what is happening and give them a chance to bypass. What if we add a '(Enable/Disable) background location' in the form entry activity menu? Then on first launch, we show this dialog:
If you say OK, we pop two dialogs and ask for permission/providers. We also set a form-specific location allowed toggle. If you say Disable, we don't ask for location permissions or enabling the location provider. We show this snackbar.
On second launch, we need the toggle, permissions, and the provider. If you have all three, we show this snackbar:
If you don't have all three, then we show this snackbar.
And when you go to the menu, and select 'Enable background location' we pop the two dialogs if necessary and ask for the permissions. Does that sound reasonable? |
Generally, it sounds good but I'm not sure whether adding a new option to the form entry activity menu is a good solution since there might be not much space... don't you like the solution with a new option in General Settings -> Form management (in Form filling section)? |
Adding it in the General Settings makes it impossible to toggle on a form by form basis. |
Ok, I'm going to follow your approach but have some concerns: 1. ..............................................................................................................................
Are you sure we need that
and that's all. 2. .............................................................................................................................. if on first launch the option is disabled displaying the same dialog doesn't make sense. Should we then display a dialog which says eg:
3. ..............................................................................................................................
This doesn't make sense to me. I think we should ask for permissions and enabling providers everytime the background location option is enabled and display appropriate snackbars if something is not granted/enabled. Your proposal message indicates that it's possible to enable all three options (the main option/permissions/location providers) just clicking once in the menu what's not possible of course. |
I agree with you suggestions. And to make sure I've got it correct... On first launch or if location has been allowed, we check for permissions and provider enabled. If we don't have permissions/provider, we ask in dialogs. We display snack bars if the user says no in the dialogs. Then we show snackbars to inform users about what is happening. If you have have enabled background location.
If you don't have background location enabled
Then in the menu we have the form specific toggle. What happens if you switch from Collect to the Android settings, revoke permissions, and come back to Collect? Do we show the dialogs again? Show the snackbars again? |
Sound much better now, Thanks!
I wonder if we need that first launch check at all. I think we should ask for permissions/providers everytime it's needed when a form is started (no matter if it's the first launch) or the background location option is changed (enabled). My scenario would be:
and log an event: otherwise, go to the next step...
and log an event: otherwise, go to the next step...
otherwise, go to the next step...
with an option otherwise, show a Snackbar:
and log location coordinates! Case 2: A form is started and a user disables background location Case 3: A form is started and a user enables background location so as I mentioned above I don't see any reason for using that firstLaunch check. Do you agree? ......................................................................................................................................................
I don't think we need that. |
Case 1: I like the sequencing! Note that you'll need to also show a snackbar if you have all the permissions/providers to inform user that their location is being collected. Case 2: Works for me. Case 3: Works for me. The case where you switch from Collect to Android and revoke permissions, you'll need to add that in the log, right? Seems like we should at least throw up a snackbar in addition when the location permissions/providers changes during data collection. What do you think? |
sure! updated.
yes, would be good to have such a log.
I'm not sure. I'll be thinking about it finalizing the implementation. Logging an event is more important that's for sure because it's a note for someone who analyzes saved forms but maybe... Great, we finally agreed on it! |
The original thread on the forum
The initial specification written in Google Docs
What is the general goal of the feature?
As a supervisor, I would like to collect location coordinates in the background to provide evidence that data was collected in a particular place.
The reason of this feature is to avoid bad data. For example, you might notice an enumerator who as been poorly trained collect location in the morning, then go home and fill in the survey data whenever.
Proposed implementation
The idea is to extend the form audit log to add location to the log if
location-mode
is set as parameters in the audit row of the XLSForm, we will choose the most accurate point recorded in the age window.In the ideal case for
location-interval=10
andlocation-age=60
, 6 points will be collected and we choose the most accurate one to write the log. Butlocation-interval
is not guaranteed and so there may be more points or less points.If
location-interval
andlocation-age
are not set, defaults will be set by the application based on the mode. If either is set, the value will override the defaults.Currently an audit.csv file has the following structure:
Location will be recorded in three columns: latitude, longitude, accuracy in the audit log that is attached to Collect's submissions.
New structure of an audit.csv file:
New columns will be added only if the audit row of the XLSForm contains background parameters otherwise they are not needed.
When you have an existing form with audit that did not have location enabled and you change that form to add location, three new columns will be added.
XForms specification
In the XForms spec audit is placed in the meta block under the orx namespace. It uses a binary data type. See getodk/xforms-spec#94
We will add the following bind attributes in the odk namespace to the specification. Both attributes are required to enable location audits and location-age must be greater than or equal to location-interval.
We prepend "location-" to the tags to ensure that there are no future conflicts with mode, interval and age.
The tentative pyxform specification is as follows.
Device behavior
When Collect opens the form, we will request location updates from the location provider every desired interval seconds. Location updates will be started in onCreate() method and paused when the app is in the background (onStop() method) to avoid battery draining.
At the time of the audit event (e.g., view question, form save etc.) occurs, Collect will check the cache for the location.
If a user disables/enables location or revokes/grants the permission after starting a form an appropriate event will be logged:
We will not exit a form if a user disables location or revokes the permission.
Data privacy issues
To ensure enumerators are aware that this sensitive data is being gathered...
On first launch of the form, we use a dialog to get consent.
We use the above strategy because if we just ask a yes/no consent question and the user says no, we have no easy way of re-enabling. That is, a yes/no question takes what we expect to be an occasional disabling and turns it into a permanent disable. Using permissions or location providers solves that problem.
The caveat is that this not the easiest thing for users to do. Further, disabling location for the device means no other location apps will work. And revoking permissions means that any required location questions (e.g., geopoint) will not work.
On subsequent launches of the form, we use a snackbar (see image below) to show background location collection status.
This will serve as a reminder to the enumerator that their location is tracked for that specific form. In the case where the enumerator is not the one to open a form for the first time, they will still see the snackbar and have an opportunity to exit the form or turn off location is required for safety or other reasons. Even though Android does show that location is being accessed, it's not clear by which app. The snackbar is clearly associated with Collect.
If location is enabled/disabled during data collection, then we show the snackbar on return to Collect. If this is hard to do, we will show the snackbar on return to Collect (so no need to check enabled/disabled).
Questions
The text was updated successfully, but these errors were encountered: