Navigation/route planning uses GPS instead of map point

Yeah, but what if I want to find the way from certain point to another certain point?

E.g. to show my friend how to get from the meeting point to the coffee place. Or if I want to quickly measure distance and time from one place to another to choose the best way, once I'll be at the place.

There are more ways to do it. Fast or more complicated.

Sure, but the problem is that I've choosen one way, which seems to be correct (based on information from the UI), but it produces incorrect result.

The seamless UX in the thirdparty app was mentioned just as a refference to possible better solution and as a demonstration of IMO correct behaviour of the navigation system, which could be used in Locus too (but discussion about it should be probably elsewhere).

Hi, thanks, I understand what you mean. My bug report is about the unexpected behaviour of the navigation/route planning system.

The idea is that when user gives the time to set up all conditions for route planning from point A to point B, he's briefly informed by the UI that the route will be planned from A to B and he's then navigated from different place to point B, it's not the intended, desired behaviour. Note that the user has to spend time preparing the planning, including manual interaction (points selection, navigation in menu), then he has to wait a moment for the correct calculation from A to B and then for the wrong calculation from his GPS position to B. At the end he gets something he did not order.

The idea is that automatic recalculation (whatever it is) should not be applied in this case, because then the route planning from A to B is meaningless, when it doesn't work.

The problem with the dialog is that it appears after single press of the Back button. And when the user stops the navigation only (notice that he can press the minimize or the stop & quit button in the dialog, if he wants to exit the app), he's asked to quit app instead of return to map (without running navigation). Maybe this issue should be reported separately…

HW back button closes dialogs in Locus. In navigation mode there's no such dialog and the app understands pushing the back button as an order to quit. Nevertheless, there's the navigation process running, therefore, Locus asks for confirmation. Locus behaves like this for ages and be sure, if it was thought to be a bug, we would have changed or removed it.

I agree. But again – in the dialog user can choose to exit the app. If he doesn't want to exit, but only to stop navigation – he logically chooses only to stop the navigation. The point is that the app then asks him again to exit – but in that time the app already knows (based on the user action) that he doesn't want to exit the app (he has choosen to stop navigation, not to stop and exit, nor keep it running and exit). So the second confirmation dialog shouldn't be there, because it's superfluous, annoying and gives user again an option to exit the app (but we want him to stay and use our app, don't we?).

Thanks for comments.

1. "Navigation to" screen

I look forward to improved navigation in the future :-) Please notice it would be great to improve the navigation towards the seamless experience, when the user doesn't lose the contact with the map (notice the route planning in e.g. Maps.Me (everything happens on the map) vs in Locus (massive dialog to set up and confirm)). Personally I would really appreciate direct option to plan route not only to destination, but also from certain place/my position (I showed this in the Maps.Me video).

2. "Close dialog"

I understand the purpose of the exit dialog. The info about running tasks is also good and valuable. The point is that the standard system/device Back button is used not only for exitting the app, but also for the back actions, including, but not limited to, hidding menus and UI elements, navigation back, stopping activities etc. In this situation is IMO expected, that when user wants to stop the navigation, he uses the Back button. The appearence of the confirm dialog is then okay, to prevent accidental stop.

Expecting that user will use only the hidden (and also nonstandard) option to stop the navigation, instead of using standard system/device button (which is used almost everytime) is restrictive and IMO not in compliance with the intuitive and seamless UX.

The problem consists in the close dialog, which appears after stopping all running tasks. (Since the dialog refreshes and the visual is different, it's not the same dialog.) Again – no tasks are running, user stopped them in the dialog. What do you think he'll do after stopping all of them? Exit the app? I don't think so, because otherwise he would choose to "stop & exit". So in that time is clear that he doesn't want to quit the app, so asking him to exit doesn't make sense.

So the solution is to ask user if he wants to stop, but if there are no running tasks (he stopped the navigation), then just close the dialog and return to the map screen, without asking him again for the same thing.

So that's my feedback :-)

It is necessary to compare also functionality around creating a routes in Locus vs other apps. I've decided to made Route planner as a separate screen because of huge number of features that otherwise complicate main map screen a lot.

Close dialog ... cannot say I completely dissagree. So let's try it ;).