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

On-map warnings #4776

Closed joostschouppe closed 5 years ago

joostschouppe commented 6 years ago

It's quite common to see someone accidentally moving a node from a way quite a distance away. Here's an example from a great mapper. It usually happens in iD, and not so often in Potlatch or JOSM. I think the reason people easily miss this, is because it happens as you are moving to lower zoom levels. ID hides loaded objects as you zoom out, I suppose to avoid crashing the browser (good idea). But that also hides an error that would otherwise be quite obvious.

A possible solution: keep hiding loaded objects EXCEPT when the user has unsaved edits on the object / has edideted the object in this session.

bhousel commented 6 years ago

Can you repeat the steps and record a screen capture with licecap? I don't understand what you mean about the hiding loaded objects.

joostschouppe commented 6 years ago

Sure, here's a recording. So i don't know exactly how people do the thing I demonstrate without noticing. My suggested solution is that the road I messed up would remain a visible vector object at the end, when one only sees PNG background layers. Posted to Imgur (it turned out 25 mb)

bhousel commented 6 years ago

I took a look.. I don't see why a user would miss that they dragged that node (it seems pretty obvious), but somehow notice only after zooming out? I think I'd rather hear a report from the user who made the edit than just guess at what they were thinking and start changing things without really understanding the root cause.

We've tried to tackle this problem before, and there's not a great way to solve it and still allow the user to make legitimate edits. Besides, it's really easy for a user paying attention to just undo the thing they dragged.

timcouwelier commented 6 years ago

As requested by joostschouppe, here's my input on what I believe happened:

If I have to guess, it's due to me not being careful enough when 'panning' the map. rather then 'scroll zoom', I tend to 'drag' the map sideways to move location, much like I do in CAD environments. Often that requires multiple times sliding the map to get where I want. On one of those, rather then putting cursor on a 'blank' spot (or the center or a polygon), I may actually have selected a node, and shifted that around. Given I slid it around a few times, the obvious goofy mistake may no longer have displayed on my screen at all, thus gone unnoticed. Either way it's an oversight on my part, so I'm to blame rather then the application. If I were to 'slide just once', I'd have caught it, with a 90% certainty. But given I probably moved 3-4 times, it was a case of 'out of sight, out of mind'.

Possible fixes/prevention, if you ask me would either involve:

To point out the obvious: the first option seems to require the least community effort, but humans are bound to end up making the occasional mistake.

EDIT: Also, any possible solution should avoid causing too much lag/delay for the mapper, so on large polygons suggestions like the 'outliers check' might not pass that mark..

ghost commented 6 years ago

Just FYI: JOSM solves this by using the left mouse button for moving objects and the right mouse button for panning, which is actually really easy if you're used to it. I can only accidentally move if I press the wrong button, which happens sometimes due to my crappy laptop touchpad.

1ec5 commented 6 years ago

which is actually really easy if you're used to it

That’s a big if. 😉 At mapathons, I’ve seen new JOSM users accidentally move an entire city’s worth of nodes by panning with the wrong mouse button (or using a touchpad). It’s reasonable that JOSM uses a dedicated gesture for panning the map, given its focus on editing efficiency. By contrast, iD’s gesture handling hews more closely to standard browser/OS behavior in order to be intuitive to casual users.

Potlatch is closer in spirit to iD than JOSM is, and I think it has a sound approach for preventing accidental node moves. Potlatch requires you to click and hold for a split second before dragging a standalone POI. To move a way’s endpoint or an intersection node, you have to first click on the way to select it before you can drag the node. I don’t remember having difficulty with either of these behaviors when I started editing OSM, but of course different users have different expectations.

Before 'committing' a changeset, show a graphical representation of ONLY the altered objects for approval

I really like this idea, independently of whether it helps to avoid accidental node moves. I think an OSMCha-style graphical overview in the save screen would make it much easier to write a good changeset comment. Not sure how feasible it would be, though.

bhousel commented 6 years ago

A check on 'obvious outliers' after each line/polygon edit.

I like this idea..

I've been thinking about this a bit today. We're never going to solve the problem of users doing things without paying much attention, but we should probably find ways to expose warnings as they are editing.

A good example of this is what Excel does. If a user is not paying attention and they drag some numbers in Excel far away from where they belong, it might show something like this ⚠️

excel warning

So maybe we could detect conditions like this during editing and put ⚠️on their map with some hovertext and a dismiss option.

I wonder if Excel were an open source spreadsheet whether their issue tracker would also attract a lot of issues like "Nobody ever drags cell contents to the wrong place in Lotus1-2-3! You need to prevent users from dragging cell contents!" 🤔

bhousel commented 6 years ago

BTW, thanks @timcouwelier for stopping by - I do appreciate it!

joostschouppe commented 6 years ago

And all I had to do was ask @timcouwelier nicely :)

I wonder if Excel were an open source spreadsheet whether their issue tracker would also attract a lot of issues like "Nobody ever drags cell contents to the wrong place in Lotus1-2-3! You need to prevent users from dragging cell contents!"

That's slightly of topic, so allow me to get further off topic. I understand what you're saying, but a comment like this could easily be interpreted as "leave me alone with your suggestions for improvement". For everyone who comes here to say "hmm, maybe this could be improved", there's someone saying "iD's a lost cause anyway". I feel your comment decreases the chance of the former and increases the chance of the latter. But let's not discuss that any further here.

manfredbrandl commented 6 years ago

I tend to 'drag' the map sideways to move location, much like I do in CAD environments. Often that requires multiple times sliding the map to get where I want. On one of those, rather then putting cursor on a 'blank' spot (or the center or a polygon), I may actually have selected a node, and shifted that around. Given I slid it around a few times, the obvious goofy mistake may no longer have displayed on my screen at all, thus gone unnoticed.

One of my changesets was reverted because of such a mistake. Maybe iD should NOT move nodes when they are selected and moved very fast and more then half a screenfull. The node could simply snap back. Legitimate moving of nodes for half a screenfull or more are not done very fast. At least not with a very fast klick and move immediately afterwards.

bhousel commented 6 years ago

This comment applies here too https://github.com/openstreetmap/iD/issues/4787#issuecomment-364979903

slhh commented 6 years ago

@bhousel If we do it right, on-map warnings seem to have a great improvement potential for iD. Can we have a separate issue for the related discussion and revert the title of this one?

On-map warnings doesn't seem to be the full solution to the original issue. Due to the current drag behaviour, they might be generated out of view. Even if iD forces the user to inspect all warnings before saving, The user might not know where a dragged point comes from (a vertex is easier). We would need a selective undo here.

If we want to generate a warning for long distance drags, a modal one seems to be better. Especially, because subsequent edits wouldn't be able to eliminate the warning condition, and let the on-map warning disappear automatically. Having to inspect and dismiss a on-map warning would be more overhead than confirming a modal one. And we should not teach user to ignore warnings without knowing the reason.

I have put some more ideas to address the original issue in https://github.com/openstreetmap/iD/issues/4817#issuecomment-366525733 .

timcouwelier commented 6 years ago

I've had it happen again last saturday. This time, fortunately, it caught my eye and I was able to quickly undo it.

Based on recent experiences and working with iD, I would like to reference this part from my earlier post:

A check on 'obvious outliers' after each line/polygon edit. Not sure how you'd define that (for each node N, check if the distances between nodes (N, N+1) and (N,N-1) do not exceed the distance between nodes (N-1,N+1) by a certain ratio ?)

That would work wonders for any point on a line/polygon, except for the obvious single points and the start- and endpoints of line features. I've done a bit of aligning and editing, and find myself shifting around nodes to reflect where a certain bend / corner / is located based on survey rather then a guesstimate from aerial imagery. While that's sometimes a 'long drag', it doesn't interfere with a rule like the above

It also got me thinking about the other cases:

bhousel commented 6 years ago

Hey all, I'm actually getting really angry at this issue. I know you are all trying to help, but none of this is helpful to me. I'm locking the discussion and will build a warning system someday when time allows.

Until then, please just pay attention to what you are doing when you drag nodes around, and use Undo if you make a mistake. Thanks.

Also, please don't

quincylvania commented 5 years ago

I opened #5905 to deal with showing on-map warnings for the new validation system. Closing this since the discussion is somewhat dated and unfocused toward the title issue, to say the least.