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.
We didn’t care much to keep colors matching the schematic editor as v6 now has fully configurable color themes so theres going to be alot of variance once users start playing with them
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.
I already spent quite a bit of time on the weirdness of the symbols, so I intentionaly did not address the color of PcbNew.
However, I think that the color green for PcbNew is just fine, and that the 3D viewer should default to green soldermask; as green is the typical standard color for most board houses.
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”
The comment was made because I believe it to be a true statement. Followed up with my opinion on what I would expect to find inside the box after seeing the advertising on the outside of the box.
I notice that none of the replies so far have made a good argument as to why they make logical sense. Where is the half black and red transistor in the default libraries?
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.
You are always welcome to suggest changes, but it seems like you still are saying that our logic is invalid, rather than just different from your logic.
If you intend any suggestions as actual contributions rather than just mock-ups for discussion, please check out the icon design guidelines
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.
If https://gitlab.com/kicad/code/kicad/-/issues/6707 gets implemented it can make these kinds of threads less necessary. Especially if icon sets can be integrated to asset manager. At least there would be less need to require upstream changes, and testing propositions would also be easier.
