[OSM-talk] JOSM user interface

[Dermot McNally]

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

> I think some of your complaints and those mentioned in the follow-up
> posts could be fixed by completely changing the "modes", as proposed
> by myself here:
>
> http://josm.openstreetmap.de/ticket/11

I'm a big fan of most of your ideas in there, and the result will
allow more editing with less mode-switching. The ability to stay in
"select" mode for more kinds of manipulation is extremely useful.
There are many situations (though some now disappeared along with the
way tool) where I find myself switching from the active mode to select
mode, just so I can click on a blank bit of canvas to de-select all
just so I can reactivate the tool I started with. Yes, I daresay
there's a shortcut for that, but good UI design should still allow me
to feel my way more readily than this.

One scary aspect of the mode reform you propose is what I'm going to
refer to as the "Potlatch Effect" (with apologies to Richard). I
define this as the risk introduced through making it easy to do
something dangerous - in this instance, if we go with the proposals,
it will become much easier to move things around the map without
meaning to. For instance:

* Select a bunch of stuff by dragging a marquee
* While all of the elements are still selected, drag a node in the
hope of repositioning just that node
* Panic, because this is your first JOSM session and you haven't
discovered "undo" yet.

Obviously, JOSM benefits from the fact that you need to explicitly
upload. But there's still scope for more subtle mischief:

* Go to click on a place node to examine its properties or maybe to edit a tag
* Your sloppy click turns into a small drag, displacing the node by an
amount so small that you don't realise you've moved it.

Solving this kind of problem is going to require some very careful
feedback from JOSM. Possible ideas:

* Altered items appear with an obvious highlight, halo or other
noticeable change in appearance until uploaded. This way, you can see
a change the instance you've modified something and can undo.

* Movement over small distances (on screen, so scale dependent) does
not begin to happen until the pointer is dragged far enough from the
point of origin for your action to be obvious.

* Some kind of animation, blink or other visual effect once a dragged
item is "dropped" at its new location.

Other thoughts:

* Something I quite often do is to delete fairly long ways. Usually
this requires me to laboriously drag it to a clean bit of canvas
(which can be some way off), zoom out and marquee-delete it. Now that
we have no more segments, the action of the simple delete tool is a
bit nicer than it was, but it still leaves stray nodes, many of which
will be unwanted, lying around. Either by user preference or
shift-modifier, I'd like to see untagged and otherwise unused nodes
removed when the way is deleted.

* I never liked shift-to-extend-selection but
ctrl-to-remove-from-selection. There is precedent for shift-click to
toggle the selection state of an object. I would have guessed that
shift-click would deselect only the item I click on, but I had to RTFM
before I found out how to actually do it.

* There is a case to be made in such a revised UI for some helpful
"action buttons" in the toolbar. These would include the new delete
action already discussed, but could also have a "knife" tool to split
ways at a node (or possibly to kill a mid-way segment thereby
splitting the way and leaving a gap). Maybe also a "glue" tool to
merge ways at a common node.

Dermot