It is clear from the start that colors were not chosen with logic in mind. The V6 icon for Eeschema should have the transistor in red; the same as the two resistors in the icon. The traces in the icon should remain the default color for what happens when a wire/line is drawn in the schematic.
I would suggest to change the top resistor to a top capacitor; because it appears that two parallel red lines would fit. Then the schematic icon would show a resistor, capacitor, and transistor all off the same color.
Then make the default color for the body outline of schematic symbols the same color red (or other) in both Eeschema and the library editor.
Change either the transistor in the schematic editor to an OpAmp, or change the image in the symbol editor to a transistor.
Once these changes can be made, a similar approach can be taken to the PcbNew and the Footprint Editor.
ON EDIT: The distinction created by the V6 icon background for Eeschema and PcbNew helps identify that one might be a subset of the other; but it just is not done well at the moment.
ON EDIT: The icon for PcbNew should include a relative white silkscreen layer in it; and also contain at least part of the footprint in the Footprint Editor icon.
Users pick icons largely on colour and shape. After that it has to go to the cerebral cortex which takes a lot longer to process the actual content. This drove our selection of colours more than anything else.
We really just went out to the local zoo with a color palette and placed it in the monkey cage. After a day, we took it out and chose the colors that weren’t covered in monkey droppings. Then, with the colors selected, we removed all of the crayons from a 128-color box that didn’t almost match the monkey-selected colors and brought them into a Pre-K classroom after spiking their morning chocolate milk with two shots of espresso. Each. We then shut the door and waited. The resulting pictures were chosen as our main icons.
I don’t hear anyone calling for the PcbNew icon to change to red on blue, and yet people seem to generally approve of those being the new default colors…
To put what Jeff said in another way: icons are clues/hints at a concept. Sometimes something can seem more consistent but be less useful, because it’s a worse clue.
The transistor is black to avoid there being too much red. The wires are black because green next to red on tan is not aesthetically pleasing, and because we try to limit how many colors are used in any given icon. Making the wires green doesn’t add value.
Another thing that maybe needs to be said explicitly:
It is clear from the start that colors were not chosen with logic in mind.
This is a great way to put everyone on edge and let the tone of your post overshadow its content. If you look around the forums you can find that the icons have inspired far more people to make “helpful” suggestions without trying to understand how we got to where we are, than people actually looking to work with the team to make incremental improvements where needed.
My point wasn’t that you didn’t address it, my point is that it’s a false argument that it is important for the eeschema icon to match the default eeschema color theme. Color is an important factor in icon design, but sometimes it is more important to look at other color factors than “do the colors used in this icon match exactly with colors used for some of the things depicted in the icon in other places”
You are looking for the wrong kind of logic. The icons were designed to fit into a common theme, follow common design principles, and be easy for people to tell apart. In other words, the schematic icon needs to say “schematic” to people and not be confused with the symbol library editor icon, etc. And, it needs to do so while following our agreed-upon design guidelines, for example, not using a wide variety of colors and not over-using “loud” colors like red.
If you had in your original post asked to understand the logic rather than assuming there was none, maybe this conversation would be going in a better direction.
I don’t think it’s reasonable for everyone to perfectly understand the logic behind every decision made in a large project. That requires an enormous amount of context. Requiring it to be clarified does not necessarily invalidate the logic behind the decision.
I think that your argument hinges on the assumption that maintaining complete parity between colour schemes is an important thing. I don’t think that’s valid for two main reasons:
New users who need to make the association between the icon and its function won’t already know what the default colour scheme is.
If we’re trying to match the icon’s style or form with how the users use the program, why are we using a transistor and two passives? I personally spend most of my time in and around medium-sized ICs, so the transistor doesn’t represent how I use it. The icon is being used to bring about an association with generic functionality (“I want to edit an electrical schematic”), not with EESchema specifically, so using easily-distinguishable symbols is more important than matching what the program uses. What works in a 128x128 pixel image isn’t what works in a large schematic.
I would ask why you think that maintaining colour parity between icon and the default colour scheme is an important thing. I think that’s the concept you need to get across if you want to have a discussion around these suggestions, because as far as I can tell this is not a view held by the dev team.
At risk of piling on; perhaps Sprig ought to design and submit a set of icons, and then the developers can either accept or criticize those? Unless Sprig is an iconoclast. IMHO the meaning of the 5.99 icons is sufficiently clear and unambiguous. That is what counts. 1,2,5,7,4, uhhh
That’s a good idea. It’s easier to see if different is better or not if there’s something real to compare.
Personally I’m very satisfied with the current state of the icon set except for the red “warning signs” which is in the issue database and with which several users have agreed.
Those application icons aren’t perfect, maybe something different could be better, maybe not. I haven’t felt they need to be changed. If there’s something I don’t like, it’s the library editors which are a bit boring and don’t resemble the main application icons with which they are related: symbol editor/eeschema and and footprint editor/pcbnew. But I can see the logic behind them.
Remember also the smaller app icons if you touch the large ones.