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

[Dermot McNally]

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

> > 1. Only infer a drag if the mouse button is held down longer than a
> > threshold time.
>
> A *configurable* threshold... ;-)?

Ideally not - see my later comment about not giving users enough rope
to hang themselves.

> > 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.
>
> Makes it really difficult though to move something a small amount if
> you want - I know that from other software: select something, drag it
> away quite far so taht move mode triggers, then slowly return it to
> almost where it was...

Yes, that's how you'd have to do it - and as you say, there's
precedent for this in other drawing apps. What they often have (and
would also word well for us, IMHO) is nudge controls, where either
using toolbar options or shortcut keys (cursor keys?) you can perform
exactly this kind of fine adjustment. I think that a combination of
drag-with-inertia with nudge options would work really well.

> > 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:
>
> Agree that this should change. Not 100% sure if your suggestion is
> intuitive though. Maybe just have "delete mode" and a, different,
> "delete command"?

I wouldn't object in principle, but it could be hard to make that
intuitive too. As long as the toolbar button enters delete mode,
that's what most newbies will use to delete things. So, assuming we
believe that the action and not the mode is the best way to do most
work, we need to ensure:

* that the delete action is "prompted" by toolbar option or other hint
and not just hidden behind the (albeit guessable) delete key.

* that any dual-delete regime that leads to two different delete
options on the toolbar had better have some good ideas how to
differentiate the two in the minds of users.

How about implementing a new toolbar or toolbar section dealing with
context-sensitive actions? A delete-action button would only activate
here if something were selected. Based on current idiom, though, such
an action palette would belong on the right-side, which to me is a
non-obvious place for newbies. Tricky...

> > 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:

> > * 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)
>
> I think I slightly favour the second.

Me too.

> > * Only allow deletion of structural nodes within delete mode, not as
> > a delete action (this will in effect enforce one-at-a-time deletion).
>
> Also good (could offer various delete actions from a menu - normal
> delete, force delete even if structural, force delete with everything
> that depends on it - the current ctrl modifier).

I quite like this approach too, but its usefulness will depend a
little on how intuitive we manage to make the distinction between the
delete mode and action.

Dermot