One ways are confusing, can we make it more obvious

[aawiseman]

Browsing around I've found that many one-ways are incorrect -- people mark them properly as a one-way street, but the direction is incorrect. Marking it as yes is easy, but then you have to look at the direction of the way, and I think doing oneway = -1 is confusing to people who aren't expert street editors, you have to go down to all tags, change "yes" to -1.

Maybe when you select one way it says "which direction is it?" Or some other way to make it more apparent.

This seems to be very common from some analysis I've seen, like ~40% being wrong.

[bhousel]

I haven't really heard that oneways are confusing before. Can you elaborate? iD provides a button to easily switch the direction of a way.

[aawiseman]

Ah, I wasn't aware of that and I've been using iD for a long time. When you click the one way checkbox on the tag box on the left it just makes it go the same direction as you drew it, then you either have to know to go down to All tags and type "-1" or know to go over to the side and fix it with the big above -- like I said I think it's a bit tricky and not intuitive unless you already know what to do.

[bhousel]

Is there anything actionable here or can this be closed? It might be worth adding some more text to the builtin help, or adding a task involving oneways in the walkthrough.

[aawiseman]

I sent a mockup idea to @mikelmaron for a way to make it more straightforward. The walkthrough idea would be good as well. I just think it's too easy to click "yes" and not realize the direction is wrong.

[mikelmaron]

Attached are the mockups from @aawiseman
One way mockup (1).pdf

I think there's something here -- thought much to be thought through in UI. The idea of bringing the oneway directionality choices here more obviously into the editing panel, and styling less subtlely, seems solid.

~40% being wrong.

@aawiseman it would really be helpful to see details on this research, say for one city, to get a clearer idea of the connection of the problem to the UI

[bhousel]

Echoing what @mikelmaron said, I'd like to see some details about where you see this mistagging occurring.. 40% seems kind of high to me.

I've always considered the real value of the oneway tag to be an implementation detail - new mappers shouldn't need to know whether it says yes, 1, -1, no, or care too much about which direction the way is drawn, as long as iD renders the oneway arrows correctly and clearly and provides a button to change the direction of the way.

Looping in @samanpwbb, @tmcw because they probably have some insight into the original design of this iD feature.

[tmcw]

💭 It's been a while so I may not have this 100%, but:

• It's true that most tag properties are in the left pane
• But oneway is entirely dependent on the line's draw direction, so its value on the left panel doesn't mean anything outside of the draw direction.
• So showing the value in the left panel doesn't really help editing, because it doesn't mean anything by itself
• But I can imagine someone who both knows OSM and knows it's a tag and thinks properties will be all on the left side and assumes oneway will be
• In that case, the fix, I think, would be to show some nice helptext on the left side that explains how to use the map UI.
• But overall the 40% number needs a citation. My distrust of anecdotal iD damage is, as always, high.

[aawiseman]

But oneway is entirely dependent on the line's draw direction, so its value on the left panel doesn't mean anything outside of the draw direction.
So showing the value in the left panel doesn't really help editing, because it doesn't mean anything by itself

Yeah, the mockup I did that Mikel posted above gets to that. I think that's the issue, you have to know to both click one way and then go over and change direction on the line as well, which is not obvious or self-evident. I think the way it does it now is good but too subtle, and sometimes even hidden by the semi-circle of buttons.

[slhh]

Oneway (and any other direction/side dependent tag) should have an additional button in its preset field. This button should change the direction of the oneway property:

• In case of oneway=-1 change to oneway=yes
• In case of oneway=yes iD might change the direction of the way in order to avoid oneway=-1

The radial menu action to change way direction should be limited to not changinmg the meaning of the data. In case of oneway=yes it needs to be disabled or oneway=-1 needs to be generated.

A radial menu action to change the way direction with change of all directional meanings might be offered too, but this should use a modifier key or a different icon. Please be aware that a way might have multiple direction dependent tags. For example #1762 would add some.

Similar handling of other direction or side dependent tags could solve #1475 .

[slhh]

By the way bicycles are often exempted from the oneway restriction. Therefore the oneway preset should have a checkbox to specify this. Do we need a separate issue for this?

[aawiseman]

Updating per a chat at SOTM-US, sounds like @bhousel was going to add some functionality to make it more clear. Thanks!

[bhousel]

Yes, I was definitely thinking about this the wrong way...

To summarize our discussion, users tag oneways using the checkbox in the left pane, and they might even realize the oneway direction is wrong, but the step to fix it is hidden under the confusing "<<" icon which is not where they are looking (and maybe not even visible if the radial menu is not currently shown). A quick fix would be to add a small "reverse direction" link / button / something near the oneway checkbox.

[aawiseman]

Awesome! Thanks, sounds great. The mockup I posted above also had something like making the arrows within the line flash or something so it's super clear, think that's necessary? #3060 (comment)

[bhousel]

making the arrows within the line flash or something so it's super clear, think that's necessary?

Yeah I'll see if we can do something with the arrows to make them more visible. I haven't looked at this much since we changed the colors last year, and in your screen shot the one way arrows on the narrow service road are definitely not showing clearly.

[slhh]

@bhousel , the "Put something here" position is ok, but I thing placing it one line above in the titelbar of the oneway preset field might be better for the following reason:
The "Put something here" position would be the ideal position if it were just a change of the tag like toggling oneway=yes and oneway=-1. But changing the direction of the way is a very specicial behavior, and placing the button in the title bar would indicate that it is a special preset field.

[bhousel]

Going to work on this today.. This issue gets a bump in priority now that we don't show the radial menu all the time.

[bhousel]

• I added a "change direction" button that will appear only when oneway is yes (or assumed yes)
• I made the markers slightly more opaque

Closing for now...

[slhh]

In general that is fine, but it is still somewhat confusing for the following reasons:

1. Oneway arrow rendering doen't work for short ways, e.g on two-node ways there might be no visible arrow, even if there is plenty of space to place it, and even if the feature is selected.
   Zooming in would show the arrows, but it isn't intuitive to do so because there is already sufficient space to place the arrows. In addition oneway arrows might be hidden by rendering nodes or way direction triangles on top. In case of short ways there is a significant chance that all oneway arrows are hidden.
   I think we should increase oneway arrow density for short ways, and maybe we can hide the way direction triangeles in case of oneway=yes. In case of oneway=-1 we could use an alternating sequence of oneway arrow and way direction triangle.
2. The arrows of the "Change Direction" button are potentially misleading because they might point in the reverse direction of the oneway on the map by chance. Maybe we can omit the visual feedback of the button, which would let user search for the visual feedbeck on the map. In case a visual feedback of the button is desired we could toggle button text "Change direction" and "Direction changed", and/or we can toggle button grey-scaling.
3. Users knowing OSM tagging might get the impression that the "Change Direction" button is toggling between onewy=yes and oneway=-1. In order to avoid this wrong impression, the following means might help:

• Place the button one line above in the field header next to undo and delete bottons.
• Show the message which would be shown if the user were changing the way direction using the "V" shortcut.
• Avoid any changes of the botton due to toggling, except of the change to "Direction changed".

4. Undo of the field doesn't undo the direction change.

[aawiseman]

Awesome, thanks @bhousel !

[bhousel]

Hey @slhh, sorry I didn't respond to your points above, but after editing a bunch with the field this past week, I'm pretty happy with how it works currently and don't plan to change it anytime soon.

1. Users can always zoom in if the features are too small to see them in detail
2. The button originally did not have visual feedback, but I felt it was necessary, so that's why I added the icon. The left-right direction of the icon does not have any connection to the way direction on the map, it's just a stable indicator that will flip when the user clicks the button.
3. Not really concerned about what a user thinks about the underlying tag change. They can just look at the tags if they are curious about this.
4. I agree it would be better for undo to work. But this is hard because that undo button resets the tags, and switching the direction is not really a tag change, it's an action, so it would require extensive changes to how the undo button works.