[EPIC] UI design of Lane connector tool for new features.

[kianzarrin]

• [x] #1485
• [x] #354
• [x] #654
• [x] #1213
• [x] #784
• [x] #1214

• 1500

• 1498

• 670

The UI design for issues above can influence/conflict one another. So I created this issues to discuss solutions.

summary: 1- Hotkeys (https://github.com/CitiesSkylinesMods/TMPE/issues/1479#issuecomment-1074476891 will be adopted for hotkeys/modifiers. thought we might need a new one for creating dead ends.) 2- how should lane connections differentiate between

• making new connection VS removing older connection (#1485)
• unidirectional VS bidirectional
• dead ends (#1213) : use :X: icon 3- how should we differentiate between car/track/mixed lanes:
• for tracked vehicles we can use 🔺 🔻 🔶 to indicate the direction of the lane (it tells us if the lane is bidirectional, it does not tell us if the lane connection is bidirectional).
• for car lanes we can just use 🟠 because they are always uni-directional anyways.
• for mixed lane we can put 🔺 over 🟠 to create a pointy circle

Problems:

Bidirectional lane connections:

• If we use arrow heads :left_right_arrow: to show the direction of the lanes there is two problems:
  • if a lane lane multiple connections then the arrow heads can overlap each other.
  • also the arrow heads can overlap with the lane end icons 🔺 🔻 🔶
  • if we use ❌ for #1213 then it can overlap with the lane end symbols above
• @aubergine10 suggested to use dashed line for bi-directional:
  • if we use dashed line then it might conflict with when we want to remove lane connection if we decide to use dashed line for that too.
  • Also using solid line for uni-directional and dashed line for bi-directional does not seem logical. bidirectional has more connections why should we make it dashed? if anything it should be thickened.

[kianzarrin]

How about this modifier key configuration?

• click: both car/tram/..., bidirectional if possible
• Control+click: unidirectional
• Alt+key: cars only
• shift+click: tram only

[kianzarrin]

shift usually means multiple things are selected so maybe we can do it like this:

• no modifier:
  • always unidirectional lane connection
  • car lane-connections for car-only or mixed(car+tram) lanes
  • track lane-connections for tram/metro/monorail/train lanes
• alt: tracked vehicle only - solves #354 and #654.
• shift: bidirectional on bidirectional lanes | both car tram on mixed lanes
  • bidirectional lane connection on bidirectional lanes
  • both car/tram on mixed lanes

this also helps to reduce number of modifier keys we use and the shift modifier key makes more sense now.

The downside with this is that I think by default we should make bi-directional lane connections on bi-directional lanes so that more novice users will not get confused.

[kianzarrin]

@aubergine10 what do you think we should do with modifier key assignments?

[originalfoo]

The downside with this is that I think by default we should make bi-directional lane connections on bi-directional lanes so that more novice users will not get confused.

Users - both new and existing - will need to learn new stuff whichever way it works. As long as the UI (tracked via https://github.com/CitiesSkylinesMods/TMPE/issues/1214) makes it clear what's going on, there shouldn't be too much of a problem.

IMO having one-directional by default makes more sense than bidirectional; we're routing from lane A to lane B, and additionaly the vast majority of lanes are one-way.

The visualisation should clearly indicate:

• Default lane routings in cases where user hasn't specified custom lane routing (feint/thin dotted white lines?)
• Which lanes are bidirectional (could we overlay a double-ended arrow ↔ on the lane?)
• The direction of a lane connector (pointed triangle at ends? only show where applicable to declutter UI?)

[originalfoo]

As for modifier keys, this approach is best IMO: https://github.com/CitiesSkylinesMods/TMPE/issues/1479#issuecomment-1074476891

[kianzarrin]

@aubergine10 @kvakvs @chameleon-tbn I updated the issue. We need some brainstorming here!

[originalfoo]

for car lanes we can just use 🟠 because they are always uni-directional anyways

Are you sure car lanes are always unidirectional? I'm pretty sure some NExt roads that have central "turning lanes" were bidirectional lanes.

• @aubergine10 suggested to use dashed line for bi-directional:
  • if we use dashed line then it might conflict with when we want to remove lane connection if we decide to use dashed line for that too.
  • Also using solid line for uni-directional and dashed line for bi-directional does not seem logical. bidirectional has more connections why should we make it dashed? if anything it should be thickened.

Yeah, this needs more thought either way. Still pondering that and the other stuff in OP.

[originalfoo]

Random idea: When an incoming lane is selected, fade (reduce opacity of) connection lines from other lanes so connections from the selected lane are more obvious in comparison to them?

[kianzarrin]

Random idea: When an incoming lane is selected, fade (reduce opacity of) connection lines from other lanes so connections from the selected lane are more obvious in comparison to them?

don't we already make such lane connections thicker and on the top? I remember I took care of that : https://github.com/CitiesSkylinesMods/TMPE/pull/635#pullrequestreview-355647204

[kvakvs]

For this i had some ideas, could probably sit down with a pen tablet and draw a little. Things like arrows on connectors, they don't have to be drawn on connector ends. Place arrows on 1/2 of connector lenghts or 1/3 so they don't clump all on the end point. This is how graphing software does it when many arrows arrive to the same end point.

I personally can't remember where we ever had a dual-direction lane. Any good example?

[originalfoo]

I personally can't remember where we ever had a dual-direction lane. Any good example?

Bi-directional train tracks are somewhat common, and there's also some 'turning lanes' on roads that are bidirectional.

Prior implementation of lane connectors were always bi-directional. However, that caused limitations in cases where a uni-directional connector was required, so Kian change to using unidirectional connectors. But that now causes the issue of how to indicate to users a) which lanes are bidirectional and b) which connectors are bidirectional (where applicable).

[kianzarrin]

cool only dead end is remaining

[kianzarrin]

All required tasks are completed. there are a few optional tasks to improve aesthetics.