Context menus on Android are performed usually via long press and actions via tap (if be together).
We haven’t decided yet what to put in it, when to use it, where to put it (depends on 1-2).
As options not changed often while driving belong inside Settings.
Regarding timing, like all features, when it’s designed, implemented and tested can be provided. 
sure, it last as long as it takes… 
normally I would expect that the route is re-calculated to the next waypoint in the planned route when the Button “Skip next waypoint” is used.
Yesterday I had a strange effect when skipping waypoints: I have Skipped all waypoints in Order to get a new route to my planned Destination. But the route was calculated back to the previous planned route, even of there were NO WAYPOINTS any more. I don’t understand why because in this Situation the route should get calculated new and if there ist no more waypoint, then to the Destination.
I wouldn’t call this behaviour rerouting changes the planned route 
Maybe your waypoints weren’t necessary, and Kurviger would have taken that route anyway.
But If you don’t want to share your route we can’t know.
Manfred
I can’t share the route because I was on 4th position of the group driving at high speed… there was no way of taking screenshots or whatever.
For everyone:
Can reproduce the route at home and describe later with *.kurviger files and images what happened. e.g. @SchlesiM’s examples
With just text it’s impossible for us to understand any workflow.
yes that’s generally ok to follow strictly the waypoints (especially when the blue arrow is used). But on Tuesday I had the effect I used the menu to skip waypoints, in fact I had used this several times successively until I had only the destination to go, but the re-calculation was done as if I had not deleted (skipped) the waypoints… that was the weird situation.
The feature discussed here has a different subject, please remain on topic.
maybe this helps a little bit… this is from the GPS recording and the strange thing is that there are gaps of recording… can this maybe be connected to the strange behaviour?
sorry I don’t understand what you mean… I thouht you had extracted this from the topic to create a new discussion
There we discuss a proposed feature to improve some cases, not user reports.
Those have already their own topics and can continue their discussion in them.
(I moved the posts here)
sorry, can’t do this because I don’t know any more where it exactly was while this happened. I had another route as the road captain and wanted to have a new calculation to the destination because I had permanenty the message “route missed” or was off the route. So I used the menu to skip all my waypoints, but it didn’t recognize this. It wanted to drive me back to my originally planned route. This is all what I can say. If this is not enough to guess what could happened, then just forget it. I can’t simulate it too. I can just descibe the behaviour the best I can.
ah ok, now I understand
Thanks for the image.
What location service did you use (Android or Google)? Was Kalman filter enabled?
Generally “Google” is recommended (by them) as more accurate and battery friendly.
At those areas with GPS gaps did navigation work?
Because lack of GPS can lead to “Route missed” messages and no navigation.
Android (thought this would be more precise). Yes, Kalman filter is always enabled.
good, but difficult question, since I don’t know exactly any more where it was, but it was on the way back, could be this area. When GPS lacks can lead to this route missed, I guess this was the reason then for not recalculating the best way to the destination after having skipped all waypoints.
I will observe this next time on the road.
Thanks
If you can, please try next time the Google location service.
To see if can offer an improved experience on your device.
I made another tour with Google location service instead of Android (what is the difference between both?).
This is the tour. We started near Oberkochen in the Swebian East Alb and the destination was also set there. It was a round tour.
The tour was good until I got to Monheim where several road stoppage occured. Driving through them was not possible.
I first tried to find manually a another way, but there were also road stoppages. I had to make a bigger detour. Because it was difficult to identify in which direction the gps showed and I couldn’t bring it in line with the reality, I used the skip next waypoint function to get a new calculated route around this. I even stopped and made new waypoints too. Nothing helped, I didn’t get calculated a correct route back to my destination.
In the screenshot you can see that the gps recording didn’t happen for quite a while. There are many lacks in between, but the gps signal was not lost, it was active on the screen all the time and moved correctly.
The usage of skipping waypoints some times more then resulted in the exchange of my destination from Oberkochen to Monheim. I wasn’t aware of this while driving, just saw this after the tour. I had to stop using kurviger at this time and used my other app Navigon Cruiser to easily find my way home, because I was bugged out by this behaviour and didn’t want to lose more time to guess what happened.
The movement of the destination to antoher area is a big error in my point of view and should never happen. The destination should NEVER be deleted by skipping waypoints. I hope this can be fixed.
The strange thing is also the lacks in the gps recording. Here the change from Android to Google location service obviously didn’t help because in the previous tour the same problem happened with Android location service.
My setting for GPS recording is this
Could the lowest recording speed maybe be the problem? This is set to 3 km/h which is pedestrian speed. When the app cannot identify the correct speed and therefore doesn’t record?
Can see Google’s description for their location provider versus Android native one.
That cannot happen.
Skip next waypoint just skips next via point (if exists), while destination remains always the same.
If GPS sensor on some devices reports unusual readings, they could not pass the GPS logging filters depending on their values.
In such cases can relax or disable some filters and keep the basic ones, mainly time interval and maybe minimum distance.
ok good to hear. if a developing error can be excluded, then the most possible thing what happened is that the wrong menu entry was used.
But then we come to another problem or request reported earlier in another post… the context menu entries are too close together and the touch areas are not usable pinpoint. The font sizes and rectangular sizes should be much bigger than they are now in order to not use the wrong entry with the touch capable gloves. Also good would be that a borderline is drawn between each submenu.
If you are really sure that a development problem can be excluded, then I am sure that exactly this happened: I used insert as destination (german: Setze als Ziel) instead of interim destination (german: Setze als Zwischenziel)… But this should also not happen by accident. This could be avoided by making BIG Squares for each submenu function…
here a screenshot from Nav. Crusier. The separate BIG Action Menus are reached by just swiping to the left and the functions are also customizable.
I can use for example
and the action menus are BIG enough to not accidentially use the wrong one while driving.
Couldn’t you built something similar? This would really help a lot while driving, simple and uniquely usable with motorcycle gloves.
That is already mentioned before and is discussed in:
