Don't fly back to current location

thany commented

2022-12-08 09:08:11 +00:00

(Migrated from github.com)

When I open the app, it flies to my current location. This only happens when I reopen the app after not using it for "some" amount of time.

I don't want it to fly back to my current location, I wasn't working there. I was adding bookmarks elsewhere. I cannot stop it from doing that, ever. Best I can do is be quick enugh to catch it in the act, pan the map and stop it from moving like that.

But that's a terrible workaround. I just want it NOT to use location services, when I don't need it. That's why I've been asking for the location button to be tristate between disabled, follow location, and follow location+direction.

See also #3067

When I open the app, it flies to my current location. This only happens when I reopen the app after not using it for "some" amount of time. I don't want it to fly back to my current location, I wasn't working there. I was adding bookmarks elsewhere. I cannot stop it from doing that, ever. Best I can do is be quick enugh to catch it in the act, pan the map and stop it from moving like that. But that's a terrible workaround. I just want it NOT to use location services, when I don't need it. That's why I've been asking for the location button to be tristate between disabled, follow location, and follow location+direction. See also #3067

👍 4

biodranik commented

2022-12-08 09:51:26 +00:00

(Migrated from github.com)

Disable location service.
Run OM and make sure that the location button is crossed in OM
Close OM
You can enable location service back.
Enjoy.

1. Disable location service. 2. Run OM and make sure that the location button is crossed in OM 3. Close OM 4. You can enable location service back. 5. Enjoy.

thany commented

2022-12-08 10:04:52 +00:00

(Migrated from github.com)

Good workaround. But that doesn't do away that this is a bug, and/or a feature request for the app itself.

biodranik commented

2022-12-08 10:17:18 +00:00

(Migrated from github.com)

Most people use Organic Maps and other Maps apps to do something in relation to their current position. And most users expect that their location will be detected automatically upon the app launch. We got A LOT of complaints when the behavior was different.

The current behavior is to avoid moving to your current position if <24 hours passed after you stop using OM. That sounds reasonable for most planning actions.

If you have an idea of how it could be implemented better, without breaking the UX, please let us know.

Most people use Organic Maps and other Maps apps to do something in relation to their current position. And most users expect that their location will be detected automatically upon the app launch. We got A LOT of complaints when the behavior was different. The current behavior is to avoid moving to your current position if <24 hours passed after you stop using OM. That sounds reasonable for most planning actions. If you have an idea of how it could be implemented better, without breaking the UX, please let us know.

👍 1

claudiush commented

2022-12-08 17:27:12 +00:00

(Migrated from github.com)

Even though I occasionally am bothered by this behaviour the 24h timeout before resetting to current location seems like the most sensible UX compromise. I think the default should remain like that.

An alternative UX I could think of would be to combine the 24h reset to current location with a toast banner like at the bottom with a bar filling up for 5 seconds that states something like "Resetting Map to current location. Tap to cancel". So the user has a soft way to override the automatism

Even though I occasionally am bothered by this behaviour the 24h timeout before resetting to current location seems like the most sensible UX compromise. I think the default should remain like that. An alternative UX I could think of would be to combine the 24h reset to current location with a toast banner like at the bottom with a bar filling up for 5 seconds that states something like "Resetting Map to current location. Tap to cancel". So the user has a soft way to override the automatism

biodranik commented

2022-12-08 21:59:09 +00:00

(Migrated from github.com)

The "counter" usually works anyway: your device needs some time to detect a location, especially if it's not connected to any network (or network location providers are disabled). Dragging the map at this moment should prevent autoscroll.
But with network location, it happens too fast... And it is suitable for most users.

The "counter" usually works anyway: your device needs some time to detect a location, especially if it's not connected to any network (or network location providers are disabled). Dragging the map at this moment should prevent autoscroll. But with network location, it happens too fast... And it is suitable for most users.

thany commented

2022-12-09 16:28:38 +00:00

(Migrated from github.com)

The solution is a tristate location button, just like MAPS.ME used to have since they bollocksed it up. I don't see why that's such a problem, tbh.

Disabling location access for the app is a hassle, because maybe I want to be able to tap the location button to make it go to my location (surely, that part makes sense, doesn't it). And maybe I want to use it again afterwards to disable it.

What is the disadvantage of a tristate button, other than users who are forgetful enough that they've tapped it to disable? That last part can happen with any setting, mind you.

The solution is a tristate location button, just like MAPS.ME used to have since they bollocksed it up. I don't see why that's *such* a problem, tbh. Disabling location access for the app is a hassle, because maybe I want to be able to tap the location button to make it go to my location (surely, that part makes sense, doesn't it). And maybe I want to use it again afterwards to disable it. What is the disadvantage of a tristate button, other than users who are forgetful enough that they've tapped it to disable? That last part can happen with any setting, mind you.

👍 3

biodranik commented

2022-12-11 10:29:29 +00:00

(Migrated from github.com)

We used that button in MapsWithMe, but then removed the "off" switch from it, because it was inconvenient to turn location off if you really need to switch to another mode instead.

We used that button in MapsWithMe, but then removed the "off" switch from it, because it was inconvenient to _turn location off_ if you really need to _switch to another mode_ instead.

thany commented

2022-12-13 13:34:30 +00:00

(Migrated from github.com)

How is it inconvenient? Just press the button twice. There are only three states...

If you want to switch from location&compass to location only, you press the button twice to skip over the disable state. I really honestly don't see the problem.

Let's put it this way: If the location button must also include a location&compass state, it should be tristate. So another solution is to split the button into two buttons:

Follow location or don't.
Use compass or don't.

If a tristate button really is as evil as I get the impression it might be, then it would need to be split.

How is it inconvenient? Just press the button twice. There are only three states... If you want to switch from location&compass to location only, you press the button twice to skip over the disable state. I *really* honestly don't see the problem. Let's put it this way: If the location button *must* also include a location&compass state, it *should* be tristate. So another solution is to split the button into two buttons: * Follow location or don't. * Use compass or don't. If a tristate button really is as evil as I get the impression it might be, then it would need to be split.

biodranik commented

2022-12-13 15:12:29 +00:00

(Migrated from github.com)

One additional button is even more evil for the UI and UX. There should be a balance. I'm sure there are better solutions for the original issue than breaking other UX cases.

One additional button is even more _evil_ for the UI and UX. There should be a balance. I'm sure there are better solutions for the original issue than breaking other UX cases.

Misalf-git commented

2022-12-13 15:51:32 +00:00

(Migrated from github.com)

I understand the general direction is to keep the app simple and to not pollute the settings page with options barely anyone needs.
If there would be a switch to turn off "center current location uppon app lauch", I would turn it off as well.

I understand the general direction is to keep the app simple and to not pollute the settings page with options barely anyone needs. If there would be a switch to turn off "center current location uppon app lauch", I would turn it off as well.

thany commented

2022-12-19 10:02:27 +00:00

(Migrated from github.com)

If you don't want to add a button, then it merits a setting. There's no shame in adding a setting for something different people may use in different ways. It's more evil to try and make an app "intelligent" as to what the user is trying to achieve.

I see three possibilities:

A tristate button is far easier to implement, much clearer for the user (if done well visually and such), and doesn't require an entry in the settings menu.
An entry in the settings menu requires the user to go into settings to change it, which will be annoying in case they find themselves oftenly have to switch it. Not the end of the world, but also not ideal, iyam.
To try and make this work without any option or button or whatever, is going to require that "intelligence" that some companies are madly in love with (looking at you, Google) which are ultimately confusing because it may work differently every time, there is no clear way to change it, and there is no way to predict how it'll behave next time.

I still opt for 1.

If you don't want to add a button, then it merits a setting. There's no shame in adding a setting for something different people may use in different ways. It's more *evil* to try and make an app "intelligent" as to what the user is trying to achieve. I see three possibilities: 1. A tristate button is far easier to implement, much clearer for the user (if done well visually and such), and doesn't require an entry in the settings menu. 2. An entry in the settings menu requires the user to go into settings to change it, which will be annoying in case they find themselves oftenly have to switch it. Not the end of the world, but also not ideal, iyam. 3. To try and make this work without any option or button or whatever, is going to require that "intelligence" that some companies are madly in love with (looking at you, Google) which are ultimately confusing because it may work differently every time, there is no clear way to change it, and there is no way to predict how it'll behave next time. I still opt for 1.

👍 2

biodranik commented

2022-12-19 13:19:10 +00:00

(Migrated from github.com)

Let's clarify the use case again.

When don't you need to "fly" to your current location? When you're adding bookmarks, paused it for more than a day, and want to continue doing it again. Right?
When do you need to "fly" to your current location? When you want to use the map to locate yourself as fast as possible, ideally without pressing any buttons.

The right questions are:

What is the proportion of (1) vs (2) in your case? Do you add bookmarks most of the time, and only locate yourself occasionally?
Are there some hints that we can detect locally on your device and use locally (without collecting data from you on some servers, in contrast with Big Tech), so the "guessing" of OM about what should be done can be improved?

Let's clarify the use case again. 1. When don't you need to "fly" to your current location? When you're adding bookmarks, paused it for more than a day, and want to continue doing it again. Right? 2. When do you _need_ to "fly" to your current location? When you want to use the map to locate yourself as fast as possible, ideally without pressing any buttons. The right questions are: 1. What is the proportion of (1) vs (2) in your case? Do you add bookmarks most of the time, and only locate yourself occasionally? 2. Are there some hints that we can detect locally on your device and use locally (without collecting data from you on some servers, in contrast with Big Tech), so the "guessing" of OM about what should be done can be improved?

thany commented

2022-12-19 20:29:24 +00:00

(Migrated from github.com)

I prepare for my holiday (adding bookmarks and whatall) for a few weeks so then I rarely need it to fly to my current location. However, when I'm on that holiday, my markers are there and I do need it to fly to my location. Except when I'm looking around to see what the things around me were again, that I bookmarked.
Well, sure. Sort of. When I say "when I'm not in The Netherlands" that's gonna make for a very strange option to switch in the preferences, isn't it 😄

Basically it comes down to this: I want it to fly to my current location when I say so. And otherwise, ehm, not.

When you want to persue doing something with (2), you might end up with a far more confusing UI. I imagine there shall be an option that says:

Fly to my current location when:

I'm not home
I'm outside my home country
I'm already moving
I'm at altitude

Surely this is more confusing. Please don't do this 😀

May I now please ask you to explain clearly what your problem is with a tristate button? Maybe we are just imagining something totally different from what the other is thinking. Mayhaps all you need is some real-world examples of tristate switches. I'm sure I have a few devices laying around that have one.

1. I prepare for my holiday (adding bookmarks and whatall) for a few weeks so then I rarely need it to fly to my current location. However, when I'm on that holiday, my markers are there and I do need it to fly to my location. Except when I'm looking around to see what the things around me were again, that I bookmarked. 2. Well, sure. Sort of. When I say "when I'm not in The Netherlands" that's gonna make for a very strange option to switch in the preferences, isn't it 😄 Basically it comes down to this: I want it to fly to my current location _when I say so_. And otherwise, ehm, not. When you want to persue doing something with (2), you might end up with a _far_ more confusing UI. I imagine there shall be an option that says: Fly to my current location when: - [ ] I'm not home - [ ] I'm outside my home country - [ ] I'm already moving - [ ] I'm at altitude Surely this is more confusing. Please don't do this 😀 ---- May I now please ask you to explain clearly what your problem is with a tristate button? Maybe we are just imagining something totally different from what the other is thinking. Mayhaps all you need is some real-world examples of tristate switches. I'm sure I have a few devices laying around that have one.

biodranik commented

2022-12-19 21:33:25 +00:00

(Migrated from github.com)

Yes, some examples would be helpful. I know how it worked in MapsWithMe 9-10 years ago.

What I see from your description: you're not using OM to travel locally. You use it only when you're traveling somewhere.
There are two sides here:

OM can detect that pattern/type of user and be smart.
OM can become more useful locally, so you also use it more often at/near your home.

Yes, some examples would be helpful. I know how it worked in MapsWithMe 9-10 years ago. What I see from your description: you're not using OM to travel locally. You use it only when you're traveling somewhere. There are two sides here: 1. OM can detect that pattern/type of user and be smart. 2. OM can become more useful locally, so you also use it more often at/near your home.

thany commented

2022-12-21 15:34:37 +00:00

(Migrated from github.com)

Please don't make it smart. I said it before, and I will say it again: smartness is hard to predict and comprehend. You'd have to "blindly" trust that the app will do whatever it deems correct, without having any say in the matter.

Making it more useful locally would mean that I'm going to have to test its driving directions capability. In Google Maps it is bloody awesome, that's why I just don't switch. Also I don't "need" an offline maps app in my own country, because mobile data is only terribly expensive when abroad.

Here are some examples:

A switch on my keyboard between wireless/OFF/bluetooth.

A switch on my mouse to select one of three devices it can be paired with.

So yes, these aren't GUI examples, I hope you weren't expecting those, because for those I'll have to look a bit further. But especially the mouse appears to implement something that very clearly communicates the fact that it is a three-state button, and what the current state of that button is. I think something like that translates well into a GUI element.

Please don't make it smart. I said it before, and I will say it again: smartness is hard to predict and comprehend. You'd have to "blindly" trust that the app will do whatever it deems correct, without having any say in the matter. Making it more useful locally would mean that I'm going to have to test its driving directions capability. In Google Maps it is bloody awesome, that's why I just don't switch. Also I don't "need" an offline maps app in my own country, because mobile data is only terribly expensive when abroad. Here are some examples: ![IMG_20221221_163718](https://user-images.githubusercontent.com/152227/208943787-7feaaa71-d483-482c-bd9b-c412d88adf39.jpg) A switch on my keyboard between wireless/OFF/bluetooth. ![IMG_20221221_163641](https://user-images.githubusercontent.com/152227/208943792-a9954e33-bbaa-4070-8526-68cd128faa8b.jpg) A switch on my mouse to select one of three devices it can be paired with. So yes, these aren't GUI examples, I hope you weren't expecting those, because for those I'll have to look a bit further. But especially the mouse appears to implement something that very clearly communicates the fact that it is a three-state button, and what the current state of that button is. I think something like that translates well into a GUI element.

vbertola commented

2022-12-26 12:05:27 +00:00

(Migrated from github.com)

Yes, please, please! I hate this, I am home planning a future trip in some other part of the world, I stop for the day, I resume the following day and as soon as I open the app it starts flying back to my own home and neighbourhood, which I already know inch by inch, and I have to fight against it with my fingers, and it really doesn't want to stop!

I should just have a location button in the UI to bring me to the current location when I want so. If you do not want to change this behaviour for everyone, please give me a setting so that I can disable this annoying thing for me, forever and ever, and use the location button when I need to zoom back on my position, like Google Maps does.

Oh, and definitely it's not disabled for 24 hours - yesterday night I was working on Mexico City, I just reopened the app and it brought me back home, and only ~14 hours have passed.

Yes, please, please! I hate this, I am home planning a future trip in some other part of the world, I stop for the day, I resume the following day and as soon as I open the app it starts flying back to my own home and neighbourhood, which I already know inch by inch, and I have to fight against it with my fingers, and it really doesn't want to stop! I should just have a location button in the UI to bring me to the current location when I want so. If you do not want to change this behaviour for everyone, please give me a setting so that I can disable this annoying thing for me, forever and ever, and use the location button when I need to zoom back on my position, like Google Maps does. Oh, and definitely it's not disabled for 24 hours - yesterday night I was working on Mexico City, I just reopened the app and it brought me back home, and only ~14 hours have passed.

👍 3

biodranik commented

2022-12-26 13:02:49 +00:00

(Migrated from github.com)

@rtsisyk can you please investigate the current behavior? We can "hot-fix" it by increasing the delay to 48 hours. But it looks strange to me that position mode is restored earlier.

thany commented

2023-01-02 11:52:32 +00:00

(Migrated from github.com)

If it's set to 24 hours, hotfixing it to 48 hours isn't going to help. More to the point, where does this seemingly arbitrary delay of 24 hours come from? How is this decided, and why isn't this just a setting?

I've said it before and I will say it again: please don't make the app "smart". Smartness is hard to predict and oftenly comes as a surprise, making it feel unreliable. Sometimes it's good, but it's really hard to absolutely nail it. So we should just avoid it.

Having said that, happy new year 😀 Here's to a great year for OSM and Organic Maps.

If it's set to 24 hours, hotfixing it to 48 hours isn't going to help. More to the point, where does this seemingly arbitrary delay of 24 hours come from? How is this decided, and why isn't this just a setting? I've said it before and I will say it again: please don't make the app "smart". Smartness is hard to predict and oftenly comes as a surprise, making it feel unreliable. Sometimes it's good, but it's *really* hard to absolutely nail it. So we should just avoid it. Having said that, happy new year 😀 Here's to a great year for OSM and Organic Maps.

biodranik commented

2023-01-02 14:06:05 +00:00

(Migrated from github.com)

@thany Actually, there is an 8 hours limit now in the code that changes the Not Follow position mode to the Follow one.

For your specific case there is a working solution:

Disable location in the device's settings.
Run OM and make sure that it shows a crossed crosshair (position) button/icon.

Now if you close OM, it will save that "No Position" mode and will never restore it back until you manually press the crosshair button.

Furthermore, the search in remote areas where you are looking on the map will work better, your current position won't influence search results anymore.

@thany Actually, there is an 8 hours limit now in the code that changes the _Not Follow_ position mode to the _Follow_ one. For your specific case there is a working solution: 1. Disable location in the device's settings. 2. Run OM and make sure that it shows a crossed crosshair (position) button/icon. Now if you close OM, it will save that "No Position" mode and will never restore it back until you manually press the crosshair button. Furthermore, the search in remote areas where you are looking on the map will work better, your current position won't influence search results anymore.

thany commented

2023-01-04 08:16:23 +00:00

(Migrated from github.com)

Yes, if I disable location entirely, it's """"solved"""", this is something we knew at the very start of this issue. And this workaround is completely beside the issue at hand. THe issue is to integrate this gracefully in the app, not to require 15 taps (more or less, I'm not joking) to enable/disable a seemingly simple thing.

biodranik commented

2023-01-04 10:54:24 +00:00

(Migrated from github.com)

@thany I completely understand your disappointment. Please also look at it from our position: should we break the existing convenient UX for thousands of users only to satisfy your use case?

In your case, when you are using OM exclusively for planning remote trips during days or weeks, it is very easy to disable location service once, and then use OM without the current location during these days/weeks. Implementing a tri-state button only for use cases like this one looks like a big overkill to me at the moment.

@thany I completely understand your disappointment. Please also look at it from our position: should we break the existing convenient UX for thousands of users only to satisfy your use case? In your case, when you are using OM exclusively for planning remote trips during days or weeks, it is very easy to disable location service once, and then use OM without the current location during these days/weeks. Implementing a tri-state button only for use cases like this one looks like a big overkill to me at the moment.

👎 1

Misalf-git commented

2023-01-04 17:48:12 +00:00

(Migrated from github.com)

There could be more than just a few users seeing the current behavior as inconvenient but they just don't complain. Especially when there is already a lengthly discussion about it going on.
Breaking the UX for one group by drastically changing behavior is ofcourse unwanted. I believe a setting for this deserves consideration.
I haven't used too many Map Apps but quite a few don't automatically center on current location:
Vespucci, StreetComplete and Cruiser come to my mind.
OsmAnd does center on current location and I couldn't be arsed to find a setting in it's convoluted options structure to turn that off. ;)

There could be more than just a few users seeing the current behavior as inconvenient but they just don't complain. Especially when there is already a lengthly discussion about it going on. Breaking the UX for one group by drastically changing behavior is ofcourse unwanted. I believe a setting for this deserves consideration. I haven't used too many Map Apps but quite a few don't automatically center on current location: Vespucci, StreetComplete and Cruiser come to my mind. OsmAnd does center on current location and I couldn't be arsed to find a setting in it's convoluted options structure to turn that off. ;)

thany commented

2023-01-05 10:38:27 +00:00

(Migrated from github.com)

@biodranik No offense, but I don't think you understand. Who said we should break existing UX? A tristate button doesn't do that.

I will look at it from your perspective then: "we shouldn't change any UX because users are happy with everything the way it is". This is obviously a false statement, and laughably so. I'm half-joking of course, but it's also kind of what I'm reading in your replies. But then, bear in mind, you've actually already broken the UX by making it inconsistent.

If location can be turned ON (which you can absolutely do, because it can be turned off by panning away) you must also be able to turn it off with the same or similar user interaction: tapping it. So in a sense, the location button is now inconsistent:

It can be turn OFF by panning away (which is not persisted)
It can be turned ON by tapping it (which is persisted, implicitly)
And then there's a third state, which is to follow compass.

So in a sense, the tristate-ness is already there. All I'm asking is to be able to:

Get it to the OFF state not by panning away but (also) by tapping it. If I can tap the location button in its OFF state in order to fly back to my location, why can I not also tap it to get it back to the OFF state?
Persist this state, even after an arbitrary number of hours, but only if OFF state was achieved by an explicit user interaction (tapping it).

The button even already has three visual states! You could add a visual cue for the other states, but you're kidding yourself if you're saying a tristate button is overkill, because it already is. It just behaves inconsistently and doesn't persist.

@biodranik No offense, but I don't think you understand. Who said we should break existing UX? A tristate button doesn't do that. I will look at it from your perspective then: "we shouldn't change any UX because users are happy with everything the way it is". This is obviously a false statement, and laughably so. I'm half-joking of course, but it's also kind of what I'm reading in your replies. But then, bear in mind, you've actually already broken the UX by making it inconsistent. If location can be turned ON (which you *can absolutely do*, because it can be turned off by panning away) you must also be able to turn it off with the same or similar user interaction: tapping it. So in a sense, the location button is now inconsistent: * It can be turn OFF by panning away (which is not persisted) * It can be turned ON by tapping it (which *is* persisted, implicitly) * And then there's a third state, which is to follow compass. So in a sense, the tristate-ness is already there. All I'm asking is to be able to: * Get it to the OFF state not by panning away but (also) by tapping it. If I can tap the location button in its OFF state in order to fly back to my location, why can I not also tap it to get it back to the OFF state? * Persist this state, even after an arbitrary number of hours, but only if OFF state was achieved by an explicit user interaction (tapping it). The button even already has three visual states! You could add a visual cue for the other states, but you're kidding yourself if you're saying a tristate button is overkill, because it already is. It just behaves inconsistently and doesn't persist.

👍 1

biodranik commented

2023-01-05 13:23:54 +00:00

(Migrated from github.com)

Please don't nit-pick. Adding one more state to the current flow will definitely break UX. Example:

I want to enable map rotation to better understand my position and directions. I click my position arrow to center the map (if it is not already centered). Then I click it again to enable rotation.

After that, I want to go back to the "north up" mode. I press the location button again. Here, if you add another "GPS off" state, I will be very surprised if my position will disappear from the map.

And even if I understand what just happened, I need to do another click to finally return back to the "north up" mode.

Please don't nit-pick. Adding one more state to the current flow will definitely break UX. Example: I want to enable map rotation to better understand my position and directions. I click my position arrow to center the map (if it is not already centered). Then I click it again to enable rotation. After that, I want to go back to the "north up" mode. I press the location button again. Here, if you add another "GPS off" state, I will be very surprised if my position will disappear from the map. And even if I understand what just happened, I need to do another click to finally return back to the "north up" mode.

😕 1

thany commented

2023-01-08 21:20:15 +00:00

(Migrated from github.com)

I'm not nitpicking.

You're making an effort to describe how the app currently works. Does it have to? It's not holy. I could copypaste your reply and describe how it would work with my solution, job done.

The challenge here lies in the UX. How can you make it so that it covers your and my use-case perfectly? tap-and-hold the location button? Make its current state much clearer than it is now? Add a toaster that says "follow location is disabled, tap again to enable" or similar? All of the above?

If you keep hammering on your opinion (with all due respect) that the current location button is completely perfect, this discussion will lead nowhere.

I'm not nitpicking. You're making an effort to describe how the app currently works. Does it have to? It's not holy. I could copypaste your reply and describe how it would work with my solution, job done. The challenge here lies in the UX. How can you make it so that it covers your and my use-case perfectly? tap-and-hold the location button? Make its current state much clearer than it is now? Add a toaster that says "follow location is disabled, tap again to enable" or similar? All of the above? If you keep hammering on your opinion (with all due respect) that the current location button is completely perfect, this discussion will lead nowhere.

👍 2

biodranik commented

2023-01-08 22:07:23 +00:00

(Migrated from github.com)

We are open to any great ideas that are 1) intuitive and 2) do not break the already working UX.

Rows
Columns

Don't fly back to current location #4047