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