Arrange turn lines across the entire width

[abhishek1508]

Lane guidance view should arrange turn lines across the entire width of the view rather than centered in the view.

cc @d-prukop @zugaldia @truburt @jyrigo @AhmerKhan1 @mapbox/navigation-android @mapbox/navigation-ios

[1ec5]

Is this suggestion limited to a landscape layout like the one shown above, or would the icons also be distributed evenly across the entire screen in a portrait orientation?

(Since you tagged the iOS navigation SDK team, I should point out that the iOS navigation SDK doesn’t have a landscape layout yet: mapbox/mapbox-navigation-ios#1139. But I assume we’d aim for consistency with the interface in CarPlay. At one point, we had to be careful not to make the total set of lane icons too wide or CarPlay would crash, but I think that’s been fixed.)

[AhmerKhan1]

@1ec5 @abhishek1508 Ideally, it would be helpful to keep the icons distributed in a portrait mode as well. If there is a better experience showcasing the entire width across the display, then we should ensure that is consistent across both orientations.

[abhishek1508]

Yeah I guess the ticket is targeting more on the fact, whether the lane icons should be distributed throughout the width rather than centered in the view. I agree with @AhmerKhan1 once we make a decision on this, it would be applicable to both portrait and landscape modes.

@d-prukop @avi-c I would like your take on it to understand if you think distributed lane icons have a better experience?

[yuryybk]

@abhishek1508 @d-prukop @avi-c do you have any progress with this decision?

This screenshot is taken from the Dash app, and this layout is already in production. And also it was accepted by the delivery team in the Mapbox and the internal validation team of one of the customers.

The only bad thing here is that Dash uses its own forked and customized version of the MapboxLaneGuidanceAdapter from Nav SDK code. As the driver-apps team tries to avoid forked code for the next release it would be nice to have an option to manage this arrangement inside the Nav SDK.

[abhishek1508]

cc @lawsonkight

[lawsonkight]

I would like to limit the max-width of the lane guidance. The current version looks odd in dash, especially with two or three lane arrows, and customer applications may use even wider guidance cards.

I recommend centering the lane guidance, with a max-spacing between elements of 20px. In the event of overflow the icons can move closer together.

[abhishek1508]

@lawsonkight What happens if there are many lanes so that it does not fit in the view no matter it's centered or arranged across? Should they be horizontally scrollable?

/cc @yuryybk

[abhishek1508]

There seems to be a lot of variables in deciding the min and max spacing between the items in this horizontal list. For ex:

• should there be a min-spacing?
• how would we decide on a good min/max spacing since guidance card can have varying width?
• min/max spacing would also be affected by different device density pixels.
• should the list be scrollable horizontally?

Should we rather introduce an option for the end user: shouldCenterLaneGuidance? The default value would be true.

• If true: The items will be centered with no min/max spacing. SDK will decide a spacing that looks good on different screen sizes. If the items overflow, the list would then be scrollable.
• If false: The items will span across the width, no matter there are 1, 2 or 20 items. In this case all the items will be displayed and the list won't be scrollable horizontally, since the spacing between the items will be decided at runtime. The spacing can be 0 if there are too many items and it becomes difficult to fit them all on the view.

@lawsonkight @yuryybk

/cc @MaximAlien for visibility

[lawsonkight]

@abhishek1508 The above images are specific to the GM Dash implementation, and not created with mobile or the Nav SDK in mind.

My ultimate preference is that lane guidance is above the maneuver card and left aligned in most cases.

In the event of overflow, extraneous lanes can go off-card, with alignment based on whether the driver should be in a right, left, or center lane. The lanes do not need be scroll, and a gradient mask can be used to hide the clipping.

[abhishek1508]

Oh yes absolutely and I really like the new design although use of gradient mask to hide the clipping is something we would have to discuss when we take up this task. The designs you have shared above are more longer term and is a major change in the SDK that probably may/may not lead to breaking changes. To make sure we address concerns from GM in the shorter term for their Maps+ v1.3 internal release mid January, does this makes sense?

@lawsonkight

[lawsonkight]

@abhishek1508 I do not think shouldCenterLaneGuidance is the right approach. In the event that the list overflows, drivers will not know to scroll, and if they do, it becomes a safety issue. Additionally, overflowing the outside lanes through centering ensures that turn guidance will always be off-screen in overflow situations.

Instead, I recommend using the true scenario by default (SDK decides appropriate spacing, using a max-spacing value), with a min-spacing of 0 to prevent overflow.

[abhishek1508]

Okay so if I understand you correct, we always center the lanes with some spacing and use 0 spacing in the event there are many lanes thereby disabling scroll. @lawsonkight

Are you ok with this approach @yuryybk ?

[yuryybk]

@abhishek1508 IMO if Nav SDK will be able to select the different appropriate spacing with centering for the 2 or 5 or 7 icons it would be a better solution than just alignment across the whole width. 0 spacing is ok too for the many lines.

Maybe spacing could be a customizable option too for the Nav SDK consumers if some tricky visual representation is required.

/cc @AntonBaikou

[abhishek1508]

FYI, so we can discuss and have parity between platforms

/cc @mapbox/navigation-ios

[MaximAlien]

I'm more in favor of keeping maneuvers centered. If we expand all maneuvers across width of the underlying parent view it'll be hard to see all of them at the same time, and during driving quick glance, which contains whole picture is preferred. Here's how expanded maneuvers going to look like on devices with large widths:

Spacing can be different, but it's still hard to see.

[yuryybk]

@abhishek1508 @MaximAlien do you have any updates and ETA for the implementation?

[zugaldia]

@yuryybk Nothing to update as of yet due to other UI priorities. I'll work with @AhmerKhan1 to schedule its work and communicate here when that happens.