Made a simple test here. Not something accurate. But you can get the idea about peripheral vision… If you focus on one monochrome icon, you cant distinguish the other icons that are out of focus… With color its easier to diferentiate… You will probably move your mouse faster to the icon you have already identified the color, even while focusing on another place. Take a look at one example… Color is not the main thing, but its a hint… I liked the idea someone presented…
Black: Background, Overlays,
White: Neutral color
Blue: Selected tool, or Z axis
Green: Editing tools, Mesh data, or Y axis; Animated property
Yellow: Keyframe on selected object or property on current frame
Orange: Selected object, active object
Red: X axis, (material data and lamp data in Outliner)
There is the location thing… you memorize location too… But IDK… Just a thought.
If we have colors, we need some parameters, that would minimize the amount of colors and help us to distinguish different categories of icons… it could be just a simple detail… not an entirely colored christmas light… icons with colors need to be pertinent… like the one I mentioned, referring to vertice, edge and face selection…
I like the two color idea because it isnt too colorful or busy. How will the customization work? Will there be a color option for the primary and secondary color so it will work with themes and allow users to make icons monochromatic if they please?
Any news about the vertical layout of the icons in the right panel? To me is pointless to have done such a great job shrinking space and then still have horizontal icons that needs to be middle buttoned. What do you think about it?
Pretty sure i’ve read earlier it’s being worked on. Just guessing it’s no trivial change, so changes like adding some padding to said properties icons are probably in the same queue.
@Endoperez made a good example of categorizing data by color, @rawalanche made a cool job avoiding full colorization of the icons: can we have a mix of these two coloring styles?
Visually, it looks more interesting than just pure white, but as @Antaioz points out, it’s just a sea of two colors now, there’s color for the sake of color.
I agree, something along the lines of these two, where colors serve a function, but also maybe only partially colored could be cool. Just for reference, @Endoperez’s post being referring to is this one.
It’s a tough subject, I think jendrzych follow his vision, that is BTW completely different from the previous ones, I respect that and also the tremendous amount of work putted into these icons. Also while “he is doing it for himself” he is also very responsive to feedback and improvements, as long as it’s aligned with his initial vision.
As you said, doing things for ourselves is IMO the main motor in opensource, at some point if he follow every comments or do survey to look for what the majority wants it then go into a lot of more work.
Does dev fund should go into improving icons or stick to bugfix or projects like override, UDIM, Criptomatte, Opensubdiv… At this point what most users want is not really clear .
I’m sure if someone step in and propose a two color variant of jzendrych work maybe dev’s will look into it if that make sense. I think this is where community can step in, I’m fine with the new icon set, with some theme adjustment I don’t think it will make me work slower or confuse me when I use blender, to the contrary I generally find them way more clear and informative.
I think I’ll amend my proposal slightly to make it a bit easier to put in place earlier but leaves us with more flexibility later…
Right now these new monochrome icons can be drawn in any single color. So the total luminosity of each icon pixel is used when drawing them in arbitrary colors. I think that code should just be altered to deal with each channel separately in turn.
What I mean is that the icon-drawing code can take parameters for three different colors. Then it can use the value of the red channel of the icon to draw it in the first color, then use the value of the green channel to draw the second color on top, followed by the value of the blue channel for the third color on top of those.
Then we can take the icon SVG source file and add layers to support this scheme. Background parts of the icon output red, “foreground” parts in green, and “highlight” parts in blue. “Background” would be the majority of each icon. “Foreground” would be different parts that can be (optionaly) colored differently just for visual effect (so the mountain in the layers icon). “Highlight” parts are those minimal parts that require distinction, like the selected parts of the component selection icons.
This would require minimal code change, requires minimal change to the icons, and does not require creating a second PNG file from the SVG. But by breaking up the icons into three different classes we should be able to support, though themes, everything we have so far discussed. Use the same color for all three parameters and we’d have the current single-color icons. We could add a highlight color for just the component selection icons. We could every single icon look different if we like. We would have the flexibility to make everyone happy…
All Modifiers became flat and monochromatic. I’m not so pleased with all items design - not especially happy with Warp, Shrinkwrap and Displace icons for instance, but on the other hand they’re good enough for the time being.
By the way I made tons of tiny fixes based on the comments of the community and repairing some of the little things that irritated me. The biggest of them are:
the change in the icon of Weight Painting, which instead of bone has a dumbbell now and is semantically compatible with the Vertex Weight modifier pictogram:
modification of Selection Modes and Snapping Target icons:
correction of icons with two or more states, improving the contrast a bit and strengthening the difference between ON and OFF state:
I’m not completely sure about the modifiers. If/when we add node-based modifiers, it may be futile to make icons for each node type. But we can cross that bridge when we get to it. Ideally, for consistency we’d also have icons for all the constraints, but that seems very laborious. I think we can do without.
Note that we will likely need a new icon. We plan to split the UV/Image Editor into a UV Editor and Image Editor. These then need different icons.
Do you plan on getting rid of the current layered-based modifiers system once the node-based modifiers system arrives?
Would be nice to keep both systems. If the layered system will stay then those icons are still safe…
That’s actually the problem I am talking about. He has a vision of what the icons should be like, it’s a vision that works for him, and he’s going to pursue that vision regardless of how many people point out there are usability issues with it. Which is perfectly fine for him, but it is not fine from the perspective of the Blender Foundation making an official release.
Say, for example, I wanted to make an icon themed on teddy-bears. In that case, it’s perfectly reasonable for me to ignore feedback from people saying that teddy-bears are not a great theme for basing Blender’s iconography one - it’s my vision for my work. On the other hand, it would be far from OK for the Blender devs to make that the official iconography in the official distribution. Same principle involved.
It’s not just the “don’t change my Blender!” crowd pointing out that colour helps differentiate icons from one another. Changes should always be made for the better. We should replace the iconography of the application because the new set is BETTER not just newer/cooler. Right now, as any honest comparison of blurred UI images above would tell you, the new icons look cooler but they are not better at their job.
First I should say that I am among the people who absolutely love Andrzej’s icons. But what I think this discussion is showing us is that we are all different. It is very possible that each of the opinions here are valid in that our brains are wired to look for different things. For some adding color adds noise, and for others it is necessity. I don’t anyone is wrong for preferring monochrome, versus colored, versus assorted, etc. Our brains just vary.
But it is difficult to say the next thing and word it correctly. Despite me loving the icons, and personally thinking he is doing a wonderful job, he is also the best we have. Things like icons need to be made with one unifying vision in order for them to be consistent. I just don’t see anyone else stepping up to make a complete set that comprises hundreds of matching icons.
So I think we have to imagine this job the same way Andrzej does. It is a labor of love done by one guy in his spare time and comes to us as a complete package. It will, of course, come with good points and bad, but I think we have to accept all of it at once or not. If we had someone else interested in making icons we would probably have to accept those in the same manner, but we’d then have two selections to choose from.
That said, I think it is reasonable to look for ways to use these icons in a way that satisfies Andrzej’s aesthetic but also gives the option of displaying them as others prefer. As long as it doesn’t substantially change his icons, create more work for him, nor make updates more difficult. I’ve tried to do that with proposal above, where the icons are separated into different classes that can be recolored at will.
“Call for content: Icons” is what BF should’ve done (and still can), with full guidelines from the start, and all this panic would be avoided. And I’m pretty sure we would have plenty of icons to choose from.
You don’t need a call for content, it’s open source software after all, you’re free to cooperate whenever you want. No offense, but you either put up or shut up.
I can hardly see anyone putting in all the effort and hard work jendrzych has already done for free, let alone having a full working consistent icon set like his.
