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

[Lauri Hahne]

The current interface is a pretty good starting point but what should
be (re)introduced becides the current tools are the following

1. Separate select and move or not allow first click to move such that
you first need to select before you can move and indicate this by
mouse cursor or something.
2. Reintroduce add node and add node into way which are now terribly
well hidden. (to create a node you need to use edd node and connect
tool and use move tool to exit from creating new nodes mode). And
don't even know how it is possible currently to add node into way.
Apparently it is possible using some key combo but having an icon for
this shouldn't be to big problem is it used to have a button on
toolbar.
3. It isn't very ideal that you have to use move tool to deselect.
What on earth has selecting and moving to do with eachother.
4. JOSM shouldn't be dumbed down too much as there is always Potlach
which is mostly made beginners in mind.


On 14/10/2007, Chris Morley <c.morley at dsl.pipex.com> wrote:
> 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
>
>
> _______________________________________________
> josm-dev mailing list
> josm-dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
>


-- 
Lauri Hahne