Make tag diff more discoverable

[kymckay]

Personally I was unaware there was a way to see the tag diff before applying an autofix until I saw it in a screenshot. Before learning about it I was actually undoing/redoing to check which tags changed.

I think to improve usability any autofix that changes tags should show the user the diff before it is applied (without having to click the information button), otherwise from user perspective you're applying a fix which you don't actually know what it's doing.

This can also serve as an indirect learning method to see which tagging is preferred.

Since UI space is precious and it'd probably look bad to always have the diff there, showing it when hovered over the fix seems reasonable.

[quincylvania]

This seems like a case where casual and advanced iD mappers have different needs.

Casual mappers should never really have to deal with tags (especially non-English speakers). For these people the diff table isn't particularly helpful and risks confusion. Advanced mappers (those of use here, myself included) want to verify the changes iD is making on their behalf. Thus the diff table is quite useful.

Personally I think putting the diff table behind the info button is a good compromise. Casual mappers don't have to worry about it and everyone else can see it at will. I'm not sure how "hover" display would even work in the UI, since it's unexpected for a whole table to appear just from mousing over something.

I'll leave this open for further discussion but I'm inclined to leave the current functionality.

[kymckay]

Now that I've been using this for a while, I tend to agree that for the more advanced mapper's needs having it behind the info button is fine.

However, it could perhaps be made more discoverable (which I'm not sure how to achieve presently).

[quincylvania]

However, it could perhaps be made more discoverable

Good point. You wouldn't necessarily look for anything like this under the info button when you're used to it just showing some general text.

[1ec5]

How about changing the icon from ℹ️ (which normally means “help”, not “more details”) to ⁺⁄₋?

Also, how about persisting the choice to show or hide the diff? I’m guessing a user either knows and cares about tags or doesn’t know and doesn’t care about tags, but that it doesn’t really depend on the particular upgrade being suggested.

[quincylvania]

How about changing the icon from ℹ️ (which normally means “help”, not “more details”) to ⁺⁄₋?

I think I'd just add a second button to avoid mixing the meanings and so advanced mappers don't have to see the help text every time.

Also, how about persisting the choice to show or hide the diff?

Sounds reasonable 👍

[lgommans]

I didn't find this ticket before opening #8143. To recap, I wrote:

Rather than asking people to apply unspecified changes and requiring an extra click to see what change you will be making, iD should show what tagging changes it is proposing. Honestly, nobody should be clicking automatic edit buttons unless it's an approved import and their click is part of that approved process

In response to which @lectrician1 proposed the following design:

I like this. I would prefer this format better:

---

@quincylvania wrote in the current ticket:

This seems like a case where casual and advanced iD mappers have different needs.

If any mapper needs to make a decision about tags being changed, they need to see the tags. It's under their name and not an approved mechanical edit, after all. If they are incapable of judging the change, then they should not be deciding to make the change. If we want to push corrections to the map then I see these options:

• circumvent mechanical editing rules and apply any changes silently and automatically in their changeset, or make them click a button to the same effect so it's purportedly not mechanical (current situation);
• go through the mechanical edit procedure and do a map-wide edit so we don't collectively have to do a million manual clicks;
• if we don't want to have people blindly apply the change (be that automatically or with a button) and the rule is not reliable enough for a map-wide mechanical edit, sufficiently experienced mappers need to judge applying those probably-OK changes; or
• if we merely need a pair of human eyes on the changes being applied but a casual mapper can perfectly well do it, then they should be told what to base the decision on (example: "if this is indeed a bus stop, please upgrade this object's tags" -> sets bus=yes).

Would you be opposed to lectrician1's suggestion? Or should we change the upgrade rules so there is a criterion (or criteria) specified and shown for the casual mappers whose help we could use?