I will have to be a bit negative here unfortunately, please don't take it personal. Of course a lot of this stuff is highly subjective.

There are a few issues I see here:

• The icons do not feel like following the same icon style to me, even though you tried to do just that. I have no idea really why, they just don't look right to me in the mockups. Maybe they are just a bit too small, or maybe it's something else. I still hope we can get some icon design guidelines from @Andrzej Ambroz (jendrzych), this might help creating more consistent feeling icons.
• They do look smaller than other icons. At least they look hard to read to me, perhaps there are just too many details.
• On a bigger picture, I don't agree on the need for most of these icons. There are good reasons with good evidence for using icons sparingly. @Yevgeny Makarov (jenkm) did a great writeup on that, and I'd like to make that part of our design guidelines. If I look at the mockups, this is the kind of thing we should avoid IMO. What may work fine is (max) one icon per section in a menu, that can be a nice hint for quick scanning.

Also apologies for only replying to this now, I was just made aware of this. I hope you didn't put too much effort into this since making the initial proposal.

In T94370#1341823, @Julian Eisel (Severin) wrote:

I will have to be a bit negative here unfortunately, please don't take it personal. Of course a lot of this stuff is highly subjective.

There are a few issues I see here:

• The icons do not feel like following the same icon style to me, even though you tried to do just that. I have no idea really why, they just don't look right to me in the mockups. Maybe they are just a bit too small, or maybe it's something else. I still hope we can get some icon design guidelines from @Andrzej Ambroz (jendrzych), this might help creating more consistent feeling icons.
• They do look smaller than other icons. At least they look hard to read to me, perhaps there are just too many details.
• On a bigger picture, I don't agree on the need for most of these icons. There are good reasons with good evidence for using icons sparingly. @Yevgeny Makarov (jenkm) did a great writeup on that, and I'd like to make that part of our design guidelines. If I look at the mockups, this is the kind of thing we should avoid IMO. What may work fine is (max) one icon per section in a menu, that can be a nice hint for quick scanning.

Hi Julian, I don't take it personally however this feedback is somewhat unhelpful as it is vague, dismissive, and subjective as you said.

• Which icons specifically do not feel like the same style? Almost all of the elements from the new icons come from existing icons in the blender_icons.svg file
• Almost all of the icons are either 14px wide and/or 14px tall. Which icons specifically do you think have too many details?
• Perhaps it is not a user experience improvement for all the suggested icons, but I feel very strongly that some of these icons provide excellent explanation for some of the menu commands (e.g. Decimate, Jump to Keyframes, Column on Current Frame, Sample Keyframes). Once we get some experience with Blender, these commands make sense, but for new/inexperienced users, these icons can be extremely valuable and inviting to use the application.
• I realize that there are a lot of icons being proposed here, but I humbly request respect for the amount of work that this took by looking at each icon on a case-by-case basis, rather than a blanket rejection of all.

@Julian Eisel (Severin) are your comments on the visual look from only looking at the icons here or in context of using Blender as shown in the video https://developer.blender.org/D14662 posted with the patch?

Reading over the write up on Icon vs. text, I agree that ONLY having icons that alone don't help a user understand something, icon + text, (see the changes to the outliner icons) as reference do help create context and understanding for what an ACTION is going to do when the icon is clear. There are many wording choices in Blender that do not without reading(and even with reading the help or the tool tip, often the tool tip provides better explanation) at first read convey what the end result is going to be.

For artist facing tools like sculpting and graph editing keyframes, etc.. the artists are used to/trained/expect icons to guide them for what they do and if it ONLY allows them to find the tool in the menu faster (a bullet point as described in the great document you linked) then it is a reason to have them. Improve locating and using the tool to speed up something done 100s of times or much more over time means they don't need to read and comprehend, just click and visually they locate the "land mark" icon they need.

Context, expectations, users who use the tools (@Luciano Muñoz Sessarego (looch) @Jason schleifer (jasonschleifer) and other animators should have feedback and input on this as they are the ones ultimately spending the largest % of time in the area of the tool.

I will throw my subjective opinion in the ring here. Most of these icons are very much needed and improve the readability of the menus (they help with visual grouping, something the existing menus struggle with).

However, some of the icons feel like they won't read very well at lower DPIs, and that they're trying to pack too much detail into the small canvas given. Some examples:

• Ungroup Channels
• Before/After Current Frame
• Select All/None
• Rename Marker

Most of the marker icons also have this problem, for example:

The subject icon (marker) takes up the majority of the space, but the action icon (caret, move gizmo etc.) take up about 1/3rd the visual space. In the context of looking at that marker menu then, the majority of the icon space is largely redundant visual information, because the user cares more about the action rather than the subject when trying to visually parse the menu. Perhaps inverting or playing with the size ratios of the subject and action icons would help?

Great work, regardless!

@Colin Basnett (cmbasnett) That is helpful, constructive feedback, thank you, Colin. Here's a new version of the markers using the "KEY_DEHLT" icon for proportion & style reference.

Here's a revisit of the Before & After Current Frame and Group/Ungroup:

I think it's important to understand that a change like this doesn't just apply to the graph editor. As proposed, it actually represents a rather radical change in Blender's UI design.
For example, the selection menu is quite similar to menus in the 3D viewport, UV editor, etc. Adding icons to every operator just in the graph editor doesn't make sense, so it would have to be done consistently.

There are few existing menus in Blender (only the "Help" menu, which we have talked about changing in the past) where every single operator has its own icon.
That's on purpose. Icons are very helpful for scanning lists, locating familiar elements, etc. But when overused, they lose their meaning.
I would suggest (and so does current UI design) that the density of icons in your proposed "Select" menu goes a ways into the territory of "visual noise".

I don't mean that they all don't make sense-- some well placed additions might be helpful, but likely for commonly used visual actions rather than every operator.

Here is some more specific feedback about the designs:

• Line weight Many of the shapes are hard to read at small sizes. Examples: selection icons, channel grouping icons, bake icons
• Small shapes Similar to the previous point, visual elements are often quite small, especially when nested. Examples: camera scaled down to make room for other symbol, scaled down stop-watch, scaled down chain, "Between Selected Markers"
• Visual noise The square dashed line can be helpful to represent "bounds" or "selection", but too many dashes make the shapes harder to read. Examples: selection icons
• Skeuomorphism I would argue that the more literal word-based representations are redundant, and not a helpful visual metaphor, taking away from the other icons by adding noise. Examples: "iron" for smoothing and Euler filter.

I hope that is helpful constructive feedback. I think the icons that fit better are the simpler shapes like some of the marker icons or the jump to keyframe icon.

Thanks @Hans Goudey (HooglyBoogly) ! That's great feedback. I'll take another shot at the designs with these points in mind.

@Julian Eisel (Severin) & @Pablo Vazquez (pablovazquez), I made many changes to these designs over the weekend. I have spoken with @Sybren A. Stüvel (sybren) and he has said the decisions on these icons are yours to make. I am very willing to make changes to the icons, add new icons, or adapt their style to whatever you like. Please let me know what would need to happen for these to proceed. Thank you.

will it be possible to put the icons of the commands in a separate palette +dock them to the interface as a tab to use them as buttons to execute the commands?(like in c4d)

In T94370#1359321, @beate a. (42b3d) wrote:

will it be possible to put the icons of the commands in a separate palette +dock them to the interface as a tab to use them as buttons to execute the commands?(like in c4d)

What you are describing would be a feature request. You can submit your idea here:
https://blender.community/c/rightclickselect/

@Julian Eisel (Severin) , @Pablo Vazquez (pablovazquez), @Sybren A. Stüvel (sybren)

Can you let me know if there are changes that can be made to these icons to meet your team's approval, please?

I think I saw in Blender Chat that the number of the icons make the designs hard to review. Would you prefer for me to break these into separate design tasks, grouped by each Animation menu (e.g. Select, Marker, Channel, etc.)? Then you can decide which ones serve the greatest utility for each menu. Or I can submit each icon individually? Please let me know.

Thank you!