Blender user interface design

This. Borders vs corners are more instructional. Shortcut could be ALT+click+drag on border created new window in direction of drag. Right-click border to get menu.

the game engine was removed because for problems of desing was too cumbersome, essentially a duplicate of the code of blender, and if a function was implemented, then you had to rewrite and readjust also for the game engine … for this with the years it remained back …
so they preferred to remove it, and adopt the render engines method, with external motors, like Armory and Godot …
and anyway Ton has said that the game engine code will be cleaned up and then resumed in some way in a more modern and less cumbersome approach in the next versions of blender.

… it’s interesting … …
and I suspect that there is also a sort of collective habit by many who come from the “industrial work” … over the years they have become accustomed to working only with a part of the hemisphere and now they have trouble working with the part left …
it’s probably all unconscious …

yes I agree that the property bar can be better used! And your ideas are great :slight_smile:

To go even further, I think that:

  1. there is a need for more consistent titles at the top of the property panel to inform people what kind of property there are looking at (e.g., the icon alone do not help much; e.g., Object Constraints is titled “Light” right now)
  2. some property tabs could be hidden depending on what type of object is selected: when I select a cube, there is no need for a light property (as far as I know, I can’t make the cube project light)
  3. when no object is selected, all object-related property tabs could be hidden, only scene/global property tabs would remain
  4. the tabs for the scene and global properties could be well separated from the current object related property tabs (the small spacing may not be enough of a separation)

Hope that helps :smiley:

2 Likes

my hope… more select object context property pannels like
the good engineered Object Context Menu

I published this in UI paper cuts, but it should be here.
What do you think?
Modify a parameter this way:
Click

18 Likes

It is not clear (to me) in your example how you would differentiate between the “one click” you are showing that sets a value from the one click that is necessary to place your mouse in the area before entering a value with your keyboard.

what I’m interested in is a system that recognizes when there are heavy scenes and gives priority to setting the slider of the parameter that I want to set rather than start to lag to keep “realtime” the changes …
the condition that I would like to activate is always:
first move the parameter slider (in case of possible lag) and at the release of the click, assign the parameter to the object …

I hate terribly when it starts to lag. it makes my work from relaxing to hateful and nervous

edit:

studying your suggestion better seems a really comfortable solution compared to the current state … it could avoid making the work odious when it emerges lag …

I remember suggesting something similar before. Very handy, yeah…

The example you linked to has separate slider from amount input. Therefore a single click can have two different behaviors if you click in either. Still not sure how that would work in santbg’s example.

Click / click and drag would do, I guess…
Click to set the new position, and click and drag to follow the cursor movement?

He suggested a double click.

This is click
2019-02-21_21-19-21

This is click and drag
2019-02-21_21-18-05

And double click to type the value?

6 Likes

But you think about a cluster of properties like “Dimensions” in Properties. There is ResolutionX, ResolutionY, and “%” all together in a group.

All three of these will take a manual numerical entry and you can also drag your mouse to increase or decrease the value.

Are you suggesting that to manually enter a value with your keyboard that you single-click on two of these, but you need to (remember to) double-click on just one of them? Or are you suggesting that every property would need a double-click to enter a value rather than the current single-click?

Yes, that’s exactly the idea.

It would only work for fixed ranges.
Here for example:

Here’s a better example.

Currently for all these inputs you can drag your mouse to change all the values. Or you can single-click and enter a value.

But you are proposing that we would need to single-click to enter a value into IOR but you’d have to double-click on the rest?

double click avoids errors
and the one click “set a parameter between 0 and 1” is much more relaxing and immediate than being grab and drag every time …

1 Like

So you are proposing that for all of our numerical inputs, where we can click once to enter value, should require a double-click instead?

Or are you saying that this is just for properties with a fixed range? So in my example above, IOR would be single-click while all the rest would be double-click?

Only if you used it you can see the advantages of what they are proposing. I really miss this feature in blender.

I imagine for everywhere …
I’ve used this system in other software and I’ve always found it more immediate than being drag and grab each time to set a parameter …
notwithstanding that the drag and grab always remains when it is necessary, especially pressing shift to set more precise numerical parameters …

1 Like