Properties Editor Design
Closed, ResolvedPublic

Tokens
"Love" token, awarded by daviddomingues_."Love" token, awarded by jpthrash."Love" token, awarded by juri3d."Love" token, awarded by rawalanche."Love" token, awarded by SteffenD."Love" token, awarded by lcs_cavalheiro."Love" token, awarded by sobbayi."Love" token, awarded by DaPaulus."Like" token, awarded by harley."Love" token, awarded by Scaredyfish."Love" token, awarded by sopranoo."Love" token, awarded by -L0Lock-."Love" token, awarded by ejnaren."Love" token, awarded by januz."Love" token, awarded by Christopher_Anderssarian.
Authored By

Description

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

Details

Differential Revisions
D3442: Split property text and values
Type
Design
There are a very large number of changes, so older changes are hidden. Show Older Changes

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 (wevon) added a comment.EditedMay 12 2018, 1:26 PM

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 (wevon) added a comment.EditedMay 16 2018, 6:32 AM

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.

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!

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

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)

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 :)

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...

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.

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.

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....

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.

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.

Committed checkbox change rB861b0ec4170958814955eadf49c36109eacf9972

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.

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 second what @Campbell Barton (campbellbarton) 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.

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.

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.

Labels going back in the fields?

what about this?

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

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.

I second what @Campbell Barton (campbellbarton) 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.

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.

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?

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.

I second what @Campbell Barton (campbellbarton) 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

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/

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 @Jacques Lucke (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.

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 @Campbell Barton (campbellbarton) 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.

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.

@ronan ducluzeau (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. :)

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 @Jacques Lucke (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

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.

@William Reynish (billreynish) @Dalai Felinto (dfelinto) @Campbell Barton (campbellbarton) 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!

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

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)

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.

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

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).

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 (vklidu) added a comment.EditedJul 13 2018, 6:19 PM

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 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

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.

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

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.

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 :)

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

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'