Page MenuHome

No way to distinguish enum buttons that support shift-click to select multiple
Open, NormalPublic

Description

Blender has some buttons that allow shift-click to select multiple, but no way to show the difference. eg:

Transform Tool, Gizmo's (Move / Rotate / Scale)

Details

Type
To Do

Event Timeline

Campbell Barton (campbellbarton) triaged this task as Normal priority.

I wonder how best to solve this. We only use these types of radio-button widgets that allow multiple selections in a few places, but it's important to communicate that you can hold shift to pick more than one.

My first thought was to just turn them into separate checkbox toggles, but that doesn't work because at least one of them has to be selected always.

Maybe the theme could simply be more different for these types of toggles, but that's still not very clear.

@William Reynish (billreynish) Rather than the normal pointer you could use a pointer with a plus sign?

Maybe some sort of highlight hover effects encompassing all draggable properties/buttons.

OriginalHighlight PropertyHighlight Label

The Highlight Label option may not work everywhere and be easy to miss, but may be replaced with a vertical line along all buttons

OriginalHighlight

Please excuse the crude mockups, the hover effect could simply be just an outline around the buttons/properties, changing color or weight of text, or a simple vertical line across affected options.

@Duarte Farrajota Ramos (duarteframos), this task is about enum buttons like the move / rotate / scale settings in the transform tool, number buttons and checkbox/toggle buttons are different.

The hint to press Shift to select multiple could show in the tooltip at least, not sure how else a user would learn about this without docs or tutorials.

The plus icon appearing next to the cursor would make sense when Shift is pressed, not really before, but at that point it seems too late.

Probably not an acceptable answer, but...one thought is to not (somehow) highlight hidden behavior, but remove the hidden behavior...

So if you click on an unselected item it becomes selected without deselecting anything else. Click on a selected item and it becomes unselected, unless it is the only item selected.

This way users would know how to select multiples from the first moment they select anything. For users who complain about any added clicks, just make ctrl-clicking operate in the old exclusive behavior.

Again, just a (unpopular) thought. LOL

Another, less extreme idea, that does not require any behavior changes.

Use the rules and dividers between items to indicate visually how they are related logically.

So, for example, if multiple buttons are completely distinct from each other, then underscore that separateness by having a rule between them. But if they are related in a way - either more than one can be selected at a time - underscore the connectedness by removing rules between them, making them just parts of a larger group.

In the image below, Transform Orientations look as they do now because each selection is distinct. But Snapping options have their borders removed. Snapping Target are four distinct items, but Affect are multiple.

Similarly Transform Gizmo options lose their separations, as do the edit mode component selection icons:

Its another thought anyway...

@Harley Acheson (harley) These ideas seem very good to me. I actually agree with both of your ideas, which are not mutually exclusive.

Both would help to solve this problem.

To be honest, I don't think the first solution could be implemented in practice because the howls of protest would be unbearable. LOL. But it could be thought through. I had suggested using ctrl-click for current behavior, but that was wrong. That suggestion was really about just swapping the default behavior with the current Shift behavior. And we do have some (fairly) consistent rules on how shift, ctrl, and alt change selection behaviors.

The second suggestion does work quite well for lists, as shown in Transform and Snapping. Although while staring at that capture I realize that the title "Transform Orientations" shown should instead be a singular "Transform Orientation". Similarly, the "Snapping" title should be a plural "Snapping Elements".

@Harley Acheson (harley) I don't see why that would be an issue. To me it seems like a fine solution to make it add to the selection by default. It makes it immediately obvious that you can select multiple items. We don't use this widget type many places - I think that would ok, a nice improvement even.

I would happily aprove of this change. It would single handedly solve the problem by making it immediately discoverable, at the (IMHO small) expense of a little a little getting used to the new behavior.

Well ignoring any political aspects to it (just don't mention my name. LOL), the parts to be thought through carefully are mostly about "extending" selection while changing modes.

It is a very well-hidden feature, but not one we'd want to break. For any readers not familiar: if I am in vertex-select mode with only one vertex selected, and then change to edge-select mode I will then have nothing selected. But if I change selection modes while holding ctrl key then that single selected vertex could turn into multiple selected edges or faces.

Right now this feature works well when changing from a singular mode to another singular mode. But the feature is currently broken for multiple mode selection.

So what I mean is that if you start with my earlier single-vertex selection while in vertex select mode, holding shift AND ctrl to *add* vertex-select mode does NOT extend selection, even though it probably should. So that would mean it would similarly be broken if the behavior of selecting versus shift-selecting were swapped. As you add the higher mode, if ctrl is pressed then do the extension to the higher mode. But then again, there could be other technical reasons why extension does not already work like this.

I guess I'm the only one who thinks this is not an issue.
A tooltip would be more than enough. I mean, there are plenty of apps with similar feature and yet there's nothing fancy happening with their buttons.

I guess I'm the only one who thinks this is not an issue

No, I am just cursed with overthinking everything I ever think about. LOL. AFAICT if we fix multi-mode selection extension then we could just swap selection with shift-selection.

At this point, it's all mixed up.

  1. Move/Rotate/Scale settings in the transform tool or Snapping options, this is the "Radio Buttons" (according to theme preference), but for some reason it allows multiple selection. Although, the radio button means that only one option can be selected. You need to hold Shift for multiple selection.
  2. Shading or Snapping Target this is the correct "Radio Buttons", not allows multiple selection.
  3. Move/Rotate/Scale in the snapping menu or XYZ Axes, it's "Toggle" button, allows multiple selection and no Shift is required for this.
  4. Selection Modes, it's also "Toggle" button, but here you need to hold Shift.

o_O

Move/Rotate/Scale in the transform tool must work like Move/Rotate/Scale in the snapping, no Shift is required. This is the most obvious way, that does not require additional explanations. And it's not called radio buttons.

Shading is radio buttons. I see no reason to separate them visually from the previous ones because you can't miss some feature or do something wrong. You just clicking and everything is obvious.

Selection Modes buttons, it can be a special widget looking different, (perhaps even here you can add a small arrow with a drop-down menu containing expands/contrast switching options). Or just, it can work like all the rest, without Shift key for multiple selection.

And yet, no one will read the tooltips to learn how the buttons work, I assume that many users do not know that, for example, the "Snapping To" options can be multiple at the same time.

@Yevgeny Makarov (jenkm)

Move/Rotate/Scale in the transform tool must work like Move/Rotate/Scale in the snapping, no Shift is required. This is the most obvious way, that does not require additional explanations. And it's not called radio buttons.

Yes, this seems to be the most straight-forward solution, although it does change the interaction a bit. I at least would be fine with this change.