2.8 UI: Small, independant UI tweaks
Open, NormalPublic


This is a list of

Improving the look and feel.
UX Details

Making the widgets cleaner, simpler, while also more communicative.

  • Same corner radius for all properties
  • Make it so arrows only appear on mouseover for number fields
  • Make the number field areas highlight on mouseover, so it's always clear which part is activated
  • Kick out all embossing effects everywhere
  • Remove widget outlines

Popovers for Proportional Editing, Pivot & Snap

Now that we have popovers in Blender 2.8, we want to use them in more places. The Proportional Editing, Pivot & Snap features have lots of confusing small buttons with icons, which take up a lot of persistent space in the headers. We would like to simplify it, as well as making these features more clear, like so:

Quit Dialog

Blender now has a consistent quit dialog. We was to improve it in these ways:

-Make it clear which command get executed when the user presses Return
-Make the layout less wide
-Remove all the odd icons

Rollover toolbar tool names

When you mouse over toolbar items, we want to show the tool names:

Right-align number values while editing

When users edit number values, they jump to the left while editing:

We want to eliminate that, so that users can just edit the number values in place.

Dropping materials onto objects should highlight them

Dim shortcuts in menus

Shortcuts in menus should be dimmer than the menu command itself, like so:


This document reflects the current state of the Lekker Blender design for Blender 2.8


William Reynish (billreynish) triaged this task as Normal priority.


it looks mostly nice. Here's some of my subjective feedback:

Grouped UI fields should have at least some horizontal division to better imply their functionality. When I look at the resolution setting for example, it's hard to initially tell how exactly will the UI element behave. There's no visual implication that it still works like 3 separate value sliders, only that they are grouped together because they are related. It can be just a very faint line:

Edges of the editor could be a pixel or two thicker, but I am personally not sure about the excessive corner rounding. It gives it a feeling of separate pieces somehow glued together and barely holding. Current form form feels visually somewhat more solid and durable.

I am not sure if there are plans to re-work the editor UI splitting and merging workflow to something more intuitive, as the current complicated solution is a trap for many new users. But if that was the case, and something more intuitive was implemented, such as Unreal Engine/Fusion style UI editing. Then editors would not need to have 2 UI editing corners, but just one. That would make things look much cleaner :)

What disturbs me the most, however, is that it's not the first proposal where I see a concept of different UI panels having a bit different hues of gray. I am not sure if that is just a mockup helper, or actual proposal, but I would very much dislike that, as slight saturation offsets from the neutral gray are know to cause perception issues for some users, messing with white balance of the eyesight and in turn skewing the color tones when users create their imagery.

By the way, not sure if this is helpful (if not the sorry for cluttering this task), but I am attaching two themes I've made. I find them surprisingly close to your proposal.

Hey and happy lekker Sunday! ;)

Are the topics mentioned here things somebody is currently working on? I'm still available to join the workforce even if I have to do it remotely now. E.g. I could work on the improved feedback on widget rollover, I experimented with this a while ago:

(see see rBc5d4607792bd15fd)

@Julian Eisel (Severin), I committed a different implementation, I wasn't aware you had one. The sub buttons idea might be useful in more cases, I need to look at it more closely.

Hey guys, I don't know if it fits with this task but have you guys considered the headers default position? I think it'd be more consistent if they were all on top by default. It follows the conventions used by most other software and the way we generally read things (top-to-bottom).

It could also be a setting if some people want to keep the old style.

1: Headers can already be set this way
2: Yes, we've considered it and yes, we plan to put them at the top by default.

(from attachement)

  1. Yeah I usually flip them
  2. Awesome! :)

Just for the sake of consistency, how do you visually communicate in popovers what options have a radio-button behaviour instead of a checkbox one (on-off)? Currently the all have checkbox appearance (you are allowed to think that e.g. you can enable multiple falloff or pivot-point).

We should make those differences distinct, yes.

Maybe instead of a "V" you could try using a circle/dot checkmark. Usually radio buttons are displayed like that.

Re: Left-align number values while editing

If you edit text that is a single character, entering a larger number will immediately push the cursor off the right hand side of the button, or move the first character backwards (both are quite awkward solutions).

How would you handle the case where you want to enter a large number having started editing a smaller number?

Why? I don't get it.
As on calculators, writing long numbers keeps the cursor on the right hand and expands the digits on the left. Sounds like a trivial matter of right alignement to me, maybe i missed the point

Alessio: Correct, no you didn't miss the point.

@William Reynish (billreynish) , @Campbell Barton (campbellbarton)

Guys, you might wanna check this out. This might be the first functional App Template, and with a lot of nice UI concepts for 2.8 to take inspiration from:


@William Reynish (billreynish) , @Campbell Barton (campbellbarton)

Guys, you might wanna check this out. This might be the first functional App Template, and with a lot of nice UI concepts for 2.8 to take inspiration from:


I don't think it's a good example to take. It's a bunch of presets built for a very specific needs, workflows and use cases of a single person who does quite specific types of scenes.

Okavango (Okavango) added a comment.EditedMay 31 2018, 2:42 PM

I don't think it's a good example to take. It's a bunch of presets built for a very specific needs, workflows and use cases of a single person who does quite specific types of scenes.

Perhaps true, but also a possible overstatement. A lot of UX ideas, implemented live for devs to test - top bars, asset management, primitives creation, floating editors, tool interaction, properties editor replacement etc. With all the implementation details.

As a working mockup for at least some of the ideas discussed here it couldn't all be that bad, now could it?

hey @William Reynish (billrey) I have few question about Lekker Presets, which I really like and always wanted to have a consistent reliable system like this in blender.
1.- I see in the mockup that when you'd add a preset you'd get to put the name, to change name of a preset would you just double click it? or maybe is it going to be like materials, where youre able to change the name to the selected one right in the box?
2.- I think most panels on the could use a preset manager, there are a ton of panels with a ton of settings to remember or to tweak, but also in some cases maybe it would be nice to have a complete property window, for instance for the rendering properties maybe you want to have a preset that covers all setings but then just customize your output, maybe it would be good idea to give it a though.
3.- will the presets be saved in the blend file or in the blender install? both have their pros and cons.- if it's in the file: how would you share presets across different files?, if it stays in blender itself: how would you share them across different blender installations (ie i want to share the presets with my team for consistency.)

thank you so much for this amazing effort!.

As I mentioned in a previous post, I'm pretty confused with the new interface.

I repeat my message here because it was not in the right category.

I feel quite lost in this new interface, what disturbs me the most is to have the name of the variable outside its label. For people with asperger syndrome in particular, it will be much more difficult to find their way around.

Exemple with the transform panel from blender 2.79 :

Here is what you currently have set (view here) :

Here is a proposal I created :

I don't know if this version is perfect, the most important in my opinion is the name of the variable next to the variable, of a color quite understandable.

Here is a second similar version :

@William Reynish (billreynish) Are there any plans on detachable pinned pop-overs? I'm sure it would be a very welcome addition, at least one that I miss greatly from other 3d programs. I made this little mockup as an example.

I did as well a proposal for layout improvement of the Tool Settings pop-over, I'm sure you guys already have plans for this but I wanted to leave a suggestion here.

We talked about detachable pinned pop-overs, which would be nice to have in several areas. We could make it a standard feature of popovers that they can be dragged out.

However, our main reservation with pinned popovers, is that most of the popovers depend on certain tools, modes or editors being active. So, we don't think it'll work as nicely as you expect, because as you change tools and modes, popovers will disappear and appear from view depending on the active state, which can be quite jarring. In other words, pinned popovers will not really be all that pinned, if you will.

We might add it anyway, but this is the reason we didn't immediately go down this route.

@William Reynish (billreynish) Oh! I totally understand that. I wonder if the tool settings once pinned could stay pinned and update with each tool you activate, that would solve that issue in my eyes. Regarding the modes, I think is fair and understandable that they will close once the mode changes. Anyway, I posted this on the forums and people seem to be quite positive about it, together with a slim layout for tool settings, I know this might be out of scope and breaks the current layout but I would like to leave it here just as a suggestion. Cheers.

For sure, it's not a bad idea per se, it's just that if you pin a popover, you'd probably expect it to stay there, and not disappear as soon as you change tool, mode or close the Editor from which it belonged.

We don't know of a good way around that. We could also try and implement it regardless, but again, it will most likely feel much more jarring than you'd expect.

@William Reynish (billreynish) And what about greyed out or collapsed but stay pinned for when you are back to that mode? I don't know if that is a good idea but this way will stay there just in case you want to toggle modes for xyz reason and come back.

In addition to being grayed out, what about adding a button with the tool icon that corresponds to the pinned settings pop-over so that the user is able to see which pinned pop-overs are tied to specific tools/state? Then a user could potentially have a couple of pinned settings pop-overs for tools they are frequently switching between as well as a way to quickly get back to the tool/state that relates to that specific pop-over.

I very much hope that all fields with decimal values can be in the settings lead to 1 title and keep these settings common for all scenes.
For example, as in the picture, so that you can remove all unnecessary values to 1.23 or 1.555 or .1.3344 etc and degrees in the same way 3.3 degrees or .123.77 and so on for all fields were in 1 format specifically for export.

When will the discussion of the editor uv?
It is very interesting that there will be added or changed.

William Reynish (billreynish) renamed this task from Lekker Blender to 2.8 UI: Small, independant UI tweaks.Jun 11 2018, 9:33 PM
William Reynish (billreynish) updated the task description. (Show Details)

I've noticed a small inconsistency in the viewport. Every button that opens a popover or a menu-like (eg. transform orientation, mode switch, etc) has a downward arrow but the actual header menus don't. This happens in every editor but it's more obvious in the viewport since it has several menu-like selectors.

Maybe header menus should have arrows too, so as a general rule anything that opens a container with more widgets is marked by an down-arrow.