Closed joostschouppe closed 5 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.
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)
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.
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..
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.
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.
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 ⚠️
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!" 🤔
BTW, thanks @timcouwelier for stopping by - I do appreciate it!
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.
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.
This comment applies here too https://github.com/openstreetmap/iD/issues/4787#issuecomment-364979903
@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 .
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:
On point nodes, I would assume (at first glance) a 'movement distance' check could work. Surely we do align stuff and such, but it's probably fairly unusual for point nodes to be moved over 50 (?) meters.
On the start- and end-nodes of a line feature: If they are connected to other line features at the node, they can be considered equivalent to a 'single node' as far the checking method goes. For the start/end nodes that aren't connected, for the most part they'd fit in the 'node' criteria aswell, unless the lines are hugely stretched to reflect the road/path goes on further. But then again, in such cases it could just as well be done by just drawing a new line feature to reflect the extension..
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
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.
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.