osmandapp / OsmAnd

OsmAnd
https://osmand.net
Other
4.63k stars 1.01k forks source link

A usability enhancement to improve dynamic responsiveness during navigation #17020

Open NohWayJose opened 1 year ago

NohWayJose commented 1 year ago

The richness of the maps is one of the main benefits and differentiators of OSM but that richness makes it computationally sluggish and sometimes just plain unusable (even on my not too shabby One+ hd1913). This could be tackled, on one level by rendering optimization, but I believe a UX enhancement could help both the rendering issue AND cognitive overload in the navigation mode.

My observation of other products in the navigation space is that they are pretty responsive and I think that's largely because they simplify the UI. They show a bare minimum; the route and only a little context.

It strikes me that OSM could achieve much more responsive rendering and also declutter the navigation mode by allowing the user to select the level of detail shown during navigation. A slider, either in navigation settings or even potentially on the live nav screen, with say 4 or 5 steps from just the route to show everything and the default equating to roughly the level of detail shown in other products, would let a user choose an optimum of responsiveness and sufficient detail for their nav task. Note that their needs may vary from moment to moment, such as when approaching the destination, so having an on screen control would be better than having it hidden in a settings panel. This feature would also positively differentiate OSM from its competition.

vshcherb commented 1 year ago

I think it's the same task as to create new Navigation Panel for Simple overview instead of current set of widgets

NohWayJose commented 1 year ago

Just another thought on this: For navigation mode, categorize the navigation route as primary, the turnings off it as secondary and ordered by the distance along the route and then 'everything else'. Then during navigation, render in that order, with 'everything else' rendered on a non-blocking thread, so it gets done if it can be, but nothing gets held up because of it!

NohWayJose commented 1 year ago

I think it's the same task as to create new Navigation Panel for Simple overview instead of current set of widgets

I sort of see what you mean but I don't think it lends itself to manual switching, it's something that should be automated when in navigation mode. No one driving a powered vehicle or on a bike or horse will be changing profiles as they go!

It's a potential use case that there's a setting to force the UI to behave as it currently does - hammering the rendering to throw detail on the screen with no prioritisation relative to the needs of the user, making everything lag, but if my suggestion was delivered, I can't imagine anyone regressing to that scenario!

NohWayJose commented 9 months ago

Time to do this feature!

ossilator commented 4 weeks ago

to summarize the imo useful ideas here:

NohWayJose commented 3 weeks ago

Yup, that's the basic summary, though I'd reiterate that 'render what's left' should be on a 'best effort' nonblocking thread that allows the higher priority rendering to be completed first. I.e. not just when at standstill, though that might be the most likely render catch-up opportunity.

On 6 September 2024 10:42:08 BST, Oswald Buddenhagen @.***> wrote:

to summarize the imo useful ideas here:

  • add a control (slider?) to quickly set the level of detail
  • add a mode to automatically reduce the level of detail for items further away from the route. maybe still render the full map at standstill.

-- Reply to this email directly or view it on GitHub: https://github.com/osmandapp/OsmAnd/issues/17020#issuecomment-2333676307 You are receiving this because you authored the thread.

Message ID: @.***>