UI/UX Color Palette Analysis - A continuing research project

[obelisk79]

Ok, so an update with all of the color changes I will be submitting a PR for.

*note* modifying what I consider the 'classic' colors of FreeCAD is no easy task. I doubt this will be perfect and/or make everyone happy, however I have done the homework and genuinely believe these changes will be an improvement for everyone. If these go live, and there are distinct issues related to color that I wasn't able to address beforehand, let me know and I will do my best to quickly resolve it.

Kind Regards,
Joe

PS. The image is the old colors, new background and new background with tweaks. Look at the improvements in overall color contrast ratios, spreadsheet included with all of the colors in separate tabs. The columns for Gradient 1 and Gradient 2 indicate the best and worst contrast possible given the selected colors.

bitmap.png (715.04 KiB) Viewed 1034 times

[onekk]

Why not trying to make such bug changes now. (after summer break probably as some developers are busy or on summer vacations).

An unified color palette limited possibly to 24 color as it seems a realistic color blind limitations from the reading I have done seems a good starting point, probably trying to discuss about:

Using Sketcher colors as a base as they are the most high in variants and find some names like:

- draw_clr used for general drawing
- sel_clr used when selecting things
- ok_clr used as example for full cobstrained sketches
- bad_clr or err_clr
- warn_clr used as example for over constrained sketch (or better to mark it as 'bad'?)
- cns_clr sketcher construction entities

to distinguish them based on general names and not "destination names"

Reusing these general names for other WB as it seems that there are near duplicates in colors and memory is limited to catch every combination, so it wil be a mnemonic exercise to remember all the color names (usually over 10 or 11 you have to find some mnemonic tricks, it is not a case that popular enumerations are limited to ten or groups of tens)

4_3 seems a reasonable limits for color designation names, but is only an idea.


Next step would be to implement this change in Sketcher that seems the most used and problematic piece of FreeCAD where colors are used extensively.

And ask other developers to use one if the chosen names to be consistent in source code.

@obelisk79 great and deep job, for what it count from a normal user like me.

Regards

Carlo D.

[obelisk79]

Update #(I've lost count at this point)

Ok, so I've narrowed down out of 130 colors from the open color palette, 40 colors that have acceptable contrast across a proposed light theme gradient and proposed dark theme gradient.

The following spreadsheet images may be difficult to discern what's going on. But of note, WCAG contrast guidelines struggle to evaluate color contrast against light backgrounds. APCA really handles this better.

image3.png (351.21 KiB) Viewed 941 times

image2.png (33.34 KiB) Viewed 941 times

image.png (36.61 KiB) Viewed 941 times

[obelisk79]

@paddle @Roy_043

Any distinct issues with the mock-ups just above?

You can ignore 1-10 that is just a full range of gray that I intend to leave largely untouched. I will be cutting the array of colors down as well.

[paddle]

I can see all the colors clearly on the dark background and light background.

Though it seems that all the colors are too light for the light background, ie the contrast is not high enough. Maybe the colors need to be darker in the light mode. Though they are still visible.

One note is that to my eye the 35-36-38-39 all look pretty much identical. Also 32-33-37-40.
Btw have you seen this : https://davidmathlogic.com/colorblind/# ... -%23004D40
There are a list of palette that are very colorblind friendly (Tol, Wong, IBM)

[obelisk79]

...

Thanks so much for the feedback. I had the same thoughts about the light but I had really hoped that I'd be able to get away with the same set of colors with both light and dark. Technically that was the case, but I agree that it was not dark enough on the light gradient. I've made some adjustments to both background palettes and also reduced the number of colors significantly.

light.png (18.67 KiB) Viewed 850 times

dark.png (19.49 KiB) Viewed 850 times

[kadet]

First of all - that palette looks great and seems really fitting for the overall design, it will hugely modernize FreeCAD experience. But I'd like to give my few cents to that topic as I've got some background from web design with respect to WCAG standards.

Regarding contrast - remember, that contrast that is required for element to be clearly visible depends on element size, thickness etc. For small elements (or very narrow ones like 1px lines) required contrast should be larger, for larger ones it'd work even with relatively small contrast ratios. Also as each color from 11 to 22 has different hue (and thus could convey different meanings to user) it'd be nice to provide at least two variants for each of colors: lighter one (could be used for mouse hovers), darker one (could be used to differentiate selected piece from not selected).

As for the colors - for web we often pick few color kinds:
- Brand / Accent Color - color that user will connect with our service
- Primary color - often to the value same as brand color, but should indicate primary actions on site
- Functional colors - Positive (greens), Negative (reds), Warnings (yellows), Informational (often blues)
- Neutral colors - mostly shades of gray or other non-saturated colors, often used for backgrounds and elements that should not distract user - often on the scale from clearly visible to barely visible.

I don't think that brand and primary colors are applicable for the CAD program design, but functional colors and neutral colors surely are. For the design system I think that FreeCAD would benefit from "layered" color systems based on tokens (inspired by design tokens).

Your palette would be the first layer - primitives - the only one with explicit values. It could look like this (CSS variables):

Code: Select all

:root {
    --color-1: #ffffff;
    --color-2: #bdbfc1;
    ...
    --color-11: #f85151;
    ...
    --color-22: #cf6c1a;
}

Then we could define the next layer, that has a little bit more semantic meaning - neutral and functional colors.

Code: Select all

// for dark theme
:root {
    --color-neutral-1: var(--color-1);
    --color-neutral-2: var(--color-2);
    ...
    --color-neutral-10: var(--color-10);
    
    --color-foreground: var( --color-neutral-1); // stands out most, could be different, explicit, value
    --color-background: var( --color-neutral-10);   // could be different, explicit, value
    
    --color-positive: var(--color-20);    
    --color-negative: var(--color-11);
    --color-warning: var(--color-21); 
    ...
}

That'd ensure that colors will be consistent across UI. Order of colors should stay the same for light and dark theme variants, but exact values could change a little bit to adjust for the required contrast. For neutral colors we could only swap order of the used colors, without touching lower-level tokens.

Code: Select all

// overrides for lighttheme
:root {
    --color-neutral-1: var(--color-10);
    --color-neutral-2: var(--color-9);
    ...
    --color-neutral-10: var(--color-1);
}

Then if we are designing for example grid we should use some even more specific tokens:

Code: Select all

:root {
  --grid-major-color: var(--color-neutral-4);
  --grid-minor-color: var(--color-neutral-6);
}

Thanks to this when designing we only care that major lines should not stay out (and that's why we use neutral-4 color, which could be different for various backgrounds but should have roughly equal contrast to background in both cases) and minor lines should be less visible than major lines by two "levels". And designer does not need to think about exact color values or if it will be used on light or dark background;

Or in case of solver status in sketcher:

Code: Select all

:root {
  --sketcher-under-constrained: var(--color-informational);
  --sketcher-fully-constrained: var(--color-positive);
  --sketcher-over-constrained: var(--color-negative);
}

Then again designer does not have to think which color to pick because over constrained sketch has clearly negative value for user and should be fixed.

Some other quite good references in my opinion:
- https://m3.material.io/styles/color/the ... lors-tones
- https://m3.material.io/foundations/desi ... s/overview

[MisterMaker]

I just blatantly de-saturaized all the color by 60% using the Color fetcher macro and this website and ended up with this

desaturized.cfg

(62.37 KiB) Downloaded 8 times

:



I kinda like it although it is missing some "fines" to it.

[tonyaimer]

Not sure I can or could contribute anything of value to this very valuable discussion.

As long as we are not forced into a dark theme I don't mind.

I prefer the light themes in most software I use but I do understand most folk preferring
a dark theme.

That's not even 2c but might be 1c

Regards

Tony

[obelisk79]

As long as we are not forced into a dark theme I don't mind.

That is not going to happen. Light vs dark theme preference varies from person to person. Personally I prefer dark themes, I also work in lower light environments where such themes tend to be easier on the eye. Understanding that there is a difference means there will be both light and dark themes available.

There will and should always be a choice.