I would like to add that one good reason for not having “too complex” commands* is that having commands with very different levels of complexity also requires a rapid switch of attention, or concentration, which makes a UI tireing to work with.
Edit: Notice that “complex commands” may not be conflated with very complex and capable UIs or dialogs. With “complex command” I mean the amount of concentration needed to actually comprehend both the problem to be solved and the complexity of the change that the command will cause.
Think of the complexity level of a plane. Placing a point in the XY plane requires attention to (or concentration on) only two directions at once.
But, placing the same point in XYZ is NOT done in one step, or thought, so to speak. Instead you first locate the point in two directions, then you shift your attention to locating it in the third direction.
The Plane thinking, and how the level of concentration and focus shifts when working with a 3D Cube instead, may serve as an example of how to keep the “complexity level” of a command within a range of a “Plane”, a level which doesn’t take too much concentration to get right.
A sudden shift in the level of concentration, or comprehension, in order to perform an operation may disrupt a workflow significantly and makes people tired sooner. This is also why “evening out” or “even spacing” the complexity level should be regarded in UI design.
Having said this, every rule may be broken, if there is a good reason for breaking it.
The scroll box is better than typing (which also is still allowed, fine), but it was the quick jumps between “magnitudes” that was the main point.
Gradual fine tuning is also good (the new scroll box) but not enough. It is the big jumps (presets) that is needed on 95% of the cases. With the addition of presets the scale settings would be perfect.
Hi Rolf - just checking to make sure you have tried the new stuff: the scrolling changes the numbers by orders of magnitude, not merely an increment of the last digit on the current number - did you see that?
Ops, honestly, I missed that. Well, that’s much better, of course. Much better. I missed that.
However, and I’m not trying to be too picky now, presets are still preferred though, since it takes more concentration to read scrolling numbers, and more precision to hit those small scroll buttons.
These two arguments are valid as they stand for them selves, but is also among the basic principles to regard when designing UI:s - §1 do not distract, and §2 do not wear (tire) out the user more than necessary. Point wise:
DISTRACTION - Avoid drawing attention to trivial actions That is, the click action should not require concentration to discern which number/magnitude is current, and from that point on decide in which “direction” to go. Compare that with if the same thing has a graphical representation, that is, the positions of the preset-buttons, then it doesn’t take concentration, and thus poses no distraction.
TIREING - Do not require precision where not absolutely necessary
Same thing here - it takes precision hitting those small scroll arrows, while the values to be changed is not exactly in focus. Everything that takes precision is considered tiring to the user.
And CAD is generally requiring very much tireing precision (small points, obscured intersections) and distracting attention to different aspects of commands other than what the user has primarily in mind (multiple dimensions, different properties affected) which makes the user exhausted if the UI isn’t helpful in this regard.
Preset button regards all these criterias, while the scroll box could have provided a mouse click alternative for fine tuning the numbers. As a “stand alone” this scroll box is better than nothing, but in combination with presets it should just scroll the numbers (numbers that are set to start from whatever preset button was last pressed)
Hi Rob - with Gumball set to align by object, Z/Blue should align to surface normal with a single point selected and X/Red to the U direction. If DragMode is set to UVN then multiple surface points will move along the individual normals with the Z/Blue gumball control. Does that get at any of what you need?
So nearly there! The normals function as you described works well. But the green and red arrows look like they are just tangent to the normal. See pic below. It definitely needs aligning to a control polygon with a flip function to get the other side.
