Colour coded icons

[nokipaike]

my proposal is to make the button head highly dynamic, link it to the selected objects to the outliner and to the way in which “work mode” we are based in the workspace we are located

doing so the property panels would be strictly divided into several categories and closely related to the mode in which it is working and then the head buttons would never exceed the presence of more than 5 buttons

would change the paradigm a bit, it would become more “working mode” llinked, but so you would have everything cleaner and the panels would emerge only when needed in

edit: just to move forward a chance but without being taken seriously and kick me…
adding, for example, a “scene / render mode” …
we understand that a lot of panels needed only for shading and rendering would end up in this category …

another possible example:
add “simulation mode” another a lot of panels would end up in this category

remember guys, I’m just going to inspire you so that even better ideas emerge

[Znio.G]

that’s the bit of the issue, if you make them more colorful they’ll pop-up and be too distractive, u’ll need the right balance for them to work in both styles, i’ll try again.

[renderhjs]

Just in reponse, I posted this elsewhere before but here is another idea:

Using color channels

Using this technique once can keep the single SVG file and its just a matter of setting the color to either blue, green or red depending on their channel coding

[brecht]

I expect we’d end up with a dozen or two.

If we follow your proposed categories there are about 30. And then people will ask for object modes, and shading modes, and editor types, and icons in editor headers other than the 3D view and properties, etc.

How else would you do it?

We already have this system in place that can define a theme category for our icons, so you can make them all the same colors or you can pick different colors for each category. I think this works really well already, because each theme can set colors that match it. We should keep going with this.

All that’s needed is to expand this a bit more where needed.

This would solve the problem we have, which is that sometimes both a shape and a color can be useful for quick identification, using a system we already have in place. It works with the new icon designs too.

It is more complicated than this. In light themes we use the same icons on light and dark backgrounds, which works fine if they follow the text color, but breaks if each icon has a fixed color. Within toggle/radio buttons with a blue highlight many colors will be difficult to see or not look good. So just adding colors for more icons without any smarter logic will break light themes.

We also reuse the same icons in the outliner and the properties header for example (the coloring is currently only enabled in the outliner). Making them separately themeable probably means splitting up the icons in the icon sheet.

I’m also not sure yet that there even exists a good way to color the new icons in the properties header in a way that is both easy to identify and looks good.

The color coding works ok in its very limited form now, but extending it to the entire UI brings up new issues. I want us to agree on solutions to those issues rather than fixing one thing and leaving something else broken.

[nokipaike]

yes at the end then the coder will decide what is simpler to do to get the same result

[DanPool]

I agree that your mockup has the icons a little too desaturated, but I wouldn’t go to far in the other direction. I really like the tool bar icons that are slightly desaturated until you hover over them or activate the tool.

[DanPool]

It is more complicated than this. In light themes we use the same icons on light and dark backgrounds, which works fine if they follow the text color, but breaks if each icon has a fixed color. Within toggle/radio buttons with a blue highlight many colors will be difficult to see or not look good. So just adding colors for more icons without any smarter logic will break light themes.

How is this different from what is currently happening in the toolbar? We know from the various toolbars that teal, purple, fleshtone, and mint green all work. In weight paint you have blue icons with a dark blue or black outline. That works as well. I really think that the icons should be two colors: text color and category/theme color.

[billrey]

Some of your points I can see. It’s an issue that we re-use the same icons in different contexts if we want to then color them differently depending on the context. The theme category then needs to be set in the python UI file and not in the icons definition. That approach should solve that problem, right?

The thing about bright themes I don’t get. The default pastel colors obviously don’t work in a bright theme, just like white text on a white background is also illegible. Bright themes would have to just pick different, darker colors - it’s up to the theme to make sure that text and icons are legible.

Here’s a quick job of modifying the colors for the Blender Light theme. I think that is a non-issue.

[brecht]

Letting the UI control theming more could help. The properties header icons are not defined in the UI code though, but you could imagine some system to do let the UI make the distinction. Still would think separate icons are better then, even if we do it in the code rather than the icon sheet.

For light themes, note these are all the same icon on different background colors:

Since the theme is middle grey making them all white or black is not too bad, but in general readability would be a problem. Or we require themes to give all their buttons similar brightness so the same icon color works everywhere, but that’s not ideal.

[billrey]

What if the icons always use text color by default, unless we set a theme category in the Python UI file? Then all the icons will just work as they do now using the text color, except that we can pick some places where we think color is needed?

In the example you posted, the two lower pencil icons would then look as they do now, but the one in the header would have an accent color.

Setting the theme category in the UI layout would also be nice in the Add menu, where some icons already have wrong colors because we reuse some icons from the Outliner here.

[zebus3d]

Other mockup:

[Notformortaleyes]

I linked a good idea a saw for colored icons on the blender artist forum a little while ago that i think would work pretty well

[nottelmo]

Not sorry for dropping my 2 cents out of nowhere:

In the outliner, I think it could work better for the icons readability if instead of adding a filled circle below the icon, just desaturate it when it is not selected, and saturate it when selected.

picking up my 2 cents because i’m poor

[1D_Inc]

And you are doing excellent job! Your shapes are just gorgeous =)

[Nix1130]

I think new designs for icons are lack a lot of things, that’s why so many people are bothered with it.

1. One of the most important thing in readability is value contrast. There were a lot of example above with blurred images, basically those show that there is no real distinction between icons in that state, and if user not paying attention it becomes almost impossible to pick one between them, until you stop and choose one. Also it’s not so obvious which one is Active at the moment (Active and Not active states are almost the same value). That can be easily fixed by adding color to Active. All of that easy to check by simply making old and new UI in Black and White.

2. Silhouette is another aspect of good readability, maybe for icons even more important than contrast. They should feel and read different from each other, even with a quick glance. So shapes for icons that are sitting close must consist of different primitives and angles.

3. I would say that new panel is overcrowded, there is no space between each icon and they feel squeezed in buttons. Making them a bit smaller should help.

4. Icons are not very consistent in their style and weight. Some are outlined and some just bold.

5. And finally color, I’m not against monochromatic UI until it’s done correctly and all of points above considered. At the same time small bits of color helps to improve perception.

Here is my 2 cents. Colored and monochromatic mockups. I wish I could spend more time on this, but hope it helps to understand my point of view.

[jendrzych]

@Nix1130
Nice and well founded insight, but unfortunately inconsistent a bit… I am devoted to this project for so long that I stop seeing the faults and weaknesses of the adopted strategy. Moreover some of my icons are not the best - I agree (bold Object icon is super weak, have to change it back to thin one), but contrast is the last thing You should blame them for.

You cheat a bit in Your infographic:

1. Your “monochromatc” icons have slight dark otuline (shadow?) - that boosts up the contrast - for that reason they’re not mono icons anymore;
2. Your inactive icons are full white, while criticized inactive icons are dimmed;
3. You depicted active state of the button with current icon set as gray highlighted, while it’s blue, like on Your proposal.

Anyway, I’d be more than happy if You’d propose individual icons design fixes within the visual style of the set, rather than suggesting completely different apporach. Object, Texture, Particles and Physics are things that can be done better, but making all Icons in a different visual style will be a good topic for a completely separate project.

On a marigin - bold vs. outlined (thin) icons actually means something. All bold pictograms refers to (a) an Object, (b) the fact that someting is selected. It helps differentiating things with no use of colour.
The discussion about icons themselves should take place in a dedicated topic on Blenderartists. Here we talk about colour codes for the very set.

[Evandro_Costa]

Your “monochromatc” icons have slight dark otuline (shadow?) - that boosts up the contrast - for that reason they’re not mono icons anymore;

This quote got me intrigued…

Mono = one… Chroma = color
Monochromatic = one hue/color, and all it’s value/tonal variations in between, all the way to pure white and pure black.
The definition states that when we are talking about a light-grey color (in the case of the icons), we could also have lighter or darker shades (and also black) and still be a monochromatic palette, because there’s only one hue.

I’m bringing this point because we could have shadows and still be called monochromatic, according to the definition of the word.
Unless we are talking about a single color hue with a single fixed color value. Which is probably called something else that I don’t know.

[jendrzych]

Ok, You’re right. My fault - they’re still mono
Anyway the goal of the very project was to remove outlines and better utilize the gained space, making a bit bigger, better readable icons.
In theory, the GUI engine could draw a dark backdrop “shadow” under each icon - a kind of postpro outline, that boosts local contract a bit. @Brecht - am I right?

[brecht]

It could, though I’m not sure there is enough space inside the button for it.

[jendrzych]

I asked from pure curiosity. Good to know, that such an option is possible - could be usefull with light themes.