search

openstreetmap / iD

🆔 The easy-to-use OpenStreetMap editor in JavaScript.
https://www.openstreetmap.org/edit?editor=id
ISC License
3.37k stars 1.21k forks source link

Add feature to reduce number of unintentional huge-area or even globe-spanning edits? #8590

Open nitram9 opened 3 years ago

nitram9 commented 3 years ago

Hi devs!

It seems that a large fraction of large-area or globe-spanning edits are made by new (or at least relatively new) OSM contributors using iD. Even seasoned contributors sometimes make mistakes by accident.... So, it seems to me that this is an area where code and some logic could be used to prevent these kinds of edits and therefore help in making the history pane easier to navigate...

What could be done? Implement a check and then do an action.

So, how could the check be done? Here are some ideas...

Then, what should be done in the action? Here, I see a few options...

An additional check to bypass the above action could be if...

I know well that there are many outstanding tasks for the iD team to work on but I think this could be a very useful feature to add. Perhaps is some better logic that can be used but I hope that this is a starting point for discussion.

1ec5 commented 3 years ago

The logic could get complicated because of individual large features (such as route relations) whose bounding boxes may not even be known to iD upfront. Perhaps addressing the root causes of too-large changesets would lead to simpler heuristics. For example, iD currently reddens the Save button as an encouragement to save earlier before accumulating too many changes that could trigger conflicts (or dataloss when the browser crashes). What if it similarly reddens based on individual operations that cause a lot of panning, such as searching for a faraway feature using Nominatim while in iD?

nitram9 commented 3 years ago

@1ec5 While an interesting idea, I'm afraid that this solution wouldn't be strong enough. As for route relations, I think that those could be 'white listed'. For all other nodes and ways, the coordinates would be used for calculating the N-S (y) and E-W (x) displacements which are used to trigger the new action if the set limit is exceeded. For advanced iD users, there could be a setting somewhere to turn off the 'safety feature' that blocks the ability to submit the changeset. But the point would be that the 'safety' is on by default and that a user needs to actively disable it each time they want to submit something very large.

1ec5 commented 3 years ago

But the point would be that the 'safety' is on by default and that a user needs to actively disable it each time they want to submit something very large.

If this proposal is motivated by unintentional globetrotting by new users, then the problem is mainly one of user education. It’s counterproductive to simply disable or hide some capability without giving some hint as to why at an opportune time. If we wait until after the user has already edited features right across the world before blocking them from saving, that’s every bit as frustrating as running into an edit conflict that iD is unable to resolve and having to throw away hard work. An option to temporarily disable the feature would unblock the user but would subject them to criticism from the community, and it would no longer be an innocent mistake.

A user-friendly approach would discourage the user from getting trapped in this catch-22. For example, if you make some edits and then search for something, there could be a warning below the “Search worldwide” button about saving before proceeding. Better yet, if you do end up making changes in a broad area, iD could offer to automatically break up the changeset into geographic clusters, as previously suggested in https://github.com/openstreetmap/iD/issues/7434#issuecomment-599073583 and #8489. The hard part is knowing where to draw the line, so to speak.

I think a security/safety mindset would be more appropriate if we’re dealing with people who stubbornly insist on globetrotting. But the most prominent examples of that behavior are from mappers using editors other than iD.

Mashin6 commented 3 years ago

I am afraid user education is not going to be very successful. Those large edits are done by new users and they don't have time to read long manuals.

What I would imagine is that when a user would pan to a new area that is too far (some arbitrary distance) from current edits, iD would block editing objects and display message "Please upload your changes before you continue editing in this area." + red upload button.

Once user uploads or moves back to previous edits location, editing is enabled again. And as suggested this could be disabled in the menu for users that know what they are doing.

mmd-osm commented 3 years ago

I like the idea of turning the upload button "red" once you're moving too far away from your current edit location. Maybe start with this kind of subtle hint, and see if this helps already.

kjonosm commented 3 years ago

A hint together with the "Zoom in to edit" message might also help... Bildschirmfoto 2021-09-12 um 11 00 51

Lee-Carre commented 3 years ago

As evidence of the need for such a remedy, a (very clear) real-world example: changeset #111425950:

I didn't know that it was important to seperate them though.

The context of the quote refers to distant changes made in the same changeset.

This is (at the time) a mapper with <100 changesets (<1000 total map changes), most of which were via phone apps and only 8 via iD. So, very much an iD newbie (& OSM novice), and the target user-group.

His remarks make clear that there's a significant usability / interaction-design flaw in iD.

Besides changes to function / behaviour, might I suggest updating the tutorial to give a primer on good practice(s). To include (at the least; further suggestions welcome):

This probably warrants its own issue being opened, separately.

This is especially important since iD is the default editor, and typically the first one which newbies encounter. It should, thus, set the example.

nitram9 commented 3 years ago

The suggestions of @Lee-Carre are excellent. I think that updating the tutorial is a great idea. Of course, the initial tutorial shouldn't have too many learning steps but perhaps there can be a second tutorial after the first which rolls in educating the new user about best practices.

However, to get around globe-spanning edits, the only way that I see effective is to disable editing if one goes away from a particular area with existing edits. A popup saying 'Please submit changes before moving to a new area' would be most helpful. There could be a link saying why this is so important. An advanced user can then go scroll to the bottom of that terms-and-services-like page to click 'I understand, allow anyway'.

Lee-Carre commented 3 years ago

The suggestions of @Lee-Carre are excellent.

Thankyou @nitramwin . In that case, I'm inspired to share some others, having studied usability somewhat, and the apparent nature of the (root-)problem is increasingly one of human—computer interfacing.

I'll preface this by admitting to having never used iD (I do surveying on a nano-computer, not armchair-mapping on a micro-computer), so I'm extrapolating from what I've read others describe of iD's UI. I'll talk somewhat in the abstract & more about general principles (of good design), rather than the detailed specifics of iD.

A recurring theme, I notice, is talk of making the “save” UI button coloured (usually) red under certain conditions.

Now, I could be entirely wrong, here (and if so then please correct me), but this seems to be very much from a technical system design perspective (to which I entirely relate, and am not criticising), rather than necessarily from a perspective of designing an effective UI and user-experience. The latter being very much about communication (in the broad sense; think non-verbal communication among humans) with the user, while the former is about what's going to function well (efficiently, robustly, reliably, etc.). Both are important, but quite different mindsets.

What do I mean? Well, how would a user know what is meant by the save button turning red? Especially that it seems to be the go-to for indicating any kind of trouble-condition related to edited data within iD.

Depending on the placement of the widget, especially if it's small and in a corner, the user may not even notice the colour-change. This is self-defeating if it's only noticed once the user wants to submit the changeset, and we've already passed the point of no return with regards to whatever trouble condition (distant and/or unrelated edits, or whatever else). I imagine some might well shrug and hit the button regardless, at that point.

My question would be; what (proper; there's good and bad ways of doing it) usability-testing has been conducted, to confirm what seem to be mere assumptions about the UI design of iD?

Empirical data always trumps opinion & guesswork.

To avoid this becoming an essay or lecture on usability, I'll refrain from describing proper testing methodology, here. Though, if others wish for elaboration then I'm willing to do so. The curious (& keen) would do well to start with Usability Testing 101 and other articles on the same site. Usability testing is very different to ‘focus groups’.

If the intent / meaning of some aspect of the UI isn't clear, then users will simply ignore it.

updating the tutorial is a great idea. Of course, the initial tutorial shouldn't have too many learning steps but perhaps there can be a second tutorial after the first which rolls in educating the new user about best practices.

This hints at a broader view and/or deeper problem.

My suggestion of updating the tutorial was as a quick & easy win. Low-hanging fruit, as it were.

However, as @nitramwin rightly points out, this risks the tutorial becoming bloated, and less of a quick-start intro but more like reading documentation.

This would, indeed, be bad. More and more users would end up skipping / dismissing the tutorial. Attempting to prevent them from doing so would cause some to simply give up and abandon either iD or OSM entirely.

Why? Well, because the user is in iD to (presumably) do some editing. In that context, a lengthy tutorial is, quite simply & bluntly, ‘getting in their way’ or distracting them from their task. Put another way; it's not helping them.

Any complaints about this is to ignore human-factors in the design of software / systems. The solution is in how to align with the user.

So, getting to my point; the solution would be a fundamentally different design than an up-front tutorial.

Instead of expecting them to read what is essentially (brief) documentation, as something separate to editing proper, make the design more about helpful tips along the way as they edit. Think of any decent game integrating the tutorial into a training level (level zero?), which is highly interactive rather than pages of text pre-gameplay.

Much of it could be conditional upon what each user is trying to do at the time. As opposed to trying to cover everything up front. Users don't need to learn about editing relations until they try to edit an actual relation, for example. Thus, only relevant advice / tips are displayed, as needed.

The whole model of this is very different in terms of user-experience. Done well, it's much more likely to be received as helpful, rather than distracting; because it's enabling them to further their chosen goal / task, rather than being a hurdle to overcome like when a tutorial is all up-front documentation (most of which the user won't relate to, if they're literally brand new to OSM; ‘what's a relation?!’ it only becomes meaningful once they've had chance to start forming a mental-model of how the software works and of OSM's data model / schema (i.e. the concepts underpinning the constructs of node, way, tags, relations)).

Taking it out of the abstract, slightly, and applying it to this issue; if a user only ever makes small changesets, then why pester them about the badness of large ones? If the user is always adding good changeset comments (however that might be determined by an algorithm) then why nag them about making good changeset comments? You see the pattern.

Think of a master-craftsman and an apprentice. If the apprentice is doing as the master thinks he should, then why intervene or comment? Let the padawan continue as-is (unless there really is something non-obvious to point out, or (for the less confident) giving confirmation of correctness).

This way, feedback from the UI occurs only when actually needed, rather than pre-emptively.

Users will tend to perceive this as being a constructive part of the work-flow, in achieving their goal. Helping them with their task, especially to avoid known mistakes.

There's a lot more which could be said on this concept & topic, but hopefully that's enough to give readers food for thought.

to get around globe-spanning edits, the only way that I see effective is to disable editing if one goes away from a particular area with existing edits. A popup saying 'Please submit changes before moving to a new area' would be most helpful. There could be a link saying why this is so important. An advanced user can then go scroll to the bottom of that terms-and-services-like page to click 'I understand, allow anyway'.

While I'm not disagreeing, a consideration from a usability perspective is that technical restrictions tend to be received as hostile, by users (back to; you're getting in the way of their task). So, should be avoided & minimised unless important / necessary (and this might be a qualifying case, since user-habit is what we'd like to change, and a mere info-box may be too easily ignored).

If possible, a better way would be to work with the user, rather than (as they would perceive it) against them. That's not always possible (scenarios involving safety systems come to mind), but should be seriously explored & tried before resorting to anything heavy-handed.

I never said that designing for users was easy 🙂. Like with technical considerations, it often comes down to juggling trade-offs (rather than there being any singular obvious solution).

Mashin6 commented 3 years ago

For the message warning about large bbox changeset this new banner UI could be used #8727

Lee-Carre commented 2 years ago

Another example: changeset #118432831.

Notably, because:

Yet, the bbox spans between Moscow & South America.

So, even with a user who appears to have been careful with his first changeset, the problem of enormous bboxes still trips them up. This suggests that they're not made aware that it's happened, until after its been submitted (and is too late).

While I'm here, some (more) usability resources for developers:

Dimitar5555 commented 1 year ago

It should be possible for iD to warn the user when uploading and to suggest to automatically split it in two (or more if needed) changesets. Generally speaking if the bbox of a changeset has a side, that's longer than 100km, it should be split (of course, this is not possible if only a single object is changed).