Browse mode enhancement

[slhh]

Browse mode should be enhanced, which does mainly improve accessibility of coincident features and relations.

1. Add a shortcut (e. g. spacebar) to select the feature which is currently shown in the sidebar, maybe we can use the spacebar or the enter key. Shift modifier or a different key for multiselection should be supported too.
2. Add shortcut keys to cycle through all features at the mouse position. Maybe using different keys, this should include relations, and even higher level relations like a master relation of a public transport route.
3. Make the browse mode directly accessible, this can be done using a toggleable "?" button, which can be placed where iD's mode buttons are. It makes the browse mode useful for selecting features with shift modifier, inspecting a feature in advance with browse mode is much more important for these subsequent selections than it is for the first or single feature to be selected. In case of selecting the first or single feature it can be inspected in the inspector after selecting, this is impossible for subsequent selects of a multiselection. Of course browse mode needs to keep the current selection in this case.
4. Maybe a right drag based context menu can offer equivalents of the shortcut operations, this would also make the shortcuts easily discoverable.

[bhousel]

Add a shortcut (e. g. spacebar) to select the feature which is currently shown in the sidebar, maybe we can use the spacebar or the enter key. Shift modifier or a different key for multiselection should be supported too.

Yes, we already do support spacebar in place of click for other things, so this makes sense.

Add shortcut keys to cycle through all features at the mouse position. Maybe using different keys, this should include relations, and even higher level relations like a master relation of a public transport route.

Sure this seems ok..

Make the browse mode directly accessible, this can be done using a toggleable "?" button, which can be placed where iD's mode buttons are. It makes the browse mode useful for selecting features with shift modifier, inspecting a feature in advance with browse mode is much more important for these subsequent selections than it is for the first or single feature to be selected.

I don't really want to add a UI button to return to browse mode. Hitting escape already does this, or clicking anywhere on the map that's not a feature. Also, Shift clicking on another feature currently does extend the selection.

In case of selecting the first or single feature it can be inspected in the inspector after selecting, this is impossible for subsequent selects of a multiselection. Of course browse mode needs to keep the current selection in this case.

I see what you mean though about how with multiple things selected, you can't hover over more things to decide whether you want to select them also. Maybe we can just enable hover here. Returning to browse mode just to select see and things seems backwards. The definition of browse mode is - nothing selected.

Maybe a right drag based context menu can offer equivalents of the shortcut operations, this would also make the shortcuts easily discoverable.

After we merge #3753, we'll be able to do a lot more with the context menu. I'm against introducing a right-drag-based menu though because that's not a traditional UI convention, and would be difficult to explain to people why they get one menu on right-click and a different menu on right-drag. (People are not as good at clicking as you think they are).

[slhh]

I see what you mean though about how with multiple things selected, you can't hover over more things to decide whether you want to select them also.

Yes, this is one usecase, and it also applys with a single thing selected to select the second one.
In addition users should be able to search the feature, which has to be added to the selection.
Furthermore, they should be able to select a coincident feature or a relation to be added to the selection, using the requested browse mode enhancements 1 and 2.

Maybe we can just enable hover here.

We do already hover style the features on the map, but it seems to be a problem to extend this to provide the desired inspection, search, and selection functions.
The sidebar contains important information in mode select (inspector or multiselection list). Overriding the sidebar due to hovering a feature would be quite annoying while moving the mouse over the map. In addition performing an operation on the selection while showing a different feature due to hovering seems to be misleading. We would have to disable operations during hovering. Changing shortcut behavior just based on a little mouse movement doesn't seem to be a good idea.

We can avoid these problems if we change to a extended hover behavior while shift is pressed (in order to select an additional feature). We would have to deactivate the normal operations of mode select while shift is pressed. This would mean we can't use any shortcuts using shift for such operations, which seems to be a significant restriction, and we can and have to use shift based shortcut for the extended hover behavior.

Returning to browse mode just to select see and things seems backwards.

I don't really think so. The user wouldn't need to use browse mode for most multiselections, but there are some cases where it would be really useful.

The definition of browse mode is - nothing selected.

Sure this is its current definition, but I think it is useful to extend it to something like:
No selection is active, but a hidden selection might be stored in the background.

The hidden selection would be reactivated by unchecking the browse mode button, or shift selecting a feature would reactivate and extend it. Otherwise the hidden selection would't have any effect anymore. Therefore, we wouldn't need to be able to explicitly clear the selection.

I don't really want to add a UI button to return to browse mode.

Sure you don't want too many visible UI elements, but we can drop the inspector X/checkmark button instead, which is already a UI button to enter browse mode, but has some drawbacks:

• The "X" fits the your current definition of browse mode, but isn't an intuitive way to reach the main functions (search, hover inspection) of browse mode.
• The "X" was partially replaced by the checkmark due to being misleading, and is is still even more misleading in the case the user has edited a field, but not pressed enter or clicked elsewhere. In this case the button still shows the "X" be
  This seems to be a bug, but I'm unsure how hard it is to fix.
• The checkmark can again be misleading, because new users might assume that it is required to click to take the changes. Therefore they might assume that leaving by clicking in the map would cancel the changes, which is a potential problem.
• The checkmark doesn't intuitively fit to entering browse mode, neither in view of the "nothing selected" definition, nor in view of reaching the browse mode functions.
• The X/Checkmark doesn't intuitively fit to the extended browse mode, and we don't need it to clear the selection as already explained above.

[quincylvania]

1. Add a shortcut (e. g. spacebar) to select the feature which is currently shown in the sidebar, maybe we can use the spacebar or the enter key. Shift modifier or a different key for multiselection should be supported too.

I did this 🚀. The spacebar now works identical to a mouse click for selection, including for deselection and multiselection.

Consequently, I had to remove the functionality of pressing the spacebar to open the context menu, though this was a fairly nonstandard interaction anyway. As a replacement you can now hold down the spacebar over a feature and the edit menu will appear after half a second. This is the same long-press/long-click functionality added for #7577.

In the future I could see extending the spacebar-as-click paradigm even further to drag and double-click map interactions. It's a convenient option to relieve repetitive stress for an application the requires lots of clicking.

---

For point 2, I'd say #1239 and #2225 cover that concern. For points 3 and 4 I agree with Bryan and would leave the existing functionality, though perhaps we can look into hover-inspection during multiselection.