[OSM-talk] [josm-dev] JOSM and 0.5 (was: Does potlatch make it too easy for people to unintentionally screw things up?)

[Dermot McNally]

On 12/10/2007, Frederik Ramm <frederik at remote.org> wrote:

> Others have said the same, albeit with another angle - they said that
> it is easy to move something which you only wanted to click-select.

I predicted that this could be the case before I had actually tried
the modeless version. Now that I have tried it, I can express my
opinion far more strongly. Specifically, I now find it next to
impossible to just select a node (to edit tags or whatever) without it
moving a little across the canvas. Even on those occasions where the
node doesn't seem to have moved, I honestly can't say whether it has
(and at lower levels of zoom a 1 pixel shift could be bad news).

Whatever it is that's going to solve this problem, we'd better work it
out before this current version becomes more widely used. The
anti-Potlatch brigade will have a field-day once the vandalism
potential becomes clear. To review my understanding of our options
here (many of which could be adopted at the same time):

1. Only infer a drag if the mouse button is held down longer than a
threshold time.

2. Only infer a drag if the pointer has been moved by more than a set
amount from the point of origin (let's call this higher "object
inertia"). Could be used alongside option 1.

3. Apply a strong highlight or other visual clue to an object changed
in any way. For mistakenly moved objects, that would cause a sudden
change to highlighted state, giving the user the option to undo. This
could be used independently of any other strategy that may also be
used. Snag: you select a node and change its tags. Highlight comes on.
You realise you forgot something and select it again. You move it my
accident. Highlight state won't now change. This strategy is therefore
useful, but won't save us in all cases.

4. Require a modifier key before moves can take place. (Yuck!)

5. Reinstate move mode. (even more yuck!)

However, there's one absolute principle that I feel we must stick by:

* Whatever protection we build in against actual moving must not be a
user-optional property. We can't have mappers deciding for themselves
that they will recognise an accidental move and protect against it
themselves - nobody's hand is that steady.


My remaining comments on the latest modeless version I've used relates
to the behaviour of delete:

1. Delete is still a mode, even though for most normal use it doesn't
need to be. I would suggest a context-sensitive delete tool that works
as follows:

Click delete with nothing selected: Delete mode activates as before.
Visual feedback on toolbar (and mouse cursor) provides user with
enough clues as to mode. Exit mode by reactivating draw mode.

Click delete with something selected: Delete the selection without
changing mode.

2. Deleting ways still leaves otherwise untagged and unconnected nodes
behind. My suggestion to change this (at least under the default
option set) is fairly new, but you can see how troublesome this
behaviour is because of...

3. Pressing delete when nodes within ways are selected will delete
those nodes and modify the way accordingly. Now, although I myself
suggested a version of this behaviour, this behaviour is actually
quite dangerous because:

* it violates Policy Of Least Astonishment: a common way of cleaning
up remnant nodes (as in [2] above) is to drag a marquee around them
and exploit the fact that any way dependency nodes will be
delete-protected.

* Sometimes you'll want to delete a node which is close enough to a
way that it's not clear whether it belongs to that way. Examples would
be place nodes, petrol stations and the like. As a mapper, when trying
to delete unwanted nodes of this kind, I only want to do so if the
nodes are not additionally required for a way, and I value the
delete-protection as a clue that tells me that I should actually be
deleting only selected attributes.

Possible solutions:

* Require modifier key before deleting "structurally-important" nodes
(specifically, nodes belonging to ways where the ways themselves are
not also being deleted). This is my favoured option.

* Only allow deletion of a single "structural" node at a time -
multiple such nodes would be delete-protected (or would require a
modifier key)

* Warning dialogue if structural nodes involved - analogous to how
file managers will often allow you to delete a read-only file, but
only with user confirmation (yuck).

* Only allow deletion of structural nodes within delete mode, not as a
delete action (this will in effect enforce one-at-a-time deletion).

Opinions?
Dermot