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 _______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
