GPS position update freuquency options / live position

[bnjbnj]

First of all thanks for this wonderful app. It's a really great idea and well done!

But - and I think this is kind of essential in the maybe most important usecase – It was my first time using the app and trying to catch the critical mass today after it started (no GPX track or route given), and it was very hard to do so, as the the GPS coordingates seem to update only every few minutes. I understand this makes it batttery friendly, but maybe it would be an option to allow the user to change the frequency of the GPS updates beween "Live", "Decent" and "Battery Saving"? So at least some (at least one) cyclists with a battery pack can transmit the real live position?

The setting might fit below the "Unsichtbar-Modus" with a Slider/Radiobuttons for quick acces.

Also it would help in this case if you can see your own live position (real live position, not the position from a few minutes ago) to navigate with the map if you are in yet unknown cities / parts of cities. I often needed to either look for street signs and searching them on the map or switching to another Navigation App to find my own position it was also everything else then live.

Thx for taking it into account. I'm glad to help out with testing or evtl. UI design/concept related topics.

[dreua]

I wonder whether that is a design issue or a (device specific?) bug because I never had issues finding the CM. I have, however, only used it in my home town where I have a decent knowledge of the city and its map representation. It may also depend on the size of the CM.

I've been using a Pixel 3a for some time now and its GPS is great in my experience. The Huawei P20 for example is really slow to get a Fix and fast to loose it again in comparison.

Recent smartphones are able to stream videos for hours so I'd assume it should be no issue updating the locations every 10 seconds or so for the duration of a normal CM 🤔

[bnjbnj]

So you say you can see the cm cyclists as well as your own dot moving live or at least updating quickly on the map (as known from Google Maps, WhatsApp, Signal or any other location sharing functionalities)?
For me they just jumped every view minutes to a new position, same for my own position on my phone itself.
The CM was quite small with only about 25-30 people and probably around 7-10 sharing the location.

If it is intended to be more fluent as I had the experience, it might be device specific or could also have been server related.
What would be the interval it should update?

[cbalster]

Hey, first of all thank you for your feedback and the kind words. :)
The way it works right now is actually a little more complicated. The main reason for the delay in updates is not actually battery savings (although this is part of it), but data usage (size as well as number of requests) for both the users' devices, but also our servers.
Let me break down the way it works right now:

1. The app gets the current location from GPS/WIFI providers every 12 seconds AND if the distance to the last position is bigger than 20 meters. After that some logic is applied to filter out old or imprecise location fixes. This is the battery savings part.
2. The app sends the last known position to our backend servers every 30 seconds (note that this happens by time, not triggered by a new location as described in 1)).
3. While the map is open two things happen: a) when the map is opened and every 30 seconds afterwards, the locations of the other users are retrieved and updated on the map. b) every time your own location is updated in 1) the marker for your location is updated.

This means two things:
a) You will see your own location only update every 12 seconds and only if you're moving. If you're moving really fast (e.g. chasing the mass) in the 12 seconds between updates, you might have covered maybe ~90 meters, which would explain you feeling that the updates are too slow. For the mass itself this is not much of a problem since it moves much slower - maybe 4 m/s max by experience.
b) For every single location of other users you see on the map, in the worst case the location might already be ~70 (12+30+30) seconds old, in the best case only 1 or 2. Over all users this should average out to around half a minute give or take, which would equal around 100 meters of error for the location of the mass.

The reasoning for this is a) use gps as little as needed to prevent battery drain and b) use fixed timings for server communication, so we have more control over server load (and therefore cost).
In our experience those numbers work out quite okay. In your case of a smaller mass (harder to spot) and you still chasing them it might feel different.

In regard to you suggestion I see some potential for how we handle 1). I'm a little reluctant to add another option here, since I think it might confuse less technical people. But we can think about tweaking the time interval to make it feel more responsive. Unfortunately judging the effect on battery drain here is a little difficult.

[dreua]

So you say you can see the cm cyclists as well as your own dot moving live or at least updating quickly on the map (as known from Google Maps, WhatsApp, Signal or any other location sharing functionalities)?

I'll need to check that again, haven't used the app for a while. I just wanted to add the data point that it worked good for me.

30 people is a small mass compared to my experience, it will be significantly shorter and maybe even faster than the use cases I had so far. This could very well explain the differences to the user experience you had.

@cbalster Thanks for the detailed explanation and calculations!
How hard would it be to reduce the 12s timeout (1) as long as the app is active (screen on and app in foreground)? That might be low hanging fruit to improve UX regarding the own position in the "chase" situation. Other apps like StreetComplete or OsmAnd really seem to have little to no delay here and the battery drain will probably be negligible compared to the screen backlight and UI computations.

I have more ideas for improvement on the client side or the communication altogether but I guess this is not an issue of lack of ideas but rather of people implementing and maintaining them.

[cbalster]

How hard would it be to reduce the 12s timeout (1) as long as the app is active (screen on and app in foreground)? That might be low hanging fruit to improve UX regarding the own position in the "chase" situation. Other apps like StreetComplete or OsmAnd really seem to have little to no delay here and the battery drain will probably be negligible compared to the screen backlight and UI computations.

Yep, that was also something I thought of and should be quite easy to implement, but would require a little refactoring.

I have more ideas for improvement on the client side or the communication altogether but I guess this is not an issue of lack of ideas but rather of people implementing and maintaining them.

Spot on. For the last years I've been mainly trying to stay on top of API updates and Android behavior changes, except for some small improvements here or there. Even though the app is working fine and is up-to-date in regard to the newest SDK, at it's core it's based on an architecture and best-practices from 10 years ago. Hopefully at some point someone with a little more time on their hands comes along to give it the refresh it deserves :)