Properties Editor Design #54951

New Issue

Closed

opened 2018-05-04 12:21:42 +02:00 by William Reynish · 117 comments

William Reynish commented 2018-05-04 12:21:42 +02:00

Copy Link

Design Document for the Properties Editor in Blender 2.8.

In Blender 2.8, we want to make some improvements to the Properties Editor. Namely, we want to solve these issues:

Problems

1: The Properties Editor uses inconsistent layouts.
Sometimes, properties are shown in a multi-column layout, sorted top -> bottom, like so:

Other times, we put controls left -> right, like so:

Sometimes, controls are in a single column, like so:

Sometimes, we show the value separate from the label, like so:

Currently, developers have to try and design their panels so that they work with two columns. However, the controls don't always naturally fit in a way that's conducive to such a layout, which causes inconsistencies and headache.

2: The Properties Editor is hard to scan through
Because controls are often scattered in multiple columns, it's difficult to quickly scan through the list. You have to scan down several columns of data.

3: We now have too many widget states to communicate via colors.
In Blender, we now have 8 states:

With this many, colors are no longer a good way to communicate this.

4: The Properties Editor takes up a lot of screen space.
Because it has several columns, users need to keep the Properties Editor rather wide to fit everything. In Blender 2.8, we want to make it less obtrusive, to give users more space for their contents

The Design

For Blender 2.8, we want to make the Properties Editor consistent, so we use the same type of layout everywhere.

We will do this by switching to a consistent single column layout, like so:

This affords us a number of advantages:

• Values are now much easier to visually scan through
• We can improve the ordering and layouts so they are always represented the same way
• The layouts themselves can be improved, because we don't have to work around the two-column issue where the two columns must be roughly the same length.
• It means that we can add visual indicators next to the values, which we couldn't do before.

To communicate widget states, rather than just using colors, we would like to use a clickable visual icon, like so:

The visual indicators can fit with the icons we already have, so that the keyframe indicator looks the same as the keyframe handle in the Graph Editor.

Here's the Transform panel with some values animated, some values on a current keyframe:

The Cycles material properties will now be consistent with the rest of the properties:

Note: We are thinking of ways to make the nesting clearer. Here, we are using brightness to communicate hierarchy depth, like stair steps that lead you further into the abyss, as you move down the node tree. This may become increasingly relevant to make clearer as we nodify more areas in Blender.

Checkboxes

One of the difficulties on the Properties design is the handling of checkboxes. Checkboxes are different from other property types, because the state can only be On or Off. Checkboxes tend to have longer text, because the value itself communicates almost nothing.

In the initial implementation for the Properties, we aligned the checkboxes with the other values, but this created a few problems:

1, There was often not enough space for the full text
2, With the state indicators on the right-hand side, there was a large gap between the value and the state

So, we explored several alternatives for displaying lists of checkboxes. Here you can see different alternatives, with the drawbacks listed underneath:

While all the solutions have compromises, we think the best overall solution is D: Right aligned checkboxes. This allows us to often times make the Properties Editor thinner, and it places the value right next to the state indicator. It also makes it possible to keep using more descriptive language for checkboxes

Header on the side:
In order to fit all the tabs on the screen, we will place them on the side, like so:

The main drawback is that some properties areas will get longer. The avoid excessive scrolling, we plan to make the following changes:

1: Presets in headers
This can mitigate scrolling in a big way. It means that panels can be closed, and users can still change the presets. Users then only need to open the panel if they way to change the presets. Otherwise they can be kept closed, like so:

This way, we can also add presets in many more places. Before, we had to endure the penalty of adding an extra row for the preset, but that no longer applies when it's in the header.

2: Searchable Properties
With a single column, we can implement a feature where users can search for a property to narrow down the list, like so:

Multiple Columns

With this new Properties Editor design, because of search, 'decorator' indicators and the increased readability and eye scanning, it is optimised for a single column approach. However, if users make their Properties Editor wide enough, we could re-flow the panels themselves to create a multi-column layout, like so:

---

This document represents the current design of the Properties Editor in Blender 2.8

Design Document for the Properties Editor in Blender 2.8. In Blender 2.8, we want to make some improvements to the Properties Editor. Namely, we want to solve these issues: ## Problems **1: The Properties Editor uses inconsistent layouts.** Sometimes, properties are shown in a multi-column layout, sorted top -> bottom, like so:  Other times, we put controls left -> right, like so:  Sometimes, controls are in a single column, like so:  Sometimes, we show the value separate from the label, like so:  Currently, developers have to try and design their panels so that they work with two columns. However, the controls don't always naturally fit in a way that's conducive to such a layout, which causes inconsistencies and headache. **2: The Properties Editor is hard to scan through** Because controls are often scattered in multiple columns, it's difficult to quickly scan through the list. You have to scan down several columns of data. **3: We now have too many widget states to communicate via colors.** In Blender, we now have 8 states:  With this many, colors are no longer a good way to communicate this. **4: The Properties Editor takes up a lot of screen space.** Because it has several columns, users need to keep the Properties Editor rather wide to fit everything. In Blender 2.8, we want to make it less obtrusive, to give users more space for their contents ## The Design For Blender 2.8, we want to make the Properties Editor consistent, so we use the same type of layout everywhere. We will do this by switching to a consistent single column layout, like so:  This affords us a number of advantages: - Values are now much easier to visually scan through - We can improve the ordering and layouts so they are always represented the same way - The layouts themselves can be improved, because we don't have to work around the two-column issue where the two columns must be roughly the same length. - It means that we can add visual indicators next to the values, which we couldn't do before. To communicate widget states, rather than just using colors, we would like to use a clickable visual icon, like so:  The visual indicators can fit with the icons we already have, so that the keyframe indicator looks the same as the keyframe handle in the Graph Editor. Here's the Transform panel with some values animated, some values on a current keyframe:  The Cycles material properties will now be consistent with the rest of the properties:  *Note: We are thinking of ways to make the nesting clearer. Here, we are using brightness to communicate hierarchy depth, like stair steps that lead you further into the abyss, as you move down the node tree. This may become increasingly relevant to make clearer as we nodify more areas in Blender.* ## Checkboxes One of the difficulties on the Properties design is the handling of checkboxes. Checkboxes are different from other property types, because the state can only be On or Off. Checkboxes tend to have longer text, because the value itself communicates almost nothing. In the initial implementation for the Properties, we aligned the checkboxes with the other values, but this created a few problems: 1, There was often not enough space for the full text 2, With the state indicators on the right-hand side, there was a large gap between the value and the state So, we explored several alternatives for displaying lists of checkboxes. Here you can see different alternatives, with the drawbacks listed underneath:  While all the solutions have compromises, we think the best overall solution is D: Right aligned checkboxes. This allows us to often times make the Properties Editor thinner, and it places the value right next to the state indicator. It also makes it possible to keep using more descriptive language for checkboxes **Header on the side:** In order to fit all the tabs on the screen, we will place them on the side, like so:  The main drawback is that some properties areas will get longer. The avoid excessive scrolling, we plan to make the following changes: **1: Presets in headers** This can mitigate scrolling in a big way. It means that panels can be closed, and users can still change the presets. Users then only need to open the panel if they way to change the presets. Otherwise they can be kept closed, like so:  This way, we can also add presets in many more places. Before, we had to endure the penalty of adding an extra row for the preset, but that no longer applies when it's in the header.  **2: Searchable Properties** With a single column, we can implement a feature where users can search for a property to narrow down the list, like so:  ## Multiple Columns With this new Properties Editor design, because of search, 'decorator' indicators and the increased readability and eye scanning, it is optimised for a single column approach. However, if users make their Properties Editor wide enough, we could re-flow the panels themselves to create a multi-column layout, like so:  ---- *This document represents the current design of the Properties Editor in Blender 2.8*

William Reynish self-assigned this 2018-05-04 12:21:42 +02:00

William Reynish commented 2018-05-04 12:21:42 +02:00

Author

Copy Link

Added subscriber: @WilliamReynish

Added subscriber: @WilliamReynish

ChristopherAnderssarian commented 2018-05-04 13:44:20 +02:00

Copy Link

Added subscriber: @ChristopherAnderssarian

Added subscriber: @ChristopherAnderssarian

ChristopherAnderssarian commented 2018-05-04 13:44:20 +02:00

Copy Link

Excellent,
though "Display device" had me confused for a second...

Excellent, though "Display device" had me confused for a second...

msalv commented 2018-05-04 14:51:07 +02:00

Copy Link

Added subscriber: @moisessalvador

Added subscriber: @moisessalvador

msalv commented 2018-05-04 14:51:07 +02:00

Copy Link

Any plans for the data type icons to be displayed vertically? There can be too many at any given time and they get cramped horizontally in the header, forcing to grab and drag with middle mouse, or use a wider area, this would only get worse if the plan is to have a narrower properties editor by default. This is a common thing that people have surely suggested in the past, but I guess it was turned down because headers cannot be vertical, on the sides. But the icons could ocupy their own vertical region inside the editor instead of the header, leaving the header for other things. It would also look more in line with the new toolbar design. Another posibility could be dropdown menus

Any plans for the data type icons to be displayed vertically? There can be too many at any given time and they get cramped horizontally in the header, forcing to grab and drag with middle mouse, or use a wider area, this would only get worse if the plan is to have a narrower properties editor by default. This is a common thing that people have surely suggested in the past, but I guess it was turned down because headers cannot be vertical, on the sides. But the icons could ocupy their own vertical region inside the editor instead of the header, leaving the header for other things. It would also look more in line with the new toolbar design. Another posibility could be dropdown menus

William Reynish commented 2018-05-04 14:52:34 +02:00

Author

Copy Link

Yes, we've discussed that, and may go that route.

Yes, we've discussed that, and may go that route.

William Reynish commented 2018-05-04 15:04:59 +02:00

Author

Copy Link

Added subscriber: @pablovazquez

Added subscriber: @pablovazquez

Ejnar Brendsdal commented 2018-05-04 22:29:59 +02:00

Copy Link

Added subscriber: @EjnarBrendsdal

Added subscriber: @EjnarBrendsdal

Ejnar Brendsdal commented 2018-05-04 22:29:59 +02:00

Copy Link

This looks amazing. I will let you know that I strongly support all the things you have mentioned here.
But with the risk of opening a can of worms (I know how difficult these design issues can be) how will we be able to tell properties with multiple states?
For example: What of a property is overwritten by a value that is animated?
Do we see multiple small icons? Can they be combined somehow?

This looks amazing. I will let you know that I strongly support all the things you have mentioned here. But with the risk of opening a can of worms (I know how difficult these design issues can be) how will we be able to tell properties with multiple states? For example: What of a property is overwritten by a value that is animated? Do we see multiple small icons? Can they be combined somehow?

msalv commented 2018-05-04 23:01:28 +02:00

Copy Link

Removed subscriber: @moisessalvador

Removed subscriber: @moisessalvador

Matias Mendiola commented 2018-05-04 23:41:59 +02:00

Member

Copy Link

Added subscriber: @mendio

Added subscriber: @mendio

Luciano Muñoz Sessarego commented 2018-05-05 00:19:50 +02:00

Member

Copy Link

Added subscriber: @LucianoMunoz

Added subscriber: @LucianoMunoz

Luciano Muñoz Sessarego commented 2018-05-05 00:19:50 +02:00

Member

Copy Link

In #54951#499807, @EjnarBrendsdal wrote:
This looks amazing. I will let you know that I strongly support all the things you have mentioned here.
But with the risk of opening a can of worms (I know how difficult these design issues can be) how will we be able to tell properties with multiple states?
For example: What of a property is overwritten by a value that is animated?
Do we see multiple small icons? Can they be combined somehow?

nice i was going to ask exactly that.

> In #54951#499807, @EjnarBrendsdal wrote: > This looks amazing. I will let you know that I strongly support all the things you have mentioned here. > But with the risk of opening a can of worms (I know how difficult these design issues can be) how will we be able to tell properties with multiple states? > For example: What of a property is overwritten by a value that is animated? > Do we see multiple small icons? Can they be combined somehow? nice i was going to ask exactly that.

William Reynish commented 2018-05-05 12:51:45 +02:00

Author

Copy Link

We never supported that before, so I'm not sure if it will be an issue. Most of the time it's not possible to be in multiple states. If something is driven, it can't be animated. If something is linked, it can't be driven or animated. If something is animated, it can't be a regular value, and so on. They are, AFAIK, almost always mutually exclusive.

We never supported that before, so I'm not sure if it will be an issue. Most of the time it's not possible to be in multiple states. If something is driven, it can't be animated. If something is linked, it can't be driven or animated. If something is animated, it can't be a regular value, and so on. They are, AFAIK, almost always mutually exclusive.

Antonio Vazquez commented 2018-05-05 13:01:57 +02:00

Member

Copy Link

Added subscriber: @antoniov

Added subscriber: @antoniov

Antonio Vazquez commented 2018-05-05 13:01:57 +02:00

Member

Copy Link

@WilliamReynish do this "one column" layout will be applied to all panels? I mean, modifiers, properties, etc.

I was thinking that if this is the goal, I could start to apply this "single colum" design to all panels and modifiers in grease pencil branch to save time after merge to 2.8.

@WilliamReynish do this "one column" layout will be applied to all panels? I mean, modifiers, properties, etc. I was thinking that if this is the goal, I could start to apply this "single colum" design to all panels and modifiers in grease pencil branch to save time after merge to 2.8.

Antonio Vazquez commented 2018-05-05 13:05:11 +02:00

Member

Copy Link

About using icons near of value to communicate state instead of color, I think this is a great idea. We must not use only color to identify any state because this does not work for color blind people (8% men, 0.5% women).

About using icons near of value to communicate state instead of color, I think this is a great idea. We must not use only color to identify any state because this does not work for color blind people (8% men, 0.5% women).

William Reynish commented 2018-05-05 13:06:08 +02:00

Author

Copy Link

Yes, that's the idea. But don't worry too much with your GP branch - it's not really your responsibility to change that on your end - we haven't even implemented it for the main 2.8 branch yet. Also, to make it work well, we need to make some changes to the way we display properties, so that a single column is always nicely aligned, with text right aligned, and so on.

So, don't worry about complying with this design until then - and hopefully your branch will have been merged anyway :)

Yes, that's the idea. But don't worry too much with your GP branch - it's not really your responsibility to change that on your end - we haven't even implemented it for the main 2.8 branch yet. Also, to make it work well, we need to make some changes to the way we display properties, so that a single column is always nicely aligned, with text right aligned, and so on. So, don't worry about complying with this design until then - and hopefully your branch will have been merged anyway :)

Antonio Vazquez commented 2018-05-05 13:09:19 +02:00

Member

Copy Link

Ok, let me know if you need my help for any task.

Ok, let me know if you need my help for any task.

William Reynish commented 2018-05-05 13:10:45 +02:00

Author

Copy Link

For sure, will do :)

For sure, will do :)

Ejnar Brendsdal commented 2018-05-05 15:04:12 +02:00

Copy Link

In #54951#499918, @WilliamReynish wrote:
We never supported that before, so I'm not sure if it will be an issue. Most of the time it's not possible to be in multiple states. If something is driven, it can't be animated. If something is linked, it can't be driven or animated. If something is animated, it can't be a regular value, and so on. They are, AFAIK, almost always mutually exclusive.

Oh ok. So it will not be possible to animate the values that we overwrite on links? For example if I link in multiple instances of characters that can change color (animate color prop) then it won't be possible with overwrites?

> In #54951#499918, @WilliamReynish wrote: > We never supported that before, so I'm not sure if it will be an issue. Most of the time it's not possible to be in multiple states. If something is driven, it can't be animated. If something is linked, it can't be driven or animated. If something is animated, it can't be a regular value, and so on. They are, AFAIK, almost always mutually exclusive. Oh ok. So it will not be possible to animate the values that we overwrite on links? For example if I link in multiple instances of characters that can change color (animate color prop) then it won't be possible with overwrites?

William Reynish commented 2018-05-05 15:22:18 +02:00

Author

Copy Link

Yes that will be possible, to overwrite a linked color. You will even be able to overwrite each instance of the linked item differently, when was not possible before. Very powerful!

As for the UI, the user marks the ID block as overridable. Then, any change to values inside it will be marked as an override. In that case all the properties will have a link icon, except the value you’ve overridden, which will have an override icon

Yes that will be possible, to overwrite a linked color. You will even be able to overwrite each instance of the linked item differently, when was not possible before. Very powerful! As for the UI, the user marks the ID block as overridable. Then, any change to values inside it will be marked as an override. In that case all the properties will have a link icon, except the value you’ve overridden, which will have an override icon

lower case commented 2018-05-05 15:29:32 +02:00

Copy Link

Added subscriber: @lowercase

Added subscriber: @lowercase

lower case commented 2018-05-05 15:29:32 +02:00

Copy Link

I still prefer colors I think, you could just pick a better palette...
almost every single property can be animated in Blender, even checkboxes, would that mean having grey dots everywhere?
a new 'modified' state for animated properties would be so nice to have, it just helps you feel you have control over your work... btw you are doing a great job!

I still prefer colors I think, you could just pick a better palette... almost every single property can be animated in Blender, even checkboxes, would that mean having grey dots everywhere? a new 'modified' state for animated properties would be so nice to have, it just helps you feel you have control over your work... btw you are doing a great job!

William Reynish commented 2018-05-05 15:58:07 +02:00

Author

Copy Link

Just colors quickly become rather random though. Originally, we picked yellow and green for Keyframe and Animated states, because they reflect the Keyframe icon and animation curves. But with so many states as we have now, it's hard to remember them all. Users have to remember that teal = overridden, orange = linked, purple, driven. In fact, the main reason we went with just colors for Blender 2.5, is that we were still using a multi-column layout.

Perhaps we will even do both colors & symbols.

Just colors quickly become rather random though. Originally, we picked yellow and green for Keyframe and Animated states, because they reflect the Keyframe icon and animation curves. But with so many states as we have now, it's hard to remember them all. Users have to remember that teal = overridden, orange = linked, purple, driven. In fact, the main reason we went with just colors for Blender 2.5, is that we were still using a multi-column layout. Perhaps we will even do *both* colors & symbols.

Loïc DAUTRY commented 2018-05-06 13:40:38 +02:00

Copy Link

Added subscriber: @L0Lock

Added subscriber: @L0Lock

S commented 2018-05-06 16:57:52 +02:00

Copy Link

Added subscriber: @sopranoo

Added subscriber: @sopranoo

William Reynish commented 2018-05-06 18:41:03 +02:00

Author

Copy Link

Added subscriber: @brecht

Added subscriber: @brecht

William Reynish removed their assignment 2018-05-07 00:14:52 +02:00

Brecht Van Lommel was assigned by William Reynish 2018-05-07 00:14:52 +02:00

Duarte Farrajota Ramos commented 2018-05-07 01:22:08 +02:00

Copy Link

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos

Duarte Farrajota Ramos commented 2018-05-07 01:22:08 +02:00

Copy Link

I'm really loving the style and overall design; vertical tabs and search filtering make a lot more sense.

I believe you are already planing this, but better value box hover highlighting would also be great, so one knows if clicking will trigger either direct value editing, arrow increments, or drag to slide.

I fear having a single column layout will require too much scrolling, even with combined presets and headers. Perhaps there could be an option auto collapse all headers, and have only one expanded at any times.
Shift-Clicking upon several headers would 'pin' multiple open at a time. I believe there was once an addon that accomplished this workflow.

Likewise it would be great if one could edit several different properties tabs at one. Say Scene Properties and Render Properties, by Shift-Clicking on both tabs would open a list of both properties, or Collections and Layers could be simultaneously pined, for example.

I'm really loving the style and overall design; vertical tabs and search filtering make a lot more sense. I believe you are already planing this, but better value box hover highlighting would also be great, so one knows if clicking will trigger either direct value editing, arrow increments, or drag to slide. I fear having a single column layout will require too much scrolling, even with combined presets and headers. Perhaps there could be an option auto collapse all headers, and have only one expanded at any times. Shift-Clicking upon several headers would 'pin' multiple open at a time. I believe there was once an addon that accomplished this workflow. Likewise it would be great if one could edit several different properties tabs at one. Say Scene Properties and Render Properties, by Shift-Clicking on both tabs would open a list of both properties, or Collections and Layers could be simultaneously pined, for example.

William Reynish commented 2018-05-07 01:25:31 +02:00

Author

Copy Link

Duarte: the first feature is already implemented.

The auto-collapse thing also exists, but you have to hold down a modifier key. We could make it more discoverable somehow.

Duarte: the first feature is already implemented. The auto-collapse thing also exists, but you have to hold down a modifier key. We could make it more discoverable somehow.

Duarte Farrajota Ramos commented 2018-05-07 01:42:28 +02:00

Copy Link

In #54951#500286, @WilliamReynish wrote:
The auto-collapse thing also exists, but you have to hold down a modifier key. We could make it more discoverable somehow.

Indeed just tested and Ctrl-Clicking does the job. I use Blender daily and still discovering new stuff after all these years. Great, thanks and keep up the excellent work. :)

> In #54951#500286, @WilliamReynish wrote: > The auto-collapse thing also exists, but you have to hold down a modifier key. We could make it more discoverable somehow. Indeed just tested and Ctrl-Clicking does the job. I use Blender daily and still discovering new stuff after all these years. Great, thanks and keep up the excellent work. :)

Dalai Felinto commented 2018-05-07 09:25:48 +02:00

Owner

Copy Link

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'

Dalai Felinto closed this issue 2018-05-07 09:25:48 +02:00

David Kozma commented 2018-05-07 14:46:49 +02:00

Copy Link

Added subscriber: @DavidKozma

Added subscriber: @DavidKozma

David Kozma commented 2018-05-07 14:46:49 +02:00

Copy Link

Oh, it's done now but let's hope you still read this :)
I love the general direction, I'd only like to add my 2cents here:

I always found the number fields too high in your mockups and now as you try to implement a 1 column solution the significance of this increased.
So I chipped away 6 pixels from their height. It's more pleasing for my eyes and also it significantly reduces the height of properties.

(it's a gif) What do you think?

As a happy accident - after I shrinked the number fields - I discovered that if I remove just about a pixel from each tab they get on the same grid size as my changes.

Oh, it's done now but let's hope you still read this :) I love the general direction, I'd only like to add my 2cents here: I always found the number fields too high in your mockups and now as you try to implement a 1 column solution the significance of this increased. So I chipped away 6 pixels from their height. It's more pleasing for my eyes and also it significantly reduces the height of properties.  (it's a gif) What do you think? As a happy accident - after I shrinked the number fields - I discovered that if I remove just about a pixel from each tab they get on the same grid size as my changes. 

William Reynish commented 2018-05-07 23:04:50 +02:00

Author

Copy Link

David Kozma: Yes, that makes sense. It all adds up, and alleviates scrolling further.

David Kozma: Yes, that makes sense. It all adds up, and alleviates scrolling further.

Aaron Carlisle commented 2018-05-09 02:42:16 +02:00

Member

Copy Link

Added subscriber: @Blendify

Added subscriber: @Blendify

Aaron Carlisle commented 2018-05-09 02:42:16 +02:00

Member

Copy Link

To communicate widget states, rather than just using colors, we would like to use a clickable visual icon, like so:

Will these have a popup that can explain what there are?

> To communicate widget states, rather than just using colors, we would like to use a clickable visual icon, like so: Will these have a popup that can explain what there are?

William Reynish commented 2018-05-09 10:06:13 +02:00

Author

Copy Link

The tooltip will tell the user what the state means.

The tooltip will tell the user what the state means.

Luciano Muñoz Sessarego commented 2018-05-09 10:23:20 +02:00

Member

Copy Link

They do seem hard to catch at a glance, and I do agree that icons in this case are more selfexplanatory, could we do Icons + the colored number field?, It feels like that would read much better at a glance.

They do seem hard to catch at a glance, and I do agree that icons in this case are more selfexplanatory, could we do Icons + the colored number field?, It feels like that would read much better at a glance.

William Reynish commented 2018-05-09 10:25:38 +02:00

Author

Copy Link

That’s a possibility, yes. We already discussed that, as a way to clarity that the value itself is being affected.

That’s a possibility, yes. We already discussed that, as a way to clarity that the value itself is being affected.

Albert commented 2018-05-10 23:12:13 +02:00

Copy Link

Added subscriber: @wevon-2

Added subscriber: @wevon-2

Albert commented 2018-05-10 23:12:13 +02:00

Copy Link

From Node Editor and the proposal of Properties Editor, I have made a new proposal trying to unify the representation of its attributes in the two editors, indicating if the attribute is animated, linked ..., and at the same time indicated if it has Inputs or Outputs.

To navigate through the nodes from Properties Editor you only need to click on the entry or exit circle to jump from node to node. Right now, when you have a very large node tree, from the Attribute Editor you do not clarify, because they all appear and so much information overloads a lot.

I have also tried that you can animate directly by clicking on the point/diamond.

From Node Editor and the proposal of Properties Editor, I have made a new proposal trying to unify the representation of its attributes in the two editors, indicating if the attribute is animated, linked ..., and at the same time indicated if it has Inputs or Outputs. To navigate through the nodes from Properties Editor you only need to click on the entry or exit circle to jump from node to node. Right now, when you have a very large node tree, from the Attribute Editor you do not clarify, because they all appear and so much information overloads a lot. I have also tried that you can animate directly by clicking on the point/diamond. 

Paul Szajner commented 2018-05-12 03:06:46 +02:00

Copy Link

Added subscriber: @sozap

Added subscriber: @sozap

Paul Szajner commented 2018-05-12 03:06:46 +02:00

Copy Link

I think adding icons near each property add a lot of clutter...
current color code works well for keyframes and drivers, how about adding an icon only when a property is overidden ?
Also , what append in your proposal when an overhidden propertie is animated ?

It's just my 2 cents, I'm sure these questions have been already answered...
Keep up the good work, 2.8 is getting really awesome !

I think adding icons near each property add a lot of clutter... current color code works well for keyframes and drivers, how about adding an icon only when a property is overidden ? Also , what append in your proposal when an overhidden propertie is animated ? It's just my 2 cents, I'm sure these questions have been already answered... Keep up the good work, 2.8 is getting really awesome !

Albert commented 2018-05-12 13:26:31 +02:00

Copy Link

I have updated the design.

I think adding icons near each property add a lot of clutter...
current color code works well for keyframes and drivers, how about adding an icon only when a property is overidden ?

I disagree, the icons clarify the information, especially when the theme was changed, and allow to edit it with a single click

Also , what append in your proposal when an overhidden propertie is animated ?

I think that in my new proposal it is well indicated.

On the other hand I have been thinking about the Inputs and Outputs topic. The Keys and Drivers are Inputs in other softwares but they overload the node trees a lot, for this reason I would treat them as they do now, and I would center them between the name and the value of the attribute.
The rest of inputs and outputs I think that as Blender currently works, they overload the Attribute Editor. I think it would be convenient to find a way to navigate the node tree from the Attribute editor, without having to expose all the attributes in a list format.

I have updated the design.  > I think adding icons near each property add a lot of clutter... > current color code works well for keyframes and drivers, how about adding an icon only when a property is overidden ? I disagree, the icons clarify the information, especially when the theme was changed, and allow to edit it with a single click > Also , what append in your proposal when an overhidden propertie is animated ? I think that in my new proposal it is well indicated. On the other hand I have been thinking about the Inputs and Outputs topic. The Keys and Drivers are Inputs in other softwares but they overload the node trees a lot, for this reason I would treat them as they do now, and I would center them between the name and the value of the attribute. The rest of inputs and outputs I think that as Blender currently works, they overload the Attribute Editor. I think it would be convenient to find a way to navigate the node tree from the Attribute editor, without having to expose all the attributes in a list format.

Albert commented 2018-05-16 06:32:47 +02:00

Copy Link

Finally, I have made a comparison between the current distribution of the attributes and the proposal with the alignments changed, to see the final effect.
I've done a simple animation to show how the cursor affects the three attribute editors at the same time.
https://youtu.be/q_SW-d1kJFQ
It is necessary to show how to navigate between nodes from Attribute Editor, but I think that showing a pop-up Node Editor window would be enough.
I would also like to comment that other programs such as Houdini or Maya align in a similar way, but then add long sliders to the right.
I have added and updated the icons.

Finally, I have made a comparison between the current distribution of the attributes and the proposal with the alignments changed, to see the final effect. I've done a simple animation to show how the cursor affects the three attribute editors at the same time. https://youtu.be/q_SW-d1kJFQ It is necessary to show how to navigate between nodes from Attribute Editor, but I think that showing a pop-up Node Editor window would be enough. I would also like to comment that other programs such as Houdini or Maya align in a similar way, but then add long sliders to the right. I have added and updated the icons. 

Marco commented 2018-05-27 21:59:14 +02:00

Copy Link

Added subscriber: @MarcoModena

Added subscriber: @MarcoModena

Jacques Lucke commented 2018-05-31 17:24:03 +02:00

Member

Copy Link

Added subscriber: @JacquesLucke

Added subscriber: @JacquesLucke

Jonathan Lampel commented 2018-05-31 18:31:55 +02:00

Copy Link

Added subscriber: @JonathanLampel-4

Added subscriber: @JonathanLampel-4

Steffen Dünner commented 2018-05-31 21:34:32 +02:00

Copy Link

Added subscriber: @SteffenD

Added subscriber: @SteffenD

Galen Beals commented 2018-06-01 10:50:07 +02:00

Copy Link

Added subscriber: @galenbeals

Added subscriber: @galenbeals

Galen Beals commented 2018-06-01 10:50:07 +02:00

Copy Link

I just wanted to say that I'm really loving everything that's happening here. I think one thing a lot of people are missing is the power of presets. Just imagine that you have a bunch of states that you normally use for each of the rollouts. Once you have these states (Presets) you'll basically never have a reason to open the rollout afterword. It has the potential to revolutionize how we work, Just imagine you're setting up a render and you switch to the render tab, pick the sample preset, pick the output size preset, turn on volumetrics and the best setting that you normally use all with a click of a preset and you're off. It's one thing to have a preset for the entire property page (which has the potential to confuse because you're not always sure about all the things that it changes) but an entirely different thing to be able to have such a high level of control with each of the rollouts having presets. Really amazing idea!

I just wanted to say that I'm really loving everything that's happening here. I think one thing a lot of people are missing is the power of presets. Just imagine that you have a bunch of states that you normally use for each of the rollouts. Once you have these states (Presets) you'll basically never have a reason to open the rollout afterword. It has the potential to revolutionize how we work, Just imagine you're setting up a render and you switch to the render tab, pick the sample preset, pick the output size preset, turn on volumetrics and the best setting that you normally use all with a click of a preset and you're off. It's one thing to have a preset for the entire property page (which has the potential to confuse because you're not always sure about all the things that it changes) but an entirely different thing to be able to have such a high level of control with each of the rollouts having presets. Really amazing idea!

Lloyd commented 2018-06-01 11:10:45 +02:00

Copy Link

Added subscriber: @LloydAlmeida

Added subscriber: @LloydAlmeida

Lloyd commented 2018-06-01 11:10:45 +02:00

Copy Link

Most monitors are widescreen.
Single column layout forces a lot of scrolling. Bad UX

A responsive layout is the way forward.

See Jacques Lucke's prototype at https://www.youtube.com/watch?v=AwAhJMIXPyw
Not only is this a more elegant solution he has intergrated Search which is HUGE

Most monitors are widescreen. Single column layout forces a lot of scrolling. Bad UX A responsive layout is the way forward. See Jacques Lucke's prototype at https://www.youtube.com/watch?v=AwAhJMIXPyw Not only is this a more elegant solution he has intergrated Search which is HUGE

Lsscpp commented 2018-06-01 13:24:44 +02:00

Copy Link

Added subscriber: @lsscpp

Added subscriber: @lsscpp

Lsscpp commented 2018-06-01 13:24:44 +02:00

Copy Link

Would something like this be viable to reduce clutter and to give a better separation for customizing UI?

(imagine the right properties in the right panel, of course)

Would something like this be viable to reduce clutter and to give a better separation for customizing UI?  (imagine the right properties in the right panel, of course)

Ludvik Koutny commented 2018-06-06 11:15:05 +02:00

Contributor

Copy Link

Added subscriber: @Rawalanche

Added subscriber: @Rawalanche

Ludvik Koutny commented 2018-06-06 11:15:05 +02:00

Contributor

Copy Link

When I've designed Corona UI, I've found out that just a simple introduction of proper vertical and horizontal UI element alignment can greatly aid readability of multi column layouts. So it's not that multi column layouts are inherently messy and less readable, but that they require a good, grid like alignment to be readable :)

When I've designed Corona UI, I've found out that just a simple introduction of proper vertical and horizontal UI element alignment can greatly aid readability of multi column layouts. So it's not that multi column layouts are inherently messy and less readable, but that they require a good, grid like alignment to be readable :)

Gustavo Munioz commented 2018-06-10 19:07:52 +02:00

Copy Link

Added subscriber: @Mustardo

Added subscriber: @Mustardo

Gustavo Munioz commented 2018-06-10 19:07:52 +02:00

Copy Link

Unification for unifications sake seems rather pointless to me. I fear a lot of these changes in 2.8 are very significantly doing one thing. Remove information from view.
I don't care if it's easier to learn this way, once learned the other way isnt hard either! But the other way gives me all the information I need at once. Here the direction seems to be leading away from this.
This especially goes for sculpt mode and the single column direction...

Not a naysayer, loving many other things you're changing about the UI! But everywhere where I get less information than before, i'll (hopelessly) argue for that not to happen...

Unification for unifications sake seems rather pointless to me. I fear a lot of these changes in 2.8 are very significantly doing one thing. Remove information from view. I don't care if it's easier to learn this way, once learned the other way isnt hard either! But the other way gives me all the information I need at once. Here the direction seems to be leading away from this. This especially goes for sculpt mode and the single column direction... Not a naysayer, loving many other things you're changing about the UI! But everywhere where I get less information than before, i'll (hopelessly) argue for that not to happen...

William Reynish commented 2018-06-10 23:01:59 +02:00

Author

Copy Link

We are adding multi-column auto-flow support. Currently it works in Object Properties Transform and Relations panels. Has to be added more places.

This way we get both: a more scannable, hierarchical, consistent and easy to keyframe layout in which you can search, and also the ability to display sections as multiple columns if you make the Properties Editor wider. The way they are defined now is easier to extend and keep sane.

Sculpt Mode always had only a single column layout in 2.79 and earlier, so actually, with the new flow layout, the reverse is true: It'll be possible to display Sculpt settings as multiple columns where it used to be only one.

We are adding multi-column auto-flow support. Currently it works in Object Properties Transform and Relations panels. Has to be added more places. This way we get both: a more scannable, hierarchical, consistent and easy to keyframe layout in which you can search, and also the ability to display sections as multiple columns if you make the Properties Editor wider. The way they are defined now is easier to extend and keep sane. Sculpt Mode always had only a single column layout in 2.79 and earlier, so actually, with the new flow layout, the reverse is true: It'll be possible to display Sculpt settings as multiple columns where it used to be only one.

William Reynish commented 2018-06-10 23:29:30 +02:00

Author

Copy Link

Also consider this: The speed at which you can locate an element in the UI is not always correlated to the number of items visible at all times. You can have a UI like 2.49, with thousands of tiny buttons, and users then have to play a game of Where's Waldo to locate what they are searching for. Even though you have more items on the screen, it can be slower to use, and require more cognitive load, because they are not quickly scannable, properly labeled or grouped in any consistent way, which adds lots of mental overhead.

Additionally, if you compress UI items together so that you end up having to use of lots of abbreviations and shorthands, it means that many users will have to constantly use tooltips to understand what 'AccY' means, for example. (In Blender 2.49 it means Constant Acceleration Y). This again makes the UI very slow, even though you can fit in more things on the screen.

That said, we do have plans to make UI widgets a hair less tall, which actually adds up to a lot when you have many controls on screen, plus the aforementioned flow layout system.

Also consider this: The speed at which you can locate an element in the UI is not always correlated to the number of items visible at all times. You can have a UI like 2.49, with thousands of tiny buttons, and users then have to play a game of Where's Waldo to locate what they are searching for. Even though you have more items on the screen, it can be slower to use, and require more cognitive load, because they are not quickly scannable, properly labeled or grouped in any consistent way, which adds lots of mental overhead. Additionally, if you compress UI items together so that you end up having to use of lots of abbreviations and shorthands, it means that many users will have to constantly use tooltips to understand what 'AccY' means, for example. (In Blender 2.49 it means Constant Acceleration Y). This again makes the UI very slow, even though you can fit in more things on the screen. That said, we do have plans to make UI widgets a hair less tall, which actually adds up to a lot when you have many controls on screen, plus the aforementioned flow layout system.

Gustavo Munioz commented 2018-06-11 09:31:07 +02:00

Copy Link

With the sculpt Mode j refer to the drop downs. (Not tablet friendly, only 1 can be opened at a time
I wonder if you are a user of the software because this sounds totally dogmatic and not based on user reality. In cases you are right of course in other places like xyz coordinates or view resolution and frames single column is an utter waste of space. Having to move the cursor to access information has to become less not more....

With the sculpt Mode j refer to the drop downs. (Not tablet friendly, only 1 can be opened at a time I wonder if you are a user of the software because this sounds totally dogmatic and not based on user reality. In cases you are right of course in other places like xyz coordinates or view resolution and frames single column is an utter waste of space. Having to move the cursor to access information has to become less not more....

KiJeon commented 2018-06-13 14:31:15 +02:00

Copy Link

Added subscriber: @0o00o0oo

Added subscriber: @0o00o0oo

Loïc DAUTRY commented 2018-06-25 11:44:54 +02:00

Copy Link

About the checkbox layouts mockups :

IMO I think B and C have the advantage of an “aligned text fields”, which for a lot of people is more readable, fast to search in a fast pace, and is almost mandatory for people having reading/sight disorder.
But the problem is that the text fields are easily cropped on B (and A), huge screenspace waste on C and A…
But with C, we can crop the pannel’s width to make it not waste. And if it gest cropped up to the point some text fields get cropped too, at least it's only the end of the text fields, the start is still visible and I'm sure that keeping the beginning of a text field is smarter than the end. (And btw, I think that is true for every layout with text fields, not just for checkboxes.)

So, C looks the best of four to me.

About the checkbox layouts mockups : IMO I think B and C have the advantage of an “aligned text fields”, which for a lot of people is more readable, fast to search in a fast pace, and is almost mandatory for people having reading/sight disorder. But the problem is that the text fields are easily cropped on B (and A), huge screenspace waste on C and A… But with C, we can crop the pannel’s width to make it not waste. And if it gest cropped up to the point some text fields get cropped too, at least it's only the end of the text fields, the start is still visible and I'm sure that keeping the beginning of a text field is smarter than the end. (And btw, I think that is true for every layout with text fields, not just for checkboxes.) So, C looks the best of four to me.

Lsscpp commented 2018-06-25 12:05:22 +02:00

Copy Link

D looks more logical to me.
Everywhere, beginning from right, you have: state, little padding, value field, little padding, label.
In the special case of checkboxes, label is not aligned with other labels. But hey, it's a special case.

D looks more logical to me. Everywhere, beginning from right, you have: state, little padding, value field, little padding, label. In the special case of checkboxes, label is not aligned with other labels. But hey, it's a special case.

Campbell Barton commented 2018-06-25 14:03:14 +02:00

Owner

Copy Link

Added subscriber: @ideasman42

Added subscriber: @ideasman42

Campbell Barton commented 2018-06-25 14:03:14 +02:00

Owner

Copy Link

Committed checkbox change 861b0ec417

We could choose other kinds of buttons also use less space, or use only as much space as needed. Color for eg only needs 2x units, some enums that only show numbers take much more room then is necessary.

This is always at the expense of nicely aligned text, however many cases currently text is obscured, so it may be justified.

Committed checkbox change 861b0ec417 We could choose other kinds of buttons also use less space, or use only as much space as needed. Color for eg only needs 2x units, some enums that only show numbers take much more room then is necessary. This is always at the expense of nicely aligned text, however many cases currently text is obscured, so it may be justified.

Campbell Barton commented 2018-06-26 10:50:59 +02:00

Owner

Copy Link

I committed this change since our UI team agreed on it but I'm not convinced the checkbox layout changes are an improvement.

The example in the task is contrived to make the previous layout logic look bad:

• The right hand side showing the number buttons is ~25..30% wider.

In Blender both sides get the same amount of space), could be changed but this means text for non checkboxes is obscured even more often.

• The text for number buttons is small.

In practice text is clipped in many other cases - meaning that we often need a wider region so users can read the text anyway.

• The checkboxes are grouped.

In practice checkboxes may not be grouped - having unaligned labels looks more noisy.

Eg:

---

A case could be made that we just need to make the region wider for the new layout to be usable irrespective of checkboxes. eg:

I committed this change since our UI team agreed on it but I'm not convinced the checkbox layout changes are an improvement. The example in the task is contrived to make the previous layout logic look bad:  - The right hand side showing the number buttons is ~25..30% wider. ``` In Blender both sides get the same amount of space), could be changed but this means text for non checkboxes is obscured even more often. ``` - The text for number buttons is small. ``` In practice text is clipped in many other cases - meaning that we often need a wider region so users can read the text anyway. ``` - The checkboxes are grouped. ``` In practice checkboxes may not be grouped - having unaligned labels looks more noisy. ``` Eg:  ---- A case could be made that we just need to make the region wider for the new layout to be usable irrespective of checkboxes. eg: 

Dalai Felinto commented 2018-06-26 11:19:09 +02:00

Owner

Copy Link

Added subscriber: @dfelinto

Added subscriber: @dfelinto

Dalai Felinto commented 2018-06-26 11:19:09 +02:00

Owner

Copy Link

I second what @ideasman42 said. And to be fair I tried with decorators for checkboxes and it doesn't look bad, even though the decorator is far from the checkbox:

Full disclosure: In this example I also removed all the separators in the layout. Since I believe they add noise, but that's a separated discussion.

I second what @ideasman42 said. And to be fair I tried with decorators for checkboxes and it doesn't look bad, even though the decorator is far from the checkbox:  *Full disclosure: In this example I also removed all the separators in the layout. Since I believe they add noise, but that's a separated discussion.*

ronan ducluzeau commented 2018-06-26 12:21:43 +02:00

Copy Link

Added subscriber: @zeauro

Added subscriber: @zeauro

ronan ducluzeau commented 2018-06-26 12:21:43 +02:00

Copy Link

If it is acceptable to have Values left aligned, why labels have to be right aligned ? It is less pratical to scan than a left aligned text.
Would it be possible to give a try to centered aligned text, too ? IMO, it is better compromise for columns.
a mock-up with Labels space centered.
When there is a main label and a sub-label, an alignement corresponding of each level.

If it is acceptable to have Values left aligned, why labels have to be right aligned ? It is less pratical to scan than a left aligned text. Would it be possible to give a try to centered aligned text, too ? IMO, it is better compromise for columns. a mock-up with Labels space centered. When there is a main label and a sub-label, an alignement corresponding of each level. 

William Reynish commented 2018-06-26 13:12:47 +02:00

Author

Copy Link

Center aligned text should be avoided, as it has none of the advantages of either left or right aligned text. Left aligned text has advantages in that it’s easy to scan the list, but the label gets disconnected from the value, which is a problem, esp with multiple columns. Right aligned text has the advantage that it makes it possible to have configurations with a leading label, such as Scale X, Y, Z in the Transform panel. Plus the advantage of a clear connection between value and label. The ragged-left negative space left when using right-aligned labels is actually a good visual marker for quickly identifying areas in panels, which helps with quickly scanning through properties.

Center aligned text should be avoided, as it has none of the advantages of either left or right aligned text. Left aligned text has advantages in that it’s easy to scan the list, but the label gets disconnected from the value, which is a problem, esp with multiple columns. Right aligned text has the advantage that it makes it possible to have configurations with a leading label, such as Scale X, Y, Z in the Transform panel. Plus the advantage of a clear connection between value and label. The ragged-left negative space left when using right-aligned labels is actually a good visual marker for quickly identifying areas in panels, which helps with quickly scanning through properties.

Lsscpp commented 2018-06-26 13:13:14 +02:00

Copy Link

Labels going back in the fields?

Labels going back in the fields? 

Manuel Grad commented 2018-06-26 13:19:05 +02:00

Copy Link

Added subscriber: @ManuelGrad

Added subscriber: @ManuelGrad

Manuel Grad commented 2018-06-26 13:19:05 +02:00

Copy Link

what about this?

this way value and state are close together and the design is coherent through the properties.

what about this?  this way value and state are close together and the design is coherent through the properties.

ronan ducluzeau commented 2018-06-26 13:31:57 +02:00

Copy Link

In #54951#513748, @WilliamReynish wrote:
Left aligned text has advantages in that it’s easy to scan the list, but the label gets disconnected from the value, which is a problem, esp with multiple columns.

But you are doing a single column layout with subpanels.
Subpanels headers are ruining a grid column layout.
With a layout made of columns of panels, there is no problem. Result is still one column of settings inside one panel.

Right aligned text has the advantage that it makes it possible to have configurations with a leading label, such as Scale X, Y, Z in the Transform panel.

It is not working here. Scale and X are sticked next to each other. There is no emphasis of what is leading label when reading from left to right.
That is really unpleasant to read. There is always an hesitation when reading a two words label. Is this a leading one and a sublabel or just a label made of 2 words ?

The ragged-left negative space left when using right-aligned labels is actually a good visual marker for quickly identifying areas in panels, which helps with quickly scanning through properties.

This point is more in favor of a centered aligned text. Because negative space is present on both sides in that case. It is easier to remind.

> In #54951#513748, @WilliamReynish wrote: > Left aligned text has advantages in that it’s easy to scan the list, but the label gets disconnected from the value, which is a problem, esp with multiple columns. But you are doing a single column layout with subpanels. Subpanels headers are ruining a grid column layout. With a layout made of columns of panels, there is no problem. Result is still one column of settings inside one panel. > Right aligned text has the advantage that it makes it possible to have configurations with a leading label, such as Scale X, Y, Z in the Transform panel. It is not working here. Scale and X are sticked next to each other. There is no emphasis of what is leading label when reading from left to right. That is really unpleasant to read. There is always an hesitation when reading a two words label. Is this a leading one and a sublabel or just a label made of 2 words ? >The ragged-left negative space left when using right-aligned labels is actually a good visual marker for quickly identifying areas in panels, which helps with quickly scanning through properties. This point is more in favor of a centered aligned text. Because negative space is present on both sides in that case. It is easier to remind.

Gibran Kaleel commented 2018-06-26 13:32:21 +02:00

Copy Link

Added subscriber: @JonDoe286

Added subscriber: @JonDoe286

Gibran Kaleel commented 2018-06-26 13:32:21 +02:00

Copy Link

In #54951#513680, @dfelinto wrote:
I second what @ideasman42 said. And to be fair I tried with decorators for checkboxes and it doesn't look bad, even though the decorator is far from the checkbox:

Full disclosure: In this example I also removed all the separators in the layout. Since I believe they add noise, but that's a separated discussion.

+1. I can agree with this too. Makes the whole thing look cleaner & more consolidated. Rather than a change that was made for sake of change. :)

Right-Aligned text labels make sure the Label/Description will not be cut-off. And having the checkbox next to the label makes it easier to access it. Rather than having to move all the way to the right side to check/uncheck options.

Also IMHO, check-boxes moved right-against the activity/keyframe dots made the whole thing seem a bit more convoluted. This seems cleaner and more thought-out.

Plus, when quickly click-dragging up/down to activate those dots, not having check-boxes right next to it helps, not mistakenly checking/unchecking stuff. While click-dragging down if you move a little to the left, might end up hitting a checkbox on the way.

Only con is the ragged-left negative space like William mentioned. But definitely not a deal breaker and I feel it also actually helps to visually break it up a bit, without seeming like a big-wall-o-text when all text is left-aligned and cut off prematurely depending on width of panel.

> In #54951#513680, @dfelinto wrote: > I second what @ideasman42 said. And to be fair I tried with decorators for checkboxes and it doesn't look bad, even though the decorator is far from the checkbox: >  > > *Full disclosure: In this example I also removed all the separators in the layout. Since I believe they add noise, but that's a separated discussion.* +1. I can agree with this too. Makes the whole thing look cleaner & more consolidated. Rather than a change that was made for sake of change. :) Right-Aligned text labels make sure the Label/Description will not be cut-off. And having the checkbox next to the label makes it easier to access it. Rather than having to move all the way to the right side to check/uncheck options. Also IMHO, check-boxes moved right-against the activity/keyframe dots made the whole thing seem a bit more convoluted. This seems cleaner and more thought-out. Plus, when quickly click-dragging up/down to activate those dots, not having check-boxes right next to it helps, not mistakenly checking/unchecking stuff. While click-dragging down if you move a little to the left, might end up hitting a checkbox on the way. Only con is the ragged-left negative space like William mentioned. But definitely not a deal breaker and I feel it also actually helps to visually break it up a bit, without seeming like a big-wall-o-text when all text is left-aligned and cut off prematurely depending on width of panel.

ronan ducluzeau commented 2018-06-26 13:39:37 +02:00

Copy Link

In #54951#513763, @JonDoe286 wrote:
Only con is the ragged-left negative space like William mentioned. But definitely not a deal breaker and I feel it also actually helps to visually break it up a bit, without seeming like a big-wall-o-text when all text is left-aligned and cut off prematurely depending on width of panel.

Another point in favor of centered labels. The shape defined by negative space is quickly changed if editor width is resized.
With centered labels, a mirrored pattern would be kept until you reach the limit of smaller label that would be a more obvious reference.

> In #54951#513763, @JonDoe286 wrote: > Only con is the ragged-left negative space like William mentioned. But definitely not a deal breaker and I feel it also actually helps to visually break it up a bit, without seeming like a big-wall-o-text when all text is left-aligned and cut off prematurely depending on width of panel. Another point in favor of centered labels. The shape defined by negative space is quickly changed if editor width is resized. With centered labels, a mirrored pattern would be kept until you reach the limit of smaller label that would be a more obvious reference.

Jacques Lucke commented 2018-06-26 14:07:20 +02:00

Member

Copy Link

Is there a reason for why the numbers have to take half of the space? Maybe it would be more practical if the width of the sliders and other elements would be static. So that when you increase the width of the panel, only the text gets more space.

Not sure if this was mentioned before or if it is a good idea, just thinking out loud.

Is there a reason for why the numbers have to take half of the space? Maybe it would be more practical if the width of the sliders and other elements would be static. So that when you increase the width of the panel, only the text gets more space. Not sure if this was mentioned before or if it is a good idea, just thinking out loud.

ronan ducluzeau commented 2018-06-26 14:38:32 +02:00

Copy Link

In #54951#513768, @JacquesLucke wrote:
Is there a reason for why the numbers have to take half of the space?

In two columns layout, number fields can contain labels.

Maybe it would be more practical if the width of the sliders and other elements would be static. So that when you increase the width of the panel, only the text gets more space.
Not sure if this was mentioned before or if it is a good idea, just thinking out loud.

It is a good idea. But settings may require different numbers of digits. For settings of physics simulation, user may want 6 digits after coma.
But a picture resolution will not require as much.
And this field is also containing units.
And user may type expressions in it.
So, a static width that suits every value requires a reflection. Or maybe, it means several static widths and implies acceptance of negative space for values, too.

I am not against right alignement next to checkboxes and values for sublabels.
What annoys me is the lack of distinction between a leading label and a sublabel.
So, I make another proposal.
Centered leading labels and the rest right aligned.

> In #54951#513768, @JacquesLucke wrote: > Is there a reason for why the numbers have to take half of the space? In two columns layout, number fields can contain labels. >Maybe it would be more practical if the width of the sliders and other elements would be static. So that when you increase the width of the panel, only the text gets more space. > Not sure if this was mentioned before or if it is a good idea, just thinking out loud. It is a good idea. But settings may require different numbers of digits. For settings of physics simulation, user may want 6 digits after coma. But a picture resolution will not require as much. And this field is also containing units. And user may type expressions in it. So, a static width that suits every value requires a reflection. Or maybe, it means several static widths and implies acceptance of negative space for values, too. I am not against right alignement next to checkboxes and values for sublabels. What annoys me is the lack of distinction between a leading label and a sublabel. So, I make another proposal. Centered leading labels and the rest right aligned. 

Matias Mendiola commented 2018-06-26 14:54:03 +02:00

Member

Copy Link

In #54951#513680, @dfelinto wrote:
I second what @ideasman42 said. And to be fair I tried with decorators for checkboxes and it doesn't look bad, even though the decorator is far from the checkbox:

Full disclosure: In this example I also removed all the separators in the layout. Since I believe they add noise, but that's a separated discussion.

+1, I Agree, IMO the option D implemented right now is not the best solution for checkboxes and adds confusion to the property editor

> In #54951#513680, @dfelinto wrote: > I second what @ideasman42 said. And to be fair I tried with decorators for checkboxes and it doesn't look bad, even though the decorator is far from the checkbox: >  > > *Full disclosure: In this example I also removed all the separators in the layout. Since I believe they add noise, but that's a separated discussion.* +1, I Agree, IMO the option D implemented right now is not the best solution for checkboxes and adds confusion to the property editor

Lucas Boutrot commented 2018-06-26 15:00:50 +02:00

Copy Link

Added subscriber: @thornydre

Added subscriber: @thornydre

Lucas Boutrot commented 2018-06-26 15:00:50 +02:00

Copy Link

Someone posted a solution on Right Click Select that I find quite convenient acutally https://blender.community/c/rightclickselect/cJbbbc/

Someone posted a solution on Right Click Select that I find quite convenient acutally https://blender.community/c/rightclickselect/cJbbbc/

Gibran Kaleel commented 2018-06-26 15:27:57 +02:00

Copy Link

In #54951#513772, @thornydre wrote:
Someone posted a solution on Right Click Select that I find quite convenient acutally https://blender.community/c/rightclickselect/cJbbbc/

That looks really interesting. :)

I like how the On/Off field Highlights/Dims according to state. Makes for quickly visualizing which option is On/Off. Also the Text/Icon in the center for further information.

Would be interesting to have it in color, like a de-saturated Red for Unchecked/Off, de-saturated Green for Checked/On. But it might add more visual noise and make weird (gawdy) mixes with theme colors, etc.

If this idea is to be considered, then like @JacquesLucke mentioned. Having a 'Static' width for all Sliders/Field Boxes would be nice. So whether you're in a single or multi column panel width. All the Sliders/Fields and in this case On/Off Fields will all be the same width.

Would add for more visual balance all-round the Properties Editor. Only issue is to find a 'Safe-Width' that can accommodate all Slider/Field (Numeric, Boolean, Etc) comfortably. In Single/Multi Column Widths. And still not make everything look too small and locked into one corner.

Some users, especially ones who have wider screen monitors will prefer to work with a wider properties editor. But if the Sliders/Field Boxes are 'Static'. Then it won't really change size, no matter the width of the Editor. So that might make it challenging to reach said Slider/Field Boxes. --- Unless everything in the properties editor panel will be left-aligned. But that will leave users with a massive negative space on the right.

The way it is right now, when you make the panel wider the Slider/Field Boxes grow in width too. So visually it doesn't appeal much, but sure makes it easier to click on, especially on ultra-wide screen monitors.

> In #54951#513772, @thornydre wrote: > Someone posted a solution on Right Click Select that I find quite convenient acutally https://blender.community/c/rightclickselect/cJbbbc/ That looks really interesting. :) I like how the On/Off field Highlights/Dims according to state. Makes for quickly visualizing which option is On/Off. Also the Text/Icon in the center for further information. Would be interesting to have it in color, like a de-saturated Red for Unchecked/Off, de-saturated Green for Checked/On. But it might add more visual noise and make weird (gawdy) mixes with theme colors, etc. If this idea is to be considered, then like @JacquesLucke mentioned. Having a 'Static' width for all Sliders/Field Boxes would be nice. So whether you're in a single or multi column panel width. All the Sliders/Fields and in this case On/Off Fields will all be the same width. Would add for more visual balance all-round the Properties Editor. Only issue is to find a 'Safe-Width' that can accommodate all Slider/Field (Numeric, Boolean, Etc) comfortably. In Single/Multi Column Widths. And still not make everything look too small and locked into one corner. Some users, especially ones who have wider screen monitors will prefer to work with a wider properties editor. But if the Sliders/Field Boxes are 'Static'. Then it won't really change size, no matter the width of the Editor. So that might make it challenging to reach said Slider/Field Boxes. --- Unless everything in the properties editor panel will be left-aligned. But that will leave users with a massive negative space on the right. The way it is right now, when you make the panel wider the Slider/Field Boxes grow in width too. So visually it doesn't appeal much, but sure makes it easier to click on, especially on ultra-wide screen monitors.

Alessio Monti di Sopra commented 2018-06-26 15:30:56 +02:00

Copy Link

Added subscriber: @a.monti

Added subscriber: @a.monti

Alessio Monti di Sopra commented 2018-06-26 15:30:56 +02:00

Copy Link

Hi, I just want to add a thing about the checkboxes' alignment: the example used in the description may seem to have been chosen to delegitimize the old layout as you said @ideasman42 but, looking at the various panels across the interface, that is in fact the most common situation in which there are checkboxes.
That kind of heavy alternation between toggles and values that you show in the Volumetric example only happens in a couple of other panels of Cycles' settings, like here:
but even in cases like this one or the one you posted, in my opinion, being able to read the labels without having to scale a lot the interface should be prioritized.

Hi, I just want to add a thing about the checkboxes' alignment: the example used in the description may seem to have been chosen to delegitimize the old layout as you said @ideasman42 but, looking at the various panels across the interface, that is in fact the most common situation in which there are checkboxes. That kind of heavy alternation between toggles and values that you show in the Volumetric example only happens in a couple of other panels of Cycles' settings, like here:  but even in cases like this one or the one you posted, in my opinion, being able to read the labels without having to scale a lot the interface should be prioritized.

Gibran Kaleel commented 2018-06-26 17:39:25 +02:00

Copy Link

In #54951#513767, @zeauro wrote:
Another point in favor of centered labels. The shape defined by negative space is quickly changed if editor width is resized.
With centered labels, a mirrored pattern would be kept until you reach the limit of smaller label that would be a more obvious reference.

@zeauro Yeah but the isssue with centered labels is the amount of negative space on 'Both Sides' opposed to just one side. And with right-aligned labels it serves another purpose. Being aligned right-up against the corresponding value it represents. (Text/Numeric Fields, Drop-down Menus, Checkboxes, Etc.)

Readability and quickly relating which label is to which value/function is important. Especially when all the listings are not separated in anyway by any horizontal grid lines.

For an example, I quickly cooked-up the negative space differences between, Right-Aligned & Center-Aligned Labels. (Apologies for the difference in fonts, I don't have the default Sans font for Blender, so used a close proxy to approximate same size.)

Negative Space on Right-Aligned Labels:

As you can see, even though ragged and asymmetric, all the negative space is focused to the left side. And still the prime purpose of the labels is still served. Sitting right next to the value field it corresponds to. Even though all the negative space is seemingly erratic towards the left side, the right side seems to have a nice 'Blocked' & 'Balanced' look. Making it easier to read and to quickly let your eyes follow onto, which belongs to what.

Negative Space on Center-Aligned Labels:

And in this one. Seems a bit more chaotic than the previous. The negative space is filling both sides. Especially the important area between Text Label & Value Field. IMHO, That's the space which is crucial for your eyes to align both columns. And adding random spaces into that space becomes a bit of a hot-mess.

And there seems to be a certain disconnect between the 'Text Label' and it's respective 'Value Field'. Which sort of defeats the purpose of the text label being aligned with the value field in the first place.

Hope this makes sense and a meaningful case towards Right-Aligned Text Labels. But it's sincerely my opinion and I hope we could all get together and find what's best for Blender. :)

> In #54951#513767, @zeauro wrote: > Another point in favor of centered labels. The shape defined by negative space is quickly changed if editor width is resized. > With centered labels, a mirrored pattern would be kept until you reach the limit of smaller label that would be a more obvious reference. @zeauro Yeah but the isssue with centered labels is the amount of negative space on 'Both Sides' opposed to just one side. And with right-aligned labels it serves another purpose. Being aligned right-up against the corresponding value it represents. (Text/Numeric Fields, Drop-down Menus, Checkboxes, Etc.) Readability and quickly relating which label is to which value/function is important. Especially when all the listings are not separated in anyway by any horizontal grid lines. For an example, I quickly cooked-up the negative space differences between, Right-Aligned & Center-Aligned Labels. *(Apologies for the difference in fonts, I don't have the default Sans font for Blender, so used a close proxy to approximate same size.)* Negative Space on Right-Aligned Labels:  As you can see, even though ragged and asymmetric, all the negative space is focused to the left side. And still the prime purpose of the labels is still served. Sitting right next to the value field it corresponds to. Even though all the negative space is seemingly erratic towards the left side, the right side seems to have a nice 'Blocked' & 'Balanced' look. Making it easier to read and to quickly let your eyes follow onto, which belongs to what. Negative Space on Center-Aligned Labels:  And in this one. Seems a bit more chaotic than the previous. The negative space is filling both sides. Especially the important area between Text Label & Value Field. IMHO, That's the space which is crucial for your eyes to align both columns. And adding random spaces into that space becomes a bit of a hot-mess. And there seems to be a certain disconnect between the 'Text Label' and it's respective 'Value Field'. Which sort of defeats the purpose of the text label being aligned with the value field in the first place. Hope this makes sense and a meaningful case towards Right-Aligned Text Labels. But it's sincerely my opinion and I hope we could all get together and find what's best for Blender. :)

Lsscpp commented 2018-06-26 17:49:59 +02:00

Copy Link

In #54951#513751, @ManuelGrad wrote:
what about this?

this way value and state are close together and the design is coherent through the properties.

I kinda like this mockup, presented here .

It inherits the problem of too little space on the left for the label, but as @JacquesLucke says, why having the number fields that big? In an old mockup i did a few weeks ago, i tried to keep those fields as little as possible, imaging a max value of 10 digits (0000000000) which should be enough afaics. They get quite thinner and allow for longer labels

edit: like this

> In #54951#513751, @ManuelGrad wrote: > what about this? > >  > > this way value and state are close together and the design is coherent through the properties. I kinda like this mockup, [presented here ](https://blender.community/c/rightclickselect/cJbbbc/). It inherits the problem of too little space on the left for the label, but as @JacquesLucke says, why having the number fields that big? In an old mockup i did a few weeks ago, i tried to keep those fields as little as possible, imaging a max value of 10 digits (0000000000) which should be enough afaics. They get quite thinner and allow for longer labels edit: like this 

Galen Beals commented 2018-06-26 17:58:43 +02:00

Copy Link

I think I’m fine with center aligned. My issue is that I don’t think the center needs to be in the actual center. I think the actual value sliders and controls should be about half the size as they are. That way you’ll get a lot more room for the text to the left of them. I have a feeling that a lot of new users will try and pull out the panel while trying to read the properties names and wind up getting frustrated because the panel doubles up on its self.

I think I’m fine with center aligned. My issue is that I don’t think the center needs to be in the actual center. I think the actual value sliders and controls should be about half the size as they are. That way you’ll get a lot more room for the text to the left of them. I have a feeling that a lot of new users will try and pull out the panel while trying to read the properties names and wind up getting frustrated because the panel doubles up on its self.

David Kozma commented 2018-06-27 16:55:03 +02:00

Copy Link

Removed subscriber: @DavidKozma

Removed subscriber: @DavidKozma

Jorge Rodrigues commented 2018-06-27 19:02:38 +02:00

Copy Link

Added subscriber: @JRodrigues

Added subscriber: @JRodrigues

Jorge Rodrigues commented 2018-06-27 19:02:38 +02:00

Copy Link

Proposal:

Proposal: 

Oleg commented 2018-06-28 06:12:05 +02:00

Copy Link

Added subscriber: @DotBow

Added subscriber: @DotBow

Oleg commented 2018-06-28 06:12:05 +02:00

Copy Link

@WilliamReynish @dfelinto @ideasman42 Hi guys! I made a proposal on Right-Click Select about checkboxes. I think it should work very well for parts of panel where checkboxes mixed with other UI elements. It easy to click on them and they don't distract the layout. What do you think about it?
P.S. Didn't notice my proposal is already mentioned in messages above. Glad peoples like it!

@WilliamReynish @dfelinto @ideasman42 Hi guys! I made a [proposal on Right-Click Select ](https://blender.community/c/rightclickselect/cJbbbc/solution-for-handling-alignment-and-usability-of-p) about checkboxes. I think it should work very well for parts of panel where checkboxes mixed with other UI elements. It easy to click on them and they don't distract the layout. What do you think about it? P.S. Didn't notice my proposal is already mentioned in messages above. Glad peoples like it!

Alberto Velázquez commented 2018-07-04 22:38:56 +02:00

Copy Link

Added subscriber: @AlbertoVelazquez

Added subscriber: @AlbertoVelazquez

Alberto Velázquez commented 2018-07-04 22:38:56 +02:00

Copy Link

In #54951#513749, @lsscpp wrote:
Labels going back in the fields?

IMHO It's with difference the best solution. The only problem maybe is the interface is really dense but it doesn't waste the space and have little columns. Also it solves a lot of problems in text space.

It's more pragmatic and useful, also help a lot with the tool settings widget

> In #54951#513749, @lsscpp wrote: > Labels going back in the fields? > >  IMHO It's with difference the best solution. The only problem maybe is the interface is really dense but it doesn't waste the space and have little columns. Also it solves a lot of problems in text space. It's more pragmatic and useful, also help a lot with the tool settings widget

Alberto Velázquez commented 2018-07-05 00:33:25 +02:00

Copy Link

Some Mockups of that idea

It probably could be better with the proposal of the wide checkbox

(sorry for the new post, I update the mockup)

Some Mockups of that idea     It probably could be better with the proposal of the wide checkbox (sorry for the new post, I update the mockup)

filip mond commented 2018-07-12 18:53:31 +02:00

Copy Link

Added subscriber: @FilipMond

Added subscriber: @FilipMond

filip mond commented 2018-07-12 18:53:31 +02:00

Copy Link

Do we really need delete symbol "–" on each row? Isn't it more pleasant to let this symbol appeared on mouse-over?

original proposal

delete icon on mouse-over only
(dirtly masked original gif)

... or like this.

There is another thing if there should be "–" or "x", that "–" means take out from the list, "x" means permanently delete. That is what I remember from some discussion. Personaly I don't care, but it would be great to keep consistency and use "–" everywhere(probably). One good thing about "–" symbol is that its easier to distinguish from "+" symbol when they are next to each other.

Do we really need delete symbol "–" on each row? Isn't it more pleasant to let this symbol appeared on mouse-over? original proposal  delete icon on mouse-over only (dirtly masked original gif)  ... or like this.  There is another thing if there should be "–" or "x", that "–" means take out from the list, "x" means permanently delete. That is what I remember from some discussion. Personaly I don't care, but it would be great to keep consistency and use "–" everywhere(probably). One good thing about "–" symbol is that its easier to distinguish from "+" symbol when they are next to each other.

Loïc DAUTRY commented 2018-07-13 10:56:42 +02:00

Copy Link

It should appear when hovering the item, not the icon only, otherwise a lot of people will just never notice it's there.

It should appear when hovering the item, not the icon only, otherwise a lot of people will just never notice it's there.

Campbell Barton commented 2018-07-13 11:19:44 +02:00

Owner

Copy Link

In general, hiding something unless you're hovering directly over it is less discoverable and should be avoided.

It's also incompatible with some tablet configurations (or touch, though we don't support that at the moment).

If its visually noisy to show information, it can be made more subtle (or only show for active item as in the last example).

In general, hiding something unless you're hovering directly over it is *less* discoverable and should be avoided. It's also incompatible with some tablet configurations (or touch, though we don't support that at the moment). If its visually noisy to show information, it can be made more subtle (or only show for active item as in the last example).

Alberto Velázquez commented 2018-07-13 11:25:37 +02:00

Copy Link

I think that it's better hide the - until user focus on an element. Because a list of - appear more other type of symbol instead a remove symbol.

And I don't worry aboyt "hiding" because in this case is easy to discover in the moment that you try to select one workspace, is really easy to learn the use.

I think that it's better hide the - until user focus on an element. Because a list of - appear more other type of symbol instead a remove symbol. And I don't worry aboyt "hiding" because in this case is easy to discover in the moment that you try to select one workspace, is really easy to learn the use.

filip mond commented 2018-07-13 18:19:51 +02:00

Copy Link

In #54951#518831, @L0Lock wrote:
It should appear when hovering the item, not the icon only, otherwise a lot of people will just never notice it's there.

Yes, thats why I attempted last screen, it should be on hovering over item.
(anim gif was just quick hack to see difference, how much "–" symbol disturbs attention)

In #54951#518832, @ideasman42 wrote:
In general, hiding something unless you're hovering directly over it is less discoverable and should be avoided.
It's also incompatible with some tablet configurations (or touch, though we don't support that at the moment).
If its visually noisy to show information, it can be made more subtle (or only show for active item as in the last example).

It is not hidden, any user discover it at the moment he use this menu and will want to choose item, that is definitely the first action he will try.

(Compatibility with tablets - I can't argument on that.)

There is no way to do it subtle since its one pixel line and only one way to decrease dominance is to use some grey colour, that is used in "disabled" meaning.
"... show only for active item" - here I don't understand the "active" - if you mean user needs to click on item first, that it doesn't make a sense, if you mean active be hovering over item - so yeas that was a purpose of my proposal.

Symbol on every row looks more like a decoration pattern and visually at the end less informative.

X symbol

Red Dot

Minus

> In #54951#518831, @L0Lock wrote: > It should appear when hovering the item, not the icon only, otherwise a lot of people will just never notice it's there. Yes, thats why I attempted last screen, it should be on hovering over item. (anim gif was just quick hack to see difference, how much "–" symbol disturbs attention) > In #54951#518832, @ideasman42 wrote: > In general, hiding something unless you're hovering directly over it is *less* discoverable and should be avoided. > It's also incompatible with some tablet configurations (or touch, though we don't support that at the moment). > If its visually noisy to show information, it can be made more subtle (or only show for active item as in the last example). It is not hidden, any user discover it at the moment he use this menu and will want to choose item, that is definitely the first action he will try. (Compatibility with tablets - I can't argument on that.) There is no way to do it subtle since its one pixel line and only one way to decrease dominance is to use some grey colour, that is used in "disabled" meaning. "... show only for active item" - here I don't understand the "active" - if you mean user needs to click on item first, that it doesn't make a sense, if you mean active be hovering over item - so yeas that was a purpose of my proposal. Symbol on every row looks more like a decoration pattern and visually at the end less informative. X symbol  Red Dot  Minus 

filip mond commented 2018-07-13 19:07:12 +02:00

Copy Link

Add "New Preset" - why to clutter list with field for new preset? Original purpose looks more clear and natural - I want to add so - click plus / name it / click anywhere to confirm. In this way works material so it would be just consistent behaviour.

Just I prefer to have "plus" symbol on left side just because there you start to type so user is not confused where mouse jumped.
Like for new material.

Please don't use line as separator, let use free space do that job.
Gif use the same dimension as original just line is erased and its separated more than enough. In this case is not even space needed, probably.

Add "New Preset" - why to clutter list with field for new preset? Original purpose looks more clear and natural - I want to add so - click plus / name it / click anywhere to confirm. In this way works material so it would be just consistent behaviour. Just I prefer to have "plus" symbol on left side just because there you start to type so user is not confused where mouse jumped. Like for new material.  Please don't use line as separator, let use free space do that job. Gif use the same dimension as original just line is erased and its separated more than enough. In this case is not even space needed, probably.

David commented 2018-07-21 23:16:35 +02:00

Copy Link

Added subscriber: @daviddomingues

Added subscriber: @daviddomingues

David commented 2018-07-21 23:16:35 +02:00

Copy Link

In #54951#507152, @lsscpp wrote:
Would something like this be viable to reduce clutter and to give a better separation for customizing UI?

(imagine the right properties in the right panel, of course)

This is Genius!! I totally approve of this to be added to 2.8. Makes it so much more readable. Great work

> In #54951#507152, @lsscpp wrote: > Would something like this be viable to reduce clutter and to give a better separation for customizing UI? >  > > (imagine the right properties in the right panel, of course) This is Genius!! I totally approve of this to be added to 2.8. Makes it so much more readable. Great work

William Reynish commented 2018-07-22 14:53:27 +02:00

Author

Copy Link

Alessio: We’d rather not do that, as it creates an extra hierarchical interaction level. It makes it so you have to click an extra time if you want to switch to a specific tab, and if you are not sure if it is object or scene, users are forced to click back and forth to look for the tab they are searching for. Besides, with vertical headers, there’s plenty of space for all our Properties tabs. Currently, we have a separator here to serve the same purpose.

Filip: Yes, that’s nicer, and in fact more close to the original design. The biggest issue with the presets is elsewhere though: in order to see the preset used at at glance, the preset name needs to be presented in the header. This gives a major advantage, because you can then properly use presets while panels are closed. However, this is a technical issue more than a design issue, because Blender currently doesn’t know which preset is being used, it can only know which preset was the last one to be activated, which is often out of sync with the actual values used. To fix this, we need to store and read presets in a different way.

Alessio: We’d rather not do that, as it creates an extra hierarchical interaction level. It makes it so you have to click an extra time if you want to switch to a specific tab, and if you are not sure if it is object or scene, users are forced to click back and forth to look for the tab they are searching for. Besides, with vertical headers, there’s plenty of space for all our Properties tabs. Currently, we have a separator here to serve the same purpose. Filip: Yes, that’s nicer, and in fact more close to the original design. The biggest issue with the presets is elsewhere though: in order to see the preset used at at glance, the preset name needs to be presented in the header. This gives a major advantage, because you can then properly use presets while panels are closed. However, this is a technical issue more than a design issue, because Blender currently doesn’t *know* which preset is being used, it can only know which preset was the last one to be activated, which is often out of sync with the actual values used. To fix this, we need to store and read presets in a different way.

David commented 2018-07-22 18:31:06 +02:00

Copy Link

In #54951#520742, @WilliamReynish wrote:
Alessio: We’d rather not do that, as it creates an extra hierarchical interaction level. It makes it so you have to click an extra time if you want to switch to a specific tab, and if you are not sure if it is object or scene, users are forced to click back and forth to look for the tab they are searching for. Besides, with vertical headers, there’s plenty of space for all our Properties tabs. Currently, we have a separator here to serve the same purpose.

Filip: Yes, that’s nicer, and in fact more close to the original design. The biggest issue with the presets is elsewhere though: in order to see the preset used at at glance, the preset name needs to be presented in the header. This gives a major advantage, because you can then properly use presets while panels are closed. However, this is a technical issue more than a design issue, because Blender currently doesn’t know which preset is being used, it can only know which preset was the last one to be activated, which is often out of sync with the actual values used. To fix this, we need to store and read presets in a different way.

I agree that adds one more spet to it, although I think It would be very obvious that a scene setting like "render settings" would be in the scene tab. My point being that It makes more clear to the user where things are. Maybe instead of a completely different tab. A tag that distinguishes the icons from scene properties and objects a part. In the same vertical row with just maybe a colour differential. Don't know, just a thought :)

> In #54951#520742, @WilliamReynish wrote: > Alessio: We’d rather not do that, as it creates an extra hierarchical interaction level. It makes it so you have to click an extra time if you want to switch to a specific tab, and if you are not sure if it is object or scene, users are forced to click back and forth to look for the tab they are searching for. Besides, with vertical headers, there’s plenty of space for all our Properties tabs. Currently, we have a separator here to serve the same purpose. > > Filip: Yes, that’s nicer, and in fact more close to the original design. The biggest issue with the presets is elsewhere though: in order to see the preset used at at glance, the preset name needs to be presented in the header. This gives a major advantage, because you can then properly use presets while panels are closed. However, this is a technical issue more than a design issue, because Blender currently doesn’t *know* which preset is being used, it can only know which preset was the last one to be activated, which is often out of sync with the actual values used. To fix this, we need to store and read presets in a different way. I agree that adds one more spet to it, although I think It would be very obvious that a scene setting like "render settings" would be in the scene tab. My point being that It makes more clear to the user where things are. Maybe instead of a completely different tab. A tag that distinguishes the icons from scene properties and objects a part. In the same vertical row with just maybe a colour differential. Don't know, just a thought :)

Lsscpp commented 2018-07-22 20:40:49 +02:00

Copy Link

I agree for the same reasons. That was an old idea. Yet a stronger separation wouldn't hurt

I agree for the same reasons. That was an old idea. Yet a stronger separation wouldn't hurt

Inês Almeida commented 2018-08-08 15:14:11 +02:00

Member

Copy Link

Added subscriber: @brita

Added subscriber: @brita

Inês Almeida commented 2018-08-08 15:14:11 +02:00

Member

Copy Link

I posted this one on devtalk before realizing there was already a huge discussion on checkboxes here ^^
https://devtalk.blender.org/t/single-column-layout-suggestion-to-have-text-left-aligned/1704

It boils down to preferring the text to be left aligned and ordered in 'actions/state, value, label'

I posted this one on devtalk before realizing there was already a huge discussion on checkboxes here ^^ https://devtalk.blender.org/t/single-column-layout-suggestion-to-have-text-left-aligned/1704 It boils down to preferring the text to be left aligned and ordered in 'actions/state, value, label' 

Hassan commented 2018-08-11 10:46:38 +02:00

Copy Link

Added subscriber: @hjsrabi

Added subscriber: @hjsrabi

Daniel Calderón commented 2019-08-05 11:55:11 +02:00

Copy Link

Added subscriber: @xdanic

Added subscriber: @xdanic

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

partial-write-refactor

brush-assets-project

universal-scene-description

fix-121021

blender-v4.1-release

blender-v3.3-release

blender-v3.6-release

blender-v3.6-temp_wmoss_animrig_public

temp-sculpt-dyntopo

gpencil-next

anim/animation-id-113594

blender-v4.0-release

blender-projects-basics

bridge-curves

sculpt-blender

asset-browser-frontend-split

asset-shelf

tmp-usd-python-mtl

tmp-usd-3.6

blender-v3.5-release

blender-v2.93-release

realtime-clock

sculpt-dev

bevelv2

xr-dev

v4.1.1

v3.6.11

v3.3.18

v4.1.0

v3.3.17

v3.6.10

v3.6.9

v3.3.16

v3.6.8

v3.6.7

v3.3.14

v4.0.2

v4.0.1

v4.0.0

v3.6.5

v3.3.12

v3.6.4

v3.6.3

v3.3.11

v3.6.2

v3.3.10

v3.6.1

v3.3.9

v3.6.0

v3.3.8

v3.3.7

v2.93.18

v3.5.1

v3.3.6

v2.93.17

v3.5.0

v2.93.16

v3.3.5

v3.3.4

v2.93.15

v2.93.14

v3.3.3

v2.93.13

v2.93.12

v3.4.1

v3.3.2

v3.4.0

v3.3.1

v2.93.11

v3.3.0

v3.2.2

v2.93.10

v3.2.1

v3.2.0

v2.83.20

v2.93.9

v3.1.2

v3.1.1

v3.1.0

v2.83.19

v2.93.8

v3.0.1

v2.93.7

v3.0.0

v2.93.6

v2.93.5

v2.83.18

v2.93.4

v2.93.3

v2.83.17

v2.93.2

v2.93.1

v2.83.16

v2.93.0

v2.83.15

v2.83.14

v2.83.13

v2.92.0

v2.83.12

v2.91.2

v2.83.10

v2.91.0

v2.83.9

v2.83.8

v2.83.7

v2.90.1

v2.83.6.1

v2.83.6

v2.90.0

v2.83.5

v2.83.4

v2.83.3

v2.83.2

v2.83.1

v2.83

v2.82a

v2.82

v2.81a

v2.81

v2.80

v2.80-rc3

v2.80-rc2

v2.80-rc1

v2.79b

v2.79a

v2.79

v2.79-rc2

v2.79-rc1

v2.78c

v2.78b

v2.78a

v2.78

v2.78-rc2

v2.78-rc1

v2.77a

v2.77

v2.77-rc2

v2.77-rc1

v2.76b

v2.76a

v2.76

v2.76-rc3

v2.76-rc2

v2.76-rc1

v2.75a

v2.75

v2.75-rc2

v2.75-rc1

v2.74

v2.74-rc4

v2.74-rc3

v2.74-rc2

v2.74-rc1

v2.73a

v2.73

v2.73-rc1

v2.72b

2.72b

v2.72a

v2.72

v2.72-rc1

v2.71

v2.71-rc2

v2.71-rc1

v2.70a

v2.70

v2.70-rc2

v2.70-rc

v2.69

v2.68a

v2.68

v2.67b

v2.67a

v2.67

v2.66a

v2.66

v2.65a

v2.65

v2.64a

v2.64

v2.63a

v2.63

v2.61

v2.60a

v2.60

v2.59

v2.58a

v2.58

v2.57b

v2.57a

v2.57

v2.56a

v2.56

v2.55

v2.54

v2.53

v2.52

v2.51

v2.50

v2.49b

v2.49a

v2.49

v2.48a

v2.48

v2.47

v2.46

v2.45

v2.44

v2.43

v2.42a

v2.42

v2.41

v2.40

v2.37a

v2.37

v2.36

v2.35a

v2.35

v2.34

v2.33a

v2.33

v2.32

v2.31a

v2.31

v2.30

v2.28c

v2.28a

v2.28

v2.27

v2.26

v2.25

Labels

Clear labels   

Interest

Alembic

  

Interest

Animation & Rigging

  

Interest

Asset Browser

  

Interest

Asset Browser Project Overview

  

Interest

Audio

  

Interest

Automated Testing

  

Interest

Blender Asset Bundle

  

Interest

BlendFile

  

Interest

Collada

  

Interest

Compatibility

This issue affects/is about backward or forward compatibility

  

Interest

Compositing

  

Interest

Core

  

Interest

Cycles

  

Interest

Dependency Graph

  

Interest

Development Management

  

Interest

EEVEE

  

Interest

EEVEE & Viewport

  

Interest

Freestyle

  

Interest

Geometry Nodes

  

Interest

Grease Pencil

  

Interest

ID Management

  

Interest

Images & Movies

  

Interest

Import Export

  

Interest

Line Art

  

Interest

Masking

  

Interest

Metal

  

Interest

Modeling

  

Interest

Modifiers

  

Interest

Motion Tracking

  

Interest

Nodes & Physics

  

Interest

OpenGL

  

Interest

Overlay

  

Interest

Overrides

  

Interest

Performance

  

Interest

Physics

  

Interest

Pipeline, Assets & IO

  

Interest

Platforms, Builds & Tests

  

Interest

Python API

  

Interest

Render & Cycles

  

Interest

Render Pipeline

  

Interest

Sculpt, Paint & Texture

  

Interest

Text Editor

  

Interest

Translations

  

Interest

Triaging

  

Interest

Undo

  

Interest

USD

  

Interest

User Interface

  

Interest

UV Editing

  

Interest

VFX & Video

  

Interest

Video Sequencer

  

Interest

Virtual Reality

  

Interest

Vulkan

  

Interest

Wayland

Issues relating to Wayland windowing support.

  

Interest

Workbench

  

Interest: X11

Issues relating to Xorg/X11 support.

  

Legacy

Blender 2.8 Project

  

Legacy

Milestone 1: Basic, Local Asset Browser

  

Legacy

OpenGL Error

  

Meta

Good First Issue

  

Meta

Papercut

  

Meta

Retrospective

  

Meta

Security

Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  

Module

Animation & Rigging

  

Module

Core

  

Module

Development Management

  

Module

EEVEE & Viewport

  

Module

Grease Pencil

  

Module

Modeling

  

Module

Nodes & Physics

  

Module

Pipeline, Assets & IO

  

Module

Platforms, Builds & Tests

  

Module

Python API

  

Module

Render & Cycles

  

Module

Sculpt, Paint & Texture

  

Module

Triaging

  

Module

User Interface

  

Module

VFX & Video

  

Platform

FreeBSD

  

Platform

Linux

  

Platform

macOS

  

Platform

Windows

  

Priority

High

  

Priority

Low

  

Priority

Normal

  

Priority

Unbreak Now!

  

Status

Archived

  

Status

Confirmed

  

Status

Duplicate

  

Status

Needs Info from Developers

  

Status

Needs Information from User

  

Status

Needs Triage

  

Status

Resolved

  

Type

Bug

  

Type

Design

  

Type

Known Issue

  

Type

Patch

  

Type

Report

  

Type

To Do

No Label

Interest

Alembic

Interest

Animation & Rigging

Interest

Asset Browser

Interest

Asset Browser Project Overview

Interest

Audio

Interest

Automated Testing

Interest

Blender Asset Bundle

Interest

BlendFile

Interest

Collada

Interest

Compatibility

Interest

Compositing

Interest

Core

Interest

Cycles

Interest

Dependency Graph

Interest

Development Management

Interest

EEVEE

Interest

EEVEE & Viewport

Interest

Freestyle

Interest

Geometry Nodes

Interest

Grease Pencil

Interest

ID Management

Interest

Images & Movies

Interest

Import Export

Interest

Line Art

Interest

Masking

Interest

Metal

Interest

Modeling

Interest

Modifiers

Interest

Motion Tracking

Interest

Nodes & Physics

Interest

OpenGL

Interest

Overlay

Interest

Overrides

Interest

Performance

Interest

Physics

Interest

Pipeline, Assets & IO

Interest

Platforms, Builds & Tests

Interest

Python API

Interest

Render & Cycles

Interest

Render Pipeline

Interest

Sculpt, Paint & Texture

Interest

Text Editor

Interest

Translations

Interest

Triaging

Interest

Undo

Interest

USD

Interest

User Interface

Interest

UV Editing

Interest

VFX & Video

Interest

Video Sequencer

Interest

Virtual Reality

Interest

Vulkan

Interest

Wayland

Interest

Workbench

Interest: X11

Legacy

Blender 2.8 Project

Legacy

Milestone 1: Basic, Local Asset Browser

Legacy

OpenGL Error

Meta

Good First Issue

Meta

Papercut

Meta

Retrospective

Meta

Security

Module

Animation & Rigging

Module

Core

Module

Development Management

Module

EEVEE & Viewport

Module

Grease Pencil

Module

Modeling

Module

Nodes & Physics

Module

Pipeline, Assets & IO

Module

Platforms, Builds & Tests

Module

Python API

Module

Render & Cycles

Module

Sculpt, Paint & Texture

Module

Triaging

Module

User Interface

Module

VFX & Video

Platform

FreeBSD

Platform

Linux

Platform

macOS

Platform

Windows

Priority

High

Priority

Low

Priority

Normal

Priority

Unbreak Now!

Status

Archived

Status

Confirmed

Status

Duplicate

Status

Needs Info from Developers

Status

Needs Information from User

Status

Needs Triage

Status

Resolved

Type

Bug

Type

Design

Type

Known Issue

Type

Patch

Type

Report

Type

To Do

Milestone

Clear milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

No Assignees

Brecht Van Lommel

40 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#54951

No description provided.