The upcoming 2.70 release is introducing a new modal numinput for tools. Modal numinput is when you’re doing a transform and type in values to control the transforms. The new numinput will allow users to input python expressions and units for transforms. It’s a good addition to functionality but a big regression in usability. The reason is it goes into the basic and most used transforms in Blender - Translate, Rotate, Scale - the bread and butter of 3d manipulation. The current way Blender does this is awsome and one of the big things making Blender fast and a joy to use. It is:
Efficient
Forgiving (pressing X, 9, 0, X, - is the same as 9, -, X, 0, X and order of keys isn’t important)
Easy on the hands (no modifier keys used for input, no ctrl-X, only X)
Works across tools and editors (gives consistency, change it and changes will propagate throughout Blender)
By enabling users to type whole strings into transform input, we lose simple shortcuts like X and forgivness of the current system. The existing system still works, it’s only when starting the new numinput with number keys, that you get stuck in typing the string. Stuck is how I feel in new numinput and instead of a system that works with me, I find a system that limits me and which I try to avoid.
Modal within modal?
Modal tools temporarily take over standard interaction to provide easy-to-access options and make them fast-to-use. E.g. by default X key deletes stuff, but in transform, it limits the transform to X axis. With new modal numinput, transform tools get an extra layer of modal to them. X key limits transform to X axis and when modal numinput is activated, CTRL-X is used to limit transform to X axis. The end result is a tool’s shortcuts change within a single session of using the tool.
It appears to me the new numinput is a similar, but a separate system of modal transform input to what we have now. Somehow it was mistaken as a same type of input and added as a replacement, ignoring or willingly sacrificing the great usability of the current numinput. I hope a better solution is found or at least an option added to disable the new numinput. Despite the added functionality, and a rather useful functionality at that, I wouldn’t give a second thought when deciding which one to use, given the option.
@DruBan
There hasn’t been much discussion regarding this feature so all feedback is welcome. Backspace can indeed be used to go back from modal numinput and the added functionality like the one you mention is an improvement. However, functionality isn’t the same as usability and it’s usabilty that bothers me here. What I really value in the current system is how forgiving it is and thus fast to use.
@bashi
When in new modal numinput, you can press ctrl+- to toggle between negative and positive values. It does what it should but feels like it was added as an afterthought to a not-well designed system. Before going to numinput - toggles negative while in numinput ctrl+- does. So I repeat one of the big issues here - a tool’s shortcuts change within a single session of using the tool.
On mac ctrl± does not do anything at all… but i’m used to Blender not being usable on Mac without heavy tweaking of a lot of things first - and if there’s a keystroke i can change it then, if i could find it… darn.
As far as changing shortcuts in session and so on, i still have not found the best way to communicate such things with the developers…
Here on linux Ctrl-(-) works if numpad minus is used, so i have to throw away mouse and use two handed gesture (right-handed me…). Another one after (or before?) running away noodles at what conveniently was an input swap.
Same opinion here. On one hand, there’s are some really cool things coming in 2.70 and on the other I’m still trying to understand how such a usability regression got its way into Blender. Especially when you consider all the effort and improvement going to UI and usability lately.
I was only testing on windows until now, but on Linux ctrl+- indeed doesn’t work, only with the - on the numpad.
I don’t see how people are unable to use it, you just type the value for transformation the way you would type it in a document or in a message on this forum, and if it’s not what you want you hit backspace.
Though I’ve always hit the ‘-’ first if I wanted a negative value because it seemed more straightforward to type it the way you type a value in text.
I could see questions the other way around to, like with the old system people might be asking why everything just flips or does something else when they press a key after they typed a value. The change, in my opinion, I found nearly as easy to get accustomed to as the old one.
I have to agree… sometimes on scenes i am not sure which way it should be going / which axis it should be on, especially when working in complex scenes where local mode is very important and x y and z directions may be interchanged)… My proposal is below:
x y and z are all exception characters, which can change the axis after input (as well as xx/yy/zz and shift x/xx/y/yy/z/zz)
still has the same properties but _ is another exception character, adds in a *-1 to the end, to flip the direction…
Just for another point of view, I don’t really care how it works. I’ll adapt, especially to obtain the new functionality, which I think is really nice. As for keeping some consistency, perhaps “X” could be parsed the old way, and “*” could be parsed as “multiply.” And maybe “-” could be context aware, e.g., a “-” at the end, or more than one “-” in a row could be used the old way. These might be awful suggestions, I don’t know, I’m just brainstorming out loud. If I’m not making sense then ignore me, this is probably over my head anyway.
Ever typed in some rotation then decided it should go the other way or on a different axis?
Ever rotated on locked Z axis, then move to top view and attempted to rotate on view plane, discover it GOES THE OTHER WAY. (for whatever reason).
Whilst it is excellent to integrate expression handling, easy access to instant negate option is great also.
Ideally options would be great, Blender is lacking user interaction options. Expression input for default but for those who often flip directions and don’t enter expressions would choose the old method option.
Not all user does the same actions for the same goal using the same method to get there, please give options.
I understand about pressing x, y, and z, there should be some code in there that checks for these key presses and change the active axis followed by a check to prevent the input of any other letter keys.
Also, if the minus key could be used as an automatic negation, how would you be able to transform by typing 8*-10 for example?
The new functionality is nice, but for me at least, its more common to have to ‘experiment’ with simple transforms, than to want to transform based on an expression. I would suggest that starting a transform defaults to the old behavior, with a subsequent press of a designated key enabling ‘expression mode’. I haven’t really thought it through so that might be terrible, but I’m just not crazy about this new-fangeled way as a default, slowed me down what felt like quite a bit yesterday.
Option to change in preferences please.
I had to use vanilla Blender 2.69 briefly and I was already quickly irritated at having to enter transforms the old way numeral by numeral instead of just pasting into the expression. As far as I am concerned the ctrl - command is a flip direction.
The instruction ‘10-’ does not mean negative ten. (Except in RPL.) I try to be sympathetic to as many different points of view as I can. But if you mean ‘-10’ you need to write ‘-10’. If you did not before, this is a good time to start! If you make a mistake, backspace to correct it. The same way as I am doing now while typing this. It’s not a use of the keyboard that should be alien to computer users.
For users that are not interested in numeric entry for precision there are plenty of ways to transform from the interface without using any numbers. Why ask for a precision that’s not really precise?
@DruBan -See Rhys’s post above. I may know I want an object to rotate 30 degrees, but depending on what’s being rotated, say a bone, and what angle its being viewed from, such as a camera view, its not always obvious - even with experience, which axis you need, or perhaps which direction around the axis you need to go, or maybe even which space its in.
Certainly, exercising perfect discipline, these could all be worked out in advance every time, or as you suggest, backspace and try again, but for the frequency with which I for one have these difficulties, the ability to just tap “-” (right beside my little finger), or hit the axis key after inputting the angle to quickly cycle between directions, axis and spaces is a much loved feature.
I’m glad the new way is good for you. I would just like the option to default to the old behavior.
I think the concern about easier negation stems from a user expectation. You have already been using it the way it expects to be used now, but a lot of users (myself included) have become accustomed to the ability to easily negate a rotation or translation. It’s super handy to be able to change your mind if you aren’t certain about whether the axis is positive or negative. while being able to evaluate functions is handy, I see myself using that feature almost never. whereas I probably use fast negation every 3 times I use a transform tool. If you want to evaluate a function for a translation, you can already do that in the f6 panel.
I guess I’m also having a hard time envisioning a real world situation where the ability to evaluate a function directly will save that much more time. Why would I want to type 24-6 when I can just type 18?
