General problems with Blender's new default theme #59796

New Issue

Sebastian Michailidis · 2018-12-23T18:15:05+01:00

2018-12-23 18:15:05 +01:00

This is technically not a bug but I had no idea what would be an appropriate place to post this so that the proposal would receive a proper evaluation.

TL;DR Blender's default theme has issues with consistency, visual hierarchies, color coding, neutrality of the ui and is generally too busy once things get more complex. Here is a direct comparison of the default theme in a complex situation with my proposa (I suggest loading both images in tabs and then go back and forth to see the difference)l:
The theme files can be found at the end of this post.

Good themes contribute to UI/UX for instance by helping to ensure clarity through consistently designed controls and by using colors in meaningful ways. Blender's new default theme looks great with simple scenes but when used for serious and more complex work things quickly become quite messy. I created a test scene that gives an overview of many editors in action. I used that scene to evaluate the current default theme and to create my proposal.

Problems of the current default theme

Inconsistencies
- Design of controls. Users search the UI for familiar shapes that are associated with specific behaviours (like buttons always having color x and shape y). There is great variance in the control design featuring seemingly random shades of gray. Additionally buttons are indistinguishable from inputs (Why for instance does "Unit Scale" have the same design as the buttons for "catmull clark / simple"? On the other hand "Rotation" and "Camera" look close but not identical.
- Editor background have varying shades of gray.
- There are many seemingly random color choices (i. e. why is the text for the selected object in the viewport yellow?)
- Certain colors are used repeatedly but with slight variations in hue and shade.
Lack of visual hierarchies
- I tried to raise awareness for this important topic before and created the following mockup to explain the issue.
Colors
- Associated data isn’t encoded with shades of the same hue but with different hues (i. e. the dope sheet labels and tweened keyframes vs. active keyframes)
- Neutrality: Having prominent colors in the interface of a design application is like having a music application play background music while users write their own song. You need an environment as neutral as possible so that your artwork can be judged on its own without having potentially disharmonic colors surrounding it. Blender sometimes needs color to communicate certain aspects but this should be the exception and happen as toned down as possible.
- Contrasts are not great in some situations like with the labels in the dope sheet.
Arms race for attention
- The lack of clear hierarchies, the inconsistencies and the way color is used lead to a very busy interface. This in turn leads to an arms race for attention. A good UI guides the user and makes it easy to scan the interface. That's not working if everything competes for attention (i. e. the screenshot shows an error in the armature-modifier which is totally lost in the UI).

My proposal
Semi flat version:
Flat version:

I tried to resolve the described issues in my proposal. Following I will give a quick overview over what was done and the reasoning.

Inconsistencies
- Consistent design of buttons and inputs (as far as Blender allows for that.)
- Unified colors.
Lack of visual hierarchies
- Usage of cascading shades of gray so users can scan the interface for the general topic and then are guided level by level to what they are looking for. The deeper in the structure / the more specific, the more toned down things are.
Colors
- Neutrality: colors are avoided whenever possible to not conflict with the content that is being designed. However when they are used they are toned down and try to encode information in meaningful ways.
- Consistent single color to highlight things where necessary. It seemed to make sense to choose Blender's brand-orange for that purpose (not sure what's Blender's official orange shade, tho. So this maybe needs fixing.)
- I feel there are still some details that need improving but I tried to fix contrasts wherever colors with text are present (BTW: value-sliders increase contrast while being edited helping legibility as much as they help setting focus in the interface).
Arms race for attention
- Light UI's are effectively bright yelling light-emitting surfaces which make it very hard to set focus. In contrast dark UIs are great for preventing said arms race for attention as long as you ensure that UI-elements draw only as much attention to them as necessary. The aforementioned fixes hopefully help to achieve this so that now the armature error does stick out instantly even tho there is a lot going on in this test scene.

Two versions
I created two versions: a flat one and a semi flat one. The semi flat one uses subtle 3D-effects to differentiate controls from inputs while the flat version has to rely on the harder to grasp visual encodings of shapes and shade variation. Therefore I personally favor the semi flat version as it allows for clearer encoding of the different control-types. The main motivation to create the entirely flat one was to cater to potential style preferences and to prevent the proposal from not being considered for fashion reasons.

Conclusion
I am sure there are still things that can be improved upon. Also Blender's very fine grained theme editor makes it quite hard to come up with a perfectly consistent solution. However I believe this to be at the very least a good starting point and I hope that the screenshot-comparisons above make a strong enough point to make you consider my proposal.

Finally a prettier and less escalated screenshot:

okapi-dark-flat.xml okapi-dark.xml

Afterthoughts: bugs, technical issues & limitations
There are some details that can't be themed right now from what I understand:

The notification that flashes in the statusbar if you save a file.
It is not possible to achieve full consistency as some colors seemingly randomly have alpha channels while others don't (i. e. selections for lists do have alpha channels but the outliner's selection highlight doesn't. So having something like "1,1,1,0.1" that just elevates the background's brightness by one tenth consistently everywhere can't be done.)
The "view", "select", "add", … buttons in the 3D-view can't be themed with an outline.
If one designs scrollbars to be dark, their resizing-handles disappear.

This is technically not a bug but I had no idea what would be an appropriate place to post this so that the proposal would receive a proper evaluation. **TL;DR** Blender's default theme has issues with consistency, visual hierarchies, color coding, neutrality of the ui and is generally too busy once things get more complex. Here is a direct comparison of the default theme in a complex situation with my proposa (I suggest loading both images in tabs and then go back and forth to see the difference)l: ![01_default.jpg](https://archive.blender.org/developer/F6046366/01_default.jpg) ![02_okapi-dark-semiflat.jpg](https://archive.blender.org/developer/F6046364/02_okapi-dark-semiflat.jpg) The theme files can be found at the end of this post. Good themes contribute to UI/UX for instance by helping to ensure clarity through consistently designed controls and by using colors in meaningful ways. Blender's new default theme looks great with simple scenes but when used for serious and more complex work things quickly become quite messy. I created a test scene that gives an overview of many editors in action. I used that scene to evaluate the current default theme and to create my proposal. **Problems of the current default theme** ![01_default.jpg](https://archive.blender.org/developer/F6046366/01_default.jpg) - __Inconsistencies__ - Design of controls. Users search the UI for familiar shapes that are associated with specific behaviours (like buttons always having color x and shape y). There is great variance in the control design featuring seemingly random shades of gray. Additionally buttons are indistinguishable from inputs (Why for instance does "Unit Scale" have the same design as the buttons for "catmull clark / simple"? On the other hand "Rotation" and "Camera" look close but not identical. ![defaulttheme_controls.jpg](https://archive.blender.org/developer/F6046251/defaulttheme_controls.jpg) - Editor background have varying shades of gray. - There are many seemingly random color choices (i. e. why is the text for the selected object in the viewport yellow?) - Certain colors are used repeatedly but with slight variations in hue and shade. - __Lack of visual hierarchies__ - I tried to raise awareness for this important topic before and created the following mockup to explain the issue.![blender28_menus_hierarchy_issues.jpg](https://archive.blender.org/developer/F6046276/blender28_menus_hierarchy_issues.jpg) - __Colors__ - Associated data isn’t encoded with shades of the same hue but with different hues (i. e. the dope sheet labels and tweened keyframes vs. active keyframes) - Neutrality: Having prominent colors in the interface of a design application is like having a music application play background music while users write their own song. You need an environment as neutral as possible so that your artwork can be judged on its own without having potentially disharmonic colors surrounding it. Blender sometimes needs color to communicate certain aspects but this should be the exception and happen as toned down as possible. - Contrasts are not great in some situations like with the labels in the dope sheet. - __Arms race for attention__ - The lack of clear hierarchies, the inconsistencies and the way color is used lead to a very busy interface. This in turn leads to an arms race for attention. A good UI guides the user and makes it easy to scan the interface. That's not working if everything competes for attention (i. e. the screenshot shows an error in the armature-modifier which is totally lost in the UI). **My proposal** Semi flat version: ![02_okapi-dark-semiflat.jpg](https://archive.blender.org/developer/F6046364/02_okapi-dark-semiflat.jpg) Flat version: ![03_okapi-dark-flat.jpg](https://archive.blender.org/developer/F6046372/03_okapi-dark-flat.jpg) I tried to resolve the described issues in my proposal. Following I will give a quick overview over what was done and the reasoning. - __Inconsistencies__ - Consistent design of buttons and inputs (as far as Blender allows for that.) - Unified colors. - __Lack of visual hierarchies__ - Usage of cascading shades of gray so users can scan the interface for the general topic and then are guided level by level to what they are looking for. The deeper in the structure / the more specific, the more toned down things are. - __Colors__ - Neutrality: colors are avoided whenever possible to not conflict with the content that is being designed. However when they are used they are toned down and try to encode information in meaningful ways. - Consistent single color to highlight things where necessary. It seemed to make sense to choose Blender's brand-orange for that purpose (not sure what's Blender's official orange shade, tho. So this maybe needs fixing.) - I feel there are still some details that need improving but I tried to fix contrasts wherever colors with text are present (BTW: value-sliders increase contrast while being edited helping legibility as much as they help setting focus in the interface). - __Arms race for attention__ - Light UI's are effectively bright yelling light-emitting surfaces which make it very hard to set focus. In contrast dark UIs are great for preventing said arms race for attention as long as you ensure that UI-elements draw only as much attention to them as necessary. The aforementioned fixes hopefully help to achieve this so that now the armature error does stick out instantly even tho there is a lot going on in this test scene. **Two versions** I created two versions: a flat one and a semi flat one. The semi flat one uses subtle 3D-effects to differentiate controls from inputs while the flat version has to rely on the harder to grasp visual encodings of shapes and shade variation. Therefore I personally favor the semi flat version as it allows for clearer encoding of the different control-types. The main motivation to create the entirely flat one was to cater to potential style preferences and to prevent the proposal from not being considered for fashion reasons. **Conclusion** I am sure there are still things that can be improved upon. Also Blender's very fine grained theme editor makes it quite hard to come up with a perfectly consistent solution. However I believe this to be at the very least a good starting point and I hope that the screenshot-comparisons above make a strong enough point to make you consider my proposal. Finally a prettier and less escalated screenshot: ![okapi-dark-wasp.jpg](https://archive.blender.org/developer/F6046380/okapi-dark-wasp.jpg) [okapi-dark-flat.xml](https://archive.blender.org/developer/F6046392/okapi-dark-flat.xml) [okapi-dark.xml](https://archive.blender.org/developer/F6046391/okapi-dark.xml) **Afterthoughts: bugs, technical issues & limitations** There are some details that can't be themed right now from what I understand: - The notification that flashes in the statusbar if you save a file. - It is not possible to achieve full consistency as some colors seemingly randomly have alpha channels while others don't (i. e. selections for lists do have alpha channels but the outliner's selection highlight doesn't. So having something like "1,1,1,0.1" that just elevates the background's brightness by one tenth consistently everywhere can't be done.) - The "view", "select", "add", … buttons in the 3D-view can't be themed with an outline. - If one designs scrollbars to be dark, their resizing-handles disappear.

Sebastian Michailidis commented

2018-12-23 18:15:05 +01:00

Added subscriber: @okapi

Brecht Van Lommel commented

2018-12-24 00:08:56 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2018-12-24 00:08:56 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2018-12-24 00:08:56 +01:00

Brecht Van Lommel self-assigned this 2018-12-24 00:08:56 +01:00

Brecht Van Lommel commented

2018-12-24 00:08:56 +01:00

Please see the explanation on the bug submission page:

What not to report here
For feature requests, feedback, questions or issues building Blender, see communication channels .

Please see the explanation on the bug submission page: > **What not to report here** > For feature requests, feedback, questions or issues building Blender, see [communication channels ](https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests).

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

General problems with Blender's new default theme #59796