[OSM-dev] iD news - 2.12.0 released 🎉

[Sarah Hoffmann]

On Mon, Dec 10, 2018 at 09:54:23AM -0500, Bryan Housel wrote:
> Sure, I can describe the logic in more detail.  
> 
> When I talk about “fields”, I mean the fields near the top of iD’s sidebar.  Users can still edit all the raw tags in the tag editor that appears below the fields.  
> 
> The purpose of this feature is not really to prevent someone who knows what they are doing from changing a tag value, but more to hint to users (especially newbies) “hey maybe you should not change that”.  
> 
> The protection should discourage people from changing the Name field just for fun, but also make sure that if a business re-brands (e.g. a Shell station changes to an Exxon station) someone changes all the tags and not just the Name that gets rendered.

That's all well meaning but somehow I doubt that a read-only field
will achieve these goals. I see one of two things happen: a
casual mapper who just wants to fix something suddenly finds
that they cannot change stuff and just leave. And the people,
who change names just for fun will randomly poke at the user
interface until their change goes through.

I tried the latter a bit. Lets assume somebody realises that
this McDonalds is actually a Burger King:
https://www.openstreetmap.org/way/586629904

Trying to change that in the new iD, here is the things that
happened during a few minutes me poking the interface in an
attempt to achieve that goal:

* Change only Operator because it is the only editable field that contains
  the offending 'McDonalds' name.

* Change all 'McDonalds' in the raw list of tags. Leaving the wikidata
  field as is because there is no way to know that there is any
	correspondence.

* Actually bother to read the tool tip that appears on the locked name,
	don't understand a word it says (what is that wikidata it is speaking
	of?). The only thing that parses is: 'delete it'.
	Click on the closest 'dust bin' you can find(the one for the name
	field). Et voila, the name field is writeable again. Conclude that
	this is the proper way to change a name.

* Do the not so obvious and click on that 'Fast Food' button on top.
  List appears with preset of which none are 'Fast Food'. There is
	no way to know from just looking at the interface that you have
	to type 'Burger King' into the search box to achieve your goal.
	Even if succeed in finding out, operator and wikipedia
	remain with 'McDonalds'. Good luck noticing that.

All of these are relatively likely to happen to somebody unfamiliar
with iD and all end you in an inconsistent state despite the locked
name. The problem here is that there is nothing obvious about the
'protected' fields. As such they are no hint to the user
on how to map but they are  just a barrier to circumvent. You could
of course add more 'protections' to prevent the circumventions
but that just ends in an arms race the editor writer can't win.
All you end up with is an editor that is no longer usable as
a general purpose editor.

To add to that: data consumers (including me) like
to complain a lot about the quality of OSM data but that is
actually greatly exaggerated. As developers, we tend to mostly
see the bad data points because the 99% of good data just
gets processed quietly without drawing any attention. That
tends to skew our perception. The number of errors this
'protection change' prevents is simply not relevant in the
grand scheme of things. And people who want to do real damage
will certainly not be deterred by a tiny read-only barrier.

Sarah