Improve Navigation Layout in Portrait and Landscape #3745

New issue

Open

opened 2022-10-28 12:46:14 +00:00 by biodranik · 6 comments

biodranik commented

2022-10-28 12:46:14 +00:00

(Migrated from github.com)

It is about Navigation mode. Motivation:

Increasing/decreasing font size now changes the bottom bar height, which in turn covers the current location blue arrow.
Current arrow position is hard-coded, and is not optimal not only in Portrait but also in Landscape mode.
Top bar in landscape mode takes up too much useful space.

Now thinking about the best solution, there are several ideas:

Do not draw the bottom bar over the map, but draw it under the map. E.g., instead of this:

=========
|       |
|       |
|  map  |
|       |
|       |
|       |
|       |
|-------|
|bar    |
|-------|
=========

draw this:

=========
|       |
|       |
|  map  |
|       |
|       |
|       |
=========
---------
|bar    |
---------

It will not only resolve the offset issue (now it can be safely hard-coded again), but also increases the rendering speed, and saves more battery.

For the landscape, another approach should be used with a custom layout. I see two possible options:

As we discussed previously, something similar to the CarPlay approach, where the top and bottom bars are on the left, while the whole right half of the screen is used for the map, and the blue arrow is centered there.
PROS: important vertical space is not occupied by bars, friendly layout for everyone who tried CarPlay, AppleMaps, etc.
CONS: less map is visible on the right side from the current position.
Bottom bar can be removed, and its info/buttons can be drawn on the left and right corners.
PROS: current position is conveniently centered.
CONS: less vertical space, ineffective use of the top bar (very long street names are very rare).

It is about Navigation mode. Motivation: 1. Increasing/decreasing font size now changes the bottom bar height, which in turn covers the current location blue arrow. 2. Current arrow position is hard-coded, and is not optimal not only in Portrait but also in Landscape mode. 3. Top bar in landscape mode takes up too much useful space. Now thinking about the best solution, there are several ideas: 1. Do not draw the bottom bar _over_ the map, but draw it _under_ the map. E.g., instead of this: ``` ========= | | | | | map | | | | | | | | | |-------| |bar | |-------| ========= ``` draw this: ``` ========= | | | | | map | | | | | | | ========= --------- |bar | --------- ``` It will not only resolve the offset issue (now it can be safely hard-coded again), but also increases the rendering speed, and saves more battery. For the landscape, another approach should be used with a custom layout. I see two possible options: 1. As we discussed previously, something similar to the CarPlay approach, where the top and bottom bars are on the left, while the whole right half of the screen is used for the map, and the blue arrow is centered there. PROS: important vertical space is not occupied by bars, friendly layout for everyone who tried CarPlay, AppleMaps, etc. CONS: less map is visible on the right side from the current position. 2. Bottom bar can be removed, and its info/buttons can be drawn on the left and right corners. PROS: current position is conveniently centered. CONS: less vertical space, ineffective use of the top bar (very long street names are very rare).

pm4rcin commented

2022-10-28 16:16:26 +00:00

(Migrated from github.com)

Portrait:
Definitely putting the bar under map is a great idea.
Landscape:
Definitely 1. not only because it's friendly layout but another thing is that it makes the bottom bar accessible which we could make bigger and add some useful buttons there. I think we also need to think if remaining distance to destination is so important to be as big as it is now. Maybe it should be smaller like in GMaps but someone (artist, designer if there's any in community) should make some drawings with different positions so it'd be much easier to decide. The bottom panel could also occupy whole (or almost whole) half of the screen when expanded so there could be some more options because now there aren't many while it's a useful and handy menu for some actions. And also the top panel could dynamically resize itself to bigger.
That's how I think.

Portrait: Definitely putting the bar under map is a great idea. Landscape: Definitely 1. not only because it's friendly layout but another thing is that it makes the bottom bar accessible which we could make bigger and add some useful buttons there. I think we also need to think if remaining distance to destination is so important to be as big as it is now. Maybe it should be smaller like in GMaps but someone (artist, designer if there's any in community) should make some drawings with different positions so it'd be much easier to decide. The bottom panel could also occupy whole (or almost whole) half of the screen when expanded so there could be some more options because now there aren't many while it's a useful and handy menu for some actions. And also the top panel could dynamically resize itself to bigger. That's how I think.

zyphlar commented

2022-10-28 17:59:37 +00:00

Member

@pm4rcin you may be thinking of a different PR than 3130 if you're talking about top panel sizing (3130 is text-to-speech only)

biodranik commented

2022-10-28 19:55:15 +00:00

(Migrated from github.com)

An ideal nav layout will also have the following:

Speed limit sign (top right, like it is done in CarPlay now?)
Current speed under the speed limit, like it is done now in OM CarPlay (then it shouldn't be displayed on the bottom bar)
Somehow alert driver about a speed camera (and later, in online mode - about road issues, traffic jams, etc.)
Route overview button
Current search, bookmarks, zoom, and position buttons likely should be redesigned to avoid cluttering. Any ideas?

An ideal nav layout will also have the following: - Speed limit sign (top right, like it is done in CarPlay now?) - Current speed under the speed limit, like it is done now in OM CarPlay (then it shouldn't be displayed on the bottom bar) - Somehow alert driver about a speed camera (and later, in online mode - about road issues, traffic jams, etc.) - Route overview button - Current search, bookmarks, zoom, and position buttons likely should be redesigned to avoid cluttering. Any ideas?

biodranik commented

2022-10-28 19:55:54 +00:00

(Migrated from github.com)

There is also a big collection of related improvements here: #1104

pm4rcin commented

2022-10-29 17:50:41 +00:00

(Migrated from github.com)

Every single feature you've mentioned is trivial (someone needs to write a bit of code for each) EXCEPT traffic jams which requires processing (probably) on server. How much is a question to e.g. Magic Earth or any other company that does this. It's probably the most complex problem for FOSS maps projects because you need money (how much? I'd like to know) and probably collaboration with similar projects (OSMand at the time being).

pm4rcin commented

2022-10-29 20:04:14 +00:00

(Migrated from github.com)

@pm4rcin you may be thinking of a different PR than 3130 if you're talking about top panel sizing (3130 is text-to-speech only)

You're probably right. I don't know what I meant because it was a lot of text so maybe I was thinking about something and then deleted. :D

> @pm4rcin you may be thinking of a different PR than 3130 if you're talking about top panel sizing (3130 is text-to-speech only) You're probably right. I don't know what I meant because it was a lot of text so maybe I was thinking about something and then deleted. :D

This repo is archived. You cannot comment on issues.