JOSM/UI

From OpenStreetMap

This page is an attempt to design a consistent UI for map editing in JOSM (and perhaps the info could be used for other editors too). The suggested process is two-stage:

1. Identify all current problems
2. Work out all the actions one might want to perform
3. Allocate keystrokes based on what people might expect from other applications/UI conventions, and possible frequency of use.

Contents 1 Problems With The Existing UI 2 Norman's principles of good design 3 Actions Needed 3.1 Movement 3.2 Selection 3.3 Editing 3.4 Addition 3.5 Other 4 New UI Design (by Gerv) - version 2 4.1 Movement 4.2 Selection 4.3 Editing 4.4 Addition 4.5 Other 5 Make it iPodish (by Nic) 6 PDA Mode (by Nic) 7 Toolbased

Problems With The Existing UI

These are by definition subjective but please do add your stuff here. If you know a solution, please add it after the entry instead of deleting the entry.

Please "sign" your comments by pressing the sign button on editors toolbar after adding a comment so we know who said what

1. It isn't possible to select a way without risking to move it.
   • I was thinking that a way of stopping this would be to make moves not occur until you've selected an item, so to drag something you would have to click, then click again and drag. Would obviously slow down dragging but would fix this problem that a number of people have reported.
     • do not do this please, every graphics editor I know (gimp, corel and derivatives like inkscape) dont have this problem, so there is a solution to easily select something without moving it, it can be done for example by requiring to move mouse to some distance from original click point to initiate object move, without moving for example 4 pixels away, action would be select only. --Walley 11:17, 10 December 2007 (UTC)
     • This was noticed fairly early on, especially with tablets and some optical mice; a work round was put in for this whereby the time before button up can be adjusted (edit.initial-move-delay). Set to 450 this has not caused me any problems since and moving when I want to is still fine. Perhaps this should be the default. However, this still leaves the problem about selecting and moving multiple objects, and for this reason I would still favour "select first before move". Davidearl 18:02, 9 December 2007 (UTC)
     • Or we could just have two modes, a "select" mode, and a "move" mode. Andrewpmk 23:44, 10 December 2007 (UTC)
       • I prefer this solution. I don't like the current risk of moving things when dragging to try to make a select box in a complicated area. Daveemtb 14:12, 14 January 2008 (UTC)
2. It isn't possible to insert two or more nodes into a way without explicitly deselecting in between.
   • Oh yes it is - just hold down shift as you insert the nodes TomH 17:40, 9 December 2007 (UTC)
     • Shouldn't this be the default behaviour if you insert into the same way? --LH 17:41, 9 December 2007 (UTC)
3. If you delete a way which has untagged nodes which aren't shared with any other way, JOSM doesn't delete the nodes.
   • Just hold down alt. --GabrielEbner 17:50, 9 December 2007 (UTC)
     • Why not make this default when nodes have no tags or other ways? (defaults do matter) --LH 17:53, 9 December 2007 (UTC)
     • I agree; I wasn't aware of this modifier until now. Davidearl 18:05, 9 December 2007 (UTC)
       • Neither was I. I've just added it to JOSM/Advanced Tricks Avantman42 18:17, 9 December 2007 (UTC)
4. If you combine two ways which have different directions but which aren't tagged as one way, JOSM ask you whether you want this. This isn't necessary if those ways aren't one-way.
   • But that would require JOSM to have special knowledge that a certain attribute or set of attributes made directionality important. Is that really desirable? Gerv 21:43, 9 December 2007 (UTC)
5. It appears to be impossible to tell the direction of a way without enabling direction arrows in the preferences, which in turn seems to make JOSM terribly slow.
   • Somebody offered a patch to show arrows when selected. Would that help? --GabrielEbner 17:50, 9 December 2007 (UTC)
     • I think that would be useful, since it doesn't clutter up the map so much then. And maybe mappaint can be extended so that it always shows arrows for oneway streets? (How to display oneway=-1 is a harder question though.) --Colin Marquardt 18:05, 12 December 2007 (UTC)
       • It seems that this is in the newest JOSMs. --Colin Marquardt 20:35, 12 December 2007 (UTC)
   • I have arrows turned on and it doesn't seem unreasonably slow to me. Davidearl 18:03, 9 December 2007 (UTC)
6. Ways are connecting too fast, when trying to make a dual carriage way it gets me a bit too sticky
   • See my comment to number 9 (there is a modifier key for that). --Colin Marquardt 17:51, 12 December 2007 (UTC)
7. The user interface depends too much on modifier keys. "Smart" tools should replace these (where it makes sense). --LH 18:08, 9 December 2007 (UTC)
8. When you open multiple GPX files, each one of these is added to their own layer. Is this really necessary or would it be a better idea to have by default one layer for your GPX files, one for points from server and for the actual data.
9. I have not worked out how to add areas surrounded by ways (eg a park surrounded by roads) without endless retries. I have seen people write that you should reuse the existing ways as borders. I don't get this conceptually, and in practice the few times I have tried inevitably seem to find later that I need to change one of the 'outer' ways separately from the area it surrounds, and don't have any idea how to do this. So I draw the inner area as a new way. This always leads to getting a little too close to the existing ways, and getting a join to the existing ways which I don't want, so having to stop, undo, reselect and start again. If I zoom close enough in to avoid this I lose my overall view of the area and keep having to zoom out and in, which generally also leads to mistakes. So now I draw a small version of the area I want, then when complete drag the nodes to where I want them to be (this generally leads to accidentally picking up the whole area at some point and moving it to the wrong place). Where my little version turns out not to have enough nodes to follow all the bends in the outer ways, I zoom in to the section and add in new nodes. It all seems ridiculously complicated and time consuming but I don't know the way to av oid it. I think one of the main issues is that the auto-join to existing ways is a little too coarse and should be set to allow you to get within a few pixels of a way without joining to it. Marinheiro 09:56, 10 December 2007 (UTC)
   • There is a modifier key that prevents snapping to an existing way. Check the status bar to see which it is. --Colin Marquardt 17:33, 12 December 2007 (UTC)
10. When trying to split ways, sometimes it works ok and sometimes it tells me that what appears to be a single straight way cannot be split; there is nothing visible to show why. Marinheiro 10:00, 10 December 2007 (UTC)
    • What do you mean by "nothing visible"? Do you get no error message at all (shouldn't happen), or is it too vague? --GabrielEbner 20:14, 10 December 2007 (UTC)
    • It may be related to what I think is (or was) just a bug, in that it tells you that it cannot split at a node since it is used by more than one way, when it really is just one way. It says to select the way too, which then works, but should be unnecessary. This may be fixed in the meantime, but I have seen this in JOSMs from the lower 400 versions. --Colin Marquardt 17:38, 12 December 2007 (UTC)
      • Fixed in r485. --GabrielEbner 14:11, 13 December 2007 (UTC)
11. JOSM doesn't allow to manipulate GPS tracks. This would help to clean up tracks before upload. Toralf 21:13, 10 December 2007 (UTC)
    • This would be very much appreciated! It could help reducing the number of "noisy" nodes/tracks from tunnels or other locations with bad GPS reception. Moving of trackpoints is not too important - but removal of noisy points and splitting tracks would be really helpful --Fh2007osm 14:43, 26 February 2008 (UTC)
12. It would be easier if we could directly edit keys and values in the tags table, instead of a dialog popping up. --Colin Marquardt 17:56, 12 December 2007 (UTC)
13. When editing an existing tag, there is no completion (I should probably just report that as a bug). --Colin Marquardt 17:56, 12 December 2007 (UTC)
14. As Frederik said somewhere, there is currently no immediate indication of multiple ways sharing the same nodes. Maybe we need transparency for ways (assuming everyone uses the excellent mappaint plugin), but even then it will be hard to see. --Colin Marquardt 18:15, 12 December 2007 (UTC)
15. Currently, it is very hard and non-intuitive to select one of multiple ways when they share the same nodes. Some graphics tools allow you to click multiple times to cycle through the list of things below the cursor. JOSM should do the same. --Colin Marquardt 18:15, 12 December 2007 (UTC)
    • I recently had a more difficult problem, that resembles this one and would probably also be solved with the cycle-approach: I had two ways, each of them sharing the nodes with one other way and I wanted to select both to connect them. When using a ctrl-middle-click to get a menu for selection for the second way, unfortunately the ctrl-key prohibited to add this second way.--Kumakyoo 12:51, 3 April 2008 (BST)
16. Currently there is no quick way to synchronise tags for all items currently in the selection. It requires opening the dialogue box for each tag pair and selecting from the pull down. Being able to pull-down directly on the tag value would be much better. Perhaps even the equivalent of the R shortcut in Potlatch could be handy, to syncrhonise all. If there are more than one option, perhaps a dialogue should let you select which to keep for all tags at once.
17. When you select with an Alt-left-drag, nodes are selected as well as ways. To me it seems necessary to be able to do just one or the other.
18. A more general problem with the GUI: josm has problems with small displays (800x600 or smaller)
    • the icons on the buttons on the top/left are too big (16x16 instead of 24x24 works fine on 800x600)
    • the lists on the right side cover more than 50% of the map window, when they are detached, they are on top of the other windows (at least on Linux/Gnome)
    • the Preset menu is only partialy visible and not scrollable
    • Frank 21:29, 14 January 2008 (UTC)
19. Zooming with a rectangle seems unintuitive to me. I think, the shown rectangle should not be similar to the whole drawing area, but should end at exactly the position, where the mouse is. When releasing the mousebutton, it should be zoomed in as wide as possible to have this area shown completely (and maybe some more at the top and the bottom or left and right).--Kumakyoo 12:51, 3 April 2008 (BST)
20. If I try to open images instead of using import images JOSM display a dialog box for each file (unknown file extension). Now I know the correct way for adding images, but pressing ALT-O hundred times after this mistake was annoying.--Plaicy
21. I really had problems entering house numbers, because the completion tried to be too smart: I wanted, for example, to enter the number 24, but after typing the '2' it was selected, so the typed '4' resulted in a '4' instead of a '24'.--Regnis 15:26, 28 July 2008 (UTC)

Problems addressed by Gerv's design: 1, 2, 3, 6, 7, 9, 15

Problems already solved in recent JOSMs: 5, 10

Problems out of scope for Gerv's design: 6, 8, 11, 12, 13, 14

Norman's principles of good design

Here a a few design thesis. If you can think of something that violates these, plese add it.

1. Make actions visible and offer natural visible messages.
2. Make the connection between controls and actions visible by offering natural connections.
3. Offer a working mental model.
4. Give natural feedback.
5. Be prepared for mistakes made by user.

Also take a look at Nielsen's heuristics

Actions Needed

Here is a list of possible actions. (Note: it may be decided that some are not needed.) If you feel that there's a missing action, add it to the list in the correct category.

Movement

• Scroll vertically
• Scroll horizontally
• Zoom in
• Zoom out

Selection

• Select node (or GPX track point)
• Select way
• Select individual segments
• Select all items in area
• Add individual node or way to selection
• Add all items in area to selection
• Subtract node or way from selection
• Subtract all items in area from selection
• Limit selection to nodes or ways

Editing

• Move node
• Move way
• Move selected segments (maybe just a part of a way)
• Rotate selection
• Delete gpx track points
• Delete node
• Delete way
• Delete way and constituent nodes
• Delete segment
• Merge nodes
• Merge paired nodes (select an even number of nodes, nodes will be merged by pairs according to distance)
• Unmerge nodes (select 2 ways and optionally nodes, will duplicatte the selected (or all) shared nodes so each way has it's own set)
• Combine ways
• Split ways
• Split ways with duplicating nodes at identical positions (yielding not connected ways)

Addition

• Add node
• Add way
• Add node into way
• Extend way

Other

• Undo
• Edit tags on node
• Edit tags on way
• Edit tags on selection
• Add empty layer
• Move selection between layers
• Toggle to en-/disable movement of ways (disable accidentally moving of selected way(s))
• Filter displayed nodes/ways by tags (note: Needs a visual indication on nodes that are also used by invisible ways!)
• List ways that use the selected node(s), including way to add/relace them to selection

New UI Design (by Gerv) - version 2

One important question is whether there need to be key alternatives for every mouse action. This can be important for accessibility. For the moment, I am assuming that there does not need to be.

Modeless UIs have a big usability (as opposed to learnability) advantage - they are always consistent. This plan attempts to design an entirely modeless interface.

Those parts of the plan which happen to coincide with how JOSM works now (perfectly or almost exactly) are marked in green.

Movement

• Zooming: The scroll wheel is used to zoom. There is also key combination for those who don't have a wheel - +/- (where for convenience, on UK/US keyboards, you would make "=" do the same as "+", given that "+" is "Shift-=").
• Scrolling: You scroll around a canvas by "dragging it" with the right mouse button (RMB), or Ctrl-button on Macs or other machines with only one button. (We can't use the LMB as in the slippy map, because we have to support selection (see below) which the slippy map doesn't.)

Selection

Selecting objects is a common UI requirement for e.g. drawing programs or text, and conventions have emerged.

• Selection is done using the left mouse button.
• A single click deselects everything else and selects the clicked item
• Select happens on mousedown so you can select something and move it in one operation; accidental moving is prevented using a drag threshold. (Drag-select requires Shift - see below - so no risk of confusion.)
• Shift-click on a new item adds it to (extends) the selection
• Shift-clicking a selected item deselects it. (If there are multiple items under the cursor, e.g. overlapping nodes, it cycles through selecting the other ones first, and then to deselection, then back to the top.)
• Dragging over an area changes the selection to all items within the area. If you need to avoid accidental moves, use Shift-drag. There is also a drag threshold to avoid accidentally resetting the selection if you do a slightly messy click.
• Shift-dragging over an area adds all within the area to the selection
• A single click in an area with no items clears the selection

I suggest that drag-subtraction is not necessary. You'd only need drag subtraction if you wanted to select all objects in an area, except for those in a smaller area inside it, with that smaller area still being big enough that it was tedious to deselect them all by hand. This seems uncommon.

It is possible to select an individual node within a way without selecting the way itself; clicking an individual node selects it (and others can be added using shift), clicking an area of way between nodes selects the way. It's not possible to select all of the nodes in a way in a single click; you have to do it individually.

Editing

Again, editing objects is a fairly common UI requirement (e.g. for drawing programs) and there are established conventions.

Once objects are selected:

• Moving the selection is done by dragging one of the items using the LMB.
• Deleting the selection is done by pressing "Delete" or "Backspace". If you delete the node at one end of a section of a way, that part of the way is deleted. If you delete a way, any nodes which are only part of that way are deleted.

Rotation is not supported, as no-one has suggested an actual use for it.

Other operations are more map-specific:

• Merge - press "M". If multiple ways are selected, they are merged; the ways must share at least one node in common. If some part of the combined way needs reversing, the part with fewer nodes is reversed. (If this is wrong, the user can always press R afterwards.) If multiple nodes are selected, they are merged. If a node and a way are selected, the node is joined into the way at the closest point.
• Split way at node - press "S" while a node is selected, and all ways using that node are split at it.
• Reverse way direction - press "R" when a way is selected.
• Align nodes in line - press L, and all selected nodes are lined up.
• Align nodes in circle - press C, and all selected nodes are arranged in a circle.

Addition

The addition interface is spring-loaded. You use Alt-click to make the first addition, and after that, all clicks are "additive" until you double-click to end the adding operation.

• Alt-click LMB to add a node. Ways are automatically drawn between nodes added in sequence. If you had a single node selected when you Alt-clicked, a way terminating at that node is extended to your new node.
• Further LMB clicks add more nodes in the same way
• Double-click to add the last node and finish the way.
• Therefore, an initial Alt-double-click just adds a single node.
• Alt-double-clicking on a part of a way which is not already a node adds a node into the way at that point.
• When you add a single node, that node becomes selected. So you can immediately edit its tags.
• When you have finished adding a way, that way (including pre-existing bits, if you extended a way) is selected (but not its constituent nodes). So you can immediately edit its tags.

Snap: snapping to existing nodes is a toggle (key: N), rather than a modifier key. This means the interface isn't entirely modeless (as you could consider this a mode, albeit a minor mode) but this seems better than having people need to hold down multiple modifier keys while doing delicate additions near existing structures. It seems like the sort of thing particular users will generally want on, or off. If you realise you've created a node when you meant to reuse one, just select the two and press M.

Other

• Undo should be Ctrl-Z (standard); redo should be Ctrl-Y and Ctrl-Shift-Z, and both should undo/redo only the most recent action. So if you've just added 20 nodes in a way, Undo should only remove the 20th, Undo again should remove the 19th and so on. In other words, the granularity of Undo should match the user's actions.
• Edit tags - select an object or objects and then type into the tag editor. The tags are applied to all selected objects. If selected objects have diverse values for the same tag (e.g. you select two ways, one is "name=Foo" and another is "name=Bar", then "name" appears in the tag list greyed out, to show that it can't be edited. (Another option would be to allow editing which splatted the existing values.)

• I put my comments to the above design on the talk page. Toralf 21:02, 14 January 2008 (UTC)

Make it iPodish (by Nic)

How is this iPodish? I'm not familiar with the iPod interface, but I thought it used a click-wheel... Gerv 19:03, 10 December 2007 (UTC)

The most used actions and how I (Nic) think they should work :

• Extend the selected way Double click or something similar. JOSM should use the cosine rule to determine which end to extend. If the new location is in blank space, a new node should be created. If it's near an existing way, that node should be used and if it isn't but it's near an existing way (segment), a new node should be added to that way. -- If the user really wants a new node near an existing object, he should zoom in far enough.
• Select way Single click.
• Move node Drag it. If two nodes now fall on each other, they should be merged.

Presumably this would be undo-able? Gerv 19:03, 10 December 2007 (UTC)

Yes, with Ctrl-Z. In the rare case that it's too late for that, the user must split, extend and merge. Nic 09:32, 11 December 2007 (UTC)

• Add new node to way If the dragging starts near an existing way, a new node should be created and inserted. If the drag ends (LButtonUp) on top of an existing node, a new node should no longer be created.
• Panning Drag any clear (vacant) area.

So no drag-select then? Or does that use a modifier key? Gerv 19:03, 10 December 2007 (UTC)

A modifier and / or a mode selected from a menu item. I rarely drag select. Nic 09:32, 11 December 2007 (UTC)

• Zooming Use 2 buttons (+ and -), instead of a slider.
• Merge and split ways Buttons.

Sure, there'd be buttons too. But are you suggesting not having keystrokes? Gerv 19:03, 10 December 2007 (UTC)

Do you understand that if something isn't mentioned, it is likely irrelevant. Having a button and a key stroke are completely orthogonal and none of these ideas appears to suggest removing any current functionality.--LH 21:48, 10 December 2007 (UTC)

• Add / edit / delete tag 1 button. If the tag already exist, it's an edit if the value is not empty and a delete if the value is empty. Alternative : edit them where they are displayed.

PDA Mode (by Nic)

How I think an editor can work on a PDA / GPSr :

• If a way is selected and the user clicks on the map, the editor looks at the angles in the triangle formed by the last two nodes of the way and the new location. If it's more than say 120, the way is extended. If it's between say 60 and 120 (approximately right angle), a new way is created and selected. The previous 2 tests are also performed with the first 2 nodes of the way. If the angle is less than say 60 in both cases, the way is deselected. Visual cues (e.g. lines or coloured triangles) must help the user
• If no way is selected and the user clicks, a new node must be created and selected.
• If dragging starts on a segment of a way, add a new node to the way and drag it.
• If dragging starts on a node, move the node.
• If the (new) node that was manipulated by the above actions, falls on an existing node, they should be merged.
• If dragging starts on empty space, the map is panned.
• If a way is selected and the "combine" button it clicked, the next way selected will be combined with the currently selected way.
• If a way is selected and the "split" button is clicked, the way will be split at the next node that is selected.
• Delete should work in a similar way.
• Buttons for commonly used actions like undo, redo, zoom-in and zoom-out, as well as tags like 'name' and 'highway=residential'

Toolbased

Instead of making it mode-less, which would require a load of modifier keys and learning curve, make it even more mode-full, by adding more tools. However, classify the tools into 2 kinds: Those that act on the current selection and those that do not. Group the tools into groups, with the (current) most intelligent tools on top, and the spicialized tool below. That could also be shown visially, by having large buttons horizontally for the top-level tools and smaller buttons also horizontally below their parents.

• Select tool. Primary tool as currently. Subtools:
  • Add to selection
  • Remove from selection
• Node select tool
  • Add to selection
  • Remove from selection
• Way select tool
  • Add to selection
  • Remove from selection
• Add tool
  • Extend way tool
  • Add nodes tool
  • Add way tool

...