[josm-dev] Do we need some principles for JOSM interface design?

[Chris Morley]

It might be helpful to write down what the principles should be behind a 
new interface for JOSM, so that they can be discussed. I think the 
recent changes by Frederik are in the right direction, but maybe the 
design process is a bit too ad hoc at the moment. My list is below; some 
of points are already applied and some are contentious. (Of course, 
caveat IANAID.)

1. The conceptual model should be nodes and ways - the same as the 
underlying data. JOSM was built on a segment model, and even after the 
0.5 API it was possible to use this as a conceptual model. I think this 
should be put aside.

2. The interface should be designed to suit the most common workflow. An 
interface of strictly logical elementary operations (select, add node, 
select...) seems obvious to programmers but may be much slower. In any 
year there hundreds of thousands of man hours spent editing with JOSM so 
even a small amount of time saved is significant. A detailed interface 
may be necessary as well, but is likely to be more clunky. With the old 
JOSM you spent too much time selecting and deselecting things.

3. The editing should be, as far as possible, clicks of a single mouse 
button and movement of the mouse pointer that does not move away from 
the part of the drawing being edited. This is a perhaps a bit too ideal, 
but it implies that it would be better if you didn't have to keep 
clicking buttons off the drawing surface and you didn't have to use 
modifier keys.

4. Mistakes should be instantly correctable. Not only does this save 
time but also reduces anxiety in the user because it reduced the chances 
of him messing up and not knowing how to put things right. Toggling is a 
simple and comfortable interface concept, and deserves to be used. For 
instance, when adding nodes on a curved road, I commonly place one too 
far from the last, cutting a corner. The fastest way to correct this is 
to have an interface where clicking the node you have just added erases 
it, giving you another chance. This would be quite a long process with 
an interface having only elementary operations. (It was in the old JOSM.)

5. There should be a visual indication of what will happen next. 
Particularly, the way about to be altered by the next mouse click should 
be highlighted, and so should the end node to which a new external node 
would be attached. A more sophisticated interface would change the 
"hover" cursor to indict what would happen when the user clicked. This 
is especially important in a "modeless" interface, as envisaged here, 
where the the click could add, delete, select or deselect (or more).

6. The interface should prevent you making useless constructs. For 
instance, a way with nodes ABCB or ABCDEB has no obvious use currently, 
and so should not be constructed. This gives the opportunity to use 
these "illegal" situations to streamline the user interface. For 
instance, if you added nodes A, B, C to make a way, and you clicked B 
again, it would mean that you were starting a new way (a side road) there.

7. The possibility of multiple ways sharing the same nodes should be 
central to the editing, not an afterthought. So if a road and an 
adjacent area shared nodes and you wanted to insert a new node in the 
road, it should be inserted in the area as well. This avoids a useless 
construct as in 6 above, but goes against 5 in some respects, 
justifiably in my view. (Not many principles don't have exceptions.)

There are obviously issues in making an interface too different from 
others that the users might be familiar with, like drawing programs. But 
JOSM is specialised application with a limited rage of required 
operations. It also (at the moment) doesn't have to maintain backward 
compatibility. Now is the time to think what we really want, not what is 
just adequate.

Chris