New icons in nightly

I like that dice cube metaphor. The FreeCad one is smarter

And it’s already in an open source program. I even think KiCad’s 3D viewer uses the same libraries as FreeCAD.

1 Like

KiCad uses the same? library (Open Cascade?) that reads and processes STEP files, a part from that, each project has its own render code.

Duplicate and copy suggest gray = old, blue = new.

Also see the old Create Array icon here:

So… it’s odd that “create array” looks more like “select one of multiple identical items”. Maybe that’s just me, but I think the colors are the wrong way round and the size difference also isn’t doing it for me.

image

Maybe something like this is more array-y?

imageimage

Creating the .svg was pretty easy:

array
with more white border:
array(2)

1 Like

Two observations:

  1. A single extra color in an icon might be helpful, depending on how it is implemented.
  2. Two extra colors in an icon is confusing.

By “Extra color” I mean using a hue that isn’t used by the other icons.

This is all theoretical, since I have not yet tried any of these icons in operating kicad.

The icon set is slowly (or not so slowly) but steadily going from pretty good to very good. There’s only one big gripe for me, the red “warning signs” which has been mentioned several times. The rest are small details.


I don’t know why I pay so much attention to the normal/dim non-active layer icon, but it annoys me because the blue color is so close to gray that they look like continuous color tracks with a slash on top of them. It would work better if the two blue tracks were replaced with brighter colors and the gray with lighter. They don’t need to be the B.Cu color because the icon is for all layers, not just copper.
image


Fill all and Unfill all icons aren’t compatible with other zone related icons.
image


“Fabrication outputs” main icon is messy, it doesn’t seem to represent anything concrete or abstract.
image


Hotkeys is probably meant to represent a keyboard but doesn’t look like one. Just plain dull keyboard might be better.
image


And then the red warning signs.
image
image
image
image
image
image
image

… and some others.
First, there are some where the small sub-icon isn’t clear. These are at least:

  • The link icon which looks like a tilted ninja smiley. The ninja’s eyes don’t look like intertwined chain links at all like links in all other icon sets do (compare with the link in this forum’s edit window).
  • The magnifier on the footprint. Its handle can’t be seen properly. And red isn’t good for a magnifier.
  • The pen. It looks like a line and dot, not a pen.
  • The eye. It’s much smaller than the eye in the Appearance panel and doesn’t look so much like an eye especially with the red color.
  • The “new” plus+X icon. It doesn’t remind me of the original idea of shining of new (which is usually yellow in icons). I couldn’t tell what it is unless I knew.

Some would be better with a different color. Why not use for example green for all import/export/add balls? And toned down orange instead of red for some others. The reasons for using different colors have been said already: red looks like a warning sign, it draws too much attention; the icons could be differentiated by different colors; and red just isn’t fitting for some ideas which the sub-icons represent.

4 Likes

What makes the red warning signs issue particularly terrible is that it puts what is important to discern onto 20% of the icon area, while the repeating part that one can sometimes even infer takes up the remaining 80%. They’re obfuscating, not clarifying.

Just as a thought experiment, I imagine one could put a little B/W symbol in the top-left corner and dedicate the majority of the icon to what it actually means.


Given the number if warning sign symbols… I suspect we’ll be victims of “it is this now forever”, aka too big to redo.

Another aspect perhaps previously recognized is a severe limit in feature size:

image
vs.
image

The line width needs to be like that in the arrows, the “+” + “x” symbol isn’t doing it.

Has anyone tried the inverse: using white circles with red symbols in them?

module_filtered_list module_filtered_list

Ok… that doesn’t work so well. To me it seems like a detail of the parent icon is highlighted.

We’re first working on the toolbar icons that are visible on all platforms. Once we are happy with those and they are not changing anymore, there are all the icons that only show up in menus (on platforms where that works, and when users have the “icons in menus” enabled). There are many more of those icons, and they are less important since they show up next to text. So, we are not prioritizing keeping them “up to date” with changes while the changes to the overall design language are still ongoing.

1 Like

What do you think about these annotate icons? (added small gap to make ?? -> 42 more distinct and replaced the red arrow with a constrasty black downward triangle).

before:
image

.png
image

.svg
annotate annotate(2)

Un-annotated parts only have one question mark, not two.
A bit more space between the “R” and the question mark does make it more readable.

You have to be careful about the “R42” text. Readability suffers if it’s to close to the sides of the blue rectangle.

1 Like

Totally agree that the round red traffic signs obfuscate more than they clarify, which I reported a week ago on gitlab

There are a lot of pink “Traffic signs” on icons. These are much to big, which obfuscates the underlying icons too much. Also a circle with some symbol (arrow, cross, question mark, etc) in it is double.

I suggest to remove the circle completely, and instead put the arrow, cross, question mark, etc in a contrasting color.

Source: https://gitlab.com/kicad/code/kicad/-/issues/6668#note_464274000
In the meantime #6668 has been closed, and I don’t know how to interpret that.

[Edit] To be fair: A lot of the red traffic signs have already disappeared. Some I remember were the star on the “new Footprint” Wizard in the Footprint editor, and the “add symbol” opamp icon in Eeschema.

Thanks. Regarding #6668, I understand it as “work on the main / control panel icons” is considered done. We may need to rescue / break out some insights and issues that are in there.

I agree that the red/ping overlay icons can be improved.

  1. The overlay icons are not consistent. Some of the icons are “positive” (star, gear, magnifying glass) drawn in red/pink, while other (majority) are “negative” drawn as white on red/pink background.
  2. Seeing red/pink circle is causing me to associate with trouble/attention. Now this might be just me and my brains, but in EU traffic signs with red border are used to communicate prohibition/warning (Not to mention dropbox/tortoisegit overlay icons in Windows file explorer)
  3. The “negative” icons also have less available area. If they would be drawn in “positive” sense, they would have more area and would be more plain/distinct.

what worries me about that is that depending on whether the icon is shown in firefox or exported from inkscape (0.92.5), it looks different.

As for “??” vs. “?”

annotateI2

.svg
annotate(3)

I’m tempted to vote for “artistic license” in this case and keep the “??”. Input / opinions welcome.

Why? Going from 2 to three characters is an extra visual clue that something is being added.

Also, I’ve decided I like the red better than the black, because red fits better with the rest of the theme. (orangy) red is used throughout the theme to indicate changes.

Another idea:
Remove the arrow altogether, and put the “42” in red. The text could then be a bit higher, which might improve readability, and it also signifies better what is actually changing.

I really liked the “123” text on the old icon (KiCad V4 I think) which got changed to a simple red line.

here’s what the red triangle would look like…
png annotate(4) svg annotate(4)
one advantage I see here is that the red doesn’t pretend to be part of the upper component as much.

ViewCube: A 3D orientation indicator and controller

Our experimental results indicated that
users prefer and are twice as fast at using the ViewCube with
dragging (to perform orbit operations with view snapping)
compared to the ―single click based‖ view switching techniques.
Also, by making the scene orientation always visible via the
ViewCube as a proxy for the 3D scene, we make visible the effect
of other application tools including ArcBall functionality. We
found no significant performance effects of varying the
ViewCube’s labeling schemes (using text, 2D graphics, a 3D
proxy model, or no labels) but to facilitate collaboration we
believe text labels are most beneficial.

1 Like

The problem with ViewCube is AutoDesk patented the dumb thing.

https://patents.google.com/patent/US20130332889A1/en

Legally dubious for KiCad to include it.

1 Like

ugh… classic. So it could almost be that with earliest patent listed as 2007-03-28, this is one of the first publications after the fact. Everything is poisoned by patent law ^^

I’ve been thinking about the cubes a bit,
image

Currently, the icons look like these fellas:

axis3d_front

and a proposal from above to make the backgrounds more distinct, avoiding the look of 60° rotations image
but not fixing the “right = right, left = front” conflict.

Now one could rotate the cube slightly and test orthographic vs. perspective projections to end up with something functionally equivalent to the old (v5) icons.

Here’s a rough sketch of planes looking down into a wireframe cube (l-to-r: back, left, bottom, right, top, front)

image

So what could we do about these six icons?