We need to do research on color schemes. #706

Closed
opened 2026-05-04 11:48:05 +00:00 by a22erigr · 4 comments
Collaborator

We need to look over our color schemes. During the presentation we received feedback from the customer whom both hardly could see the content and did not find it appealing. When questioning about the stile guides set by the schools webmaster the customer said it could be ignored.

Based on this, research tools that can be utilized to generate a color-plate that is both appealing and excessive for colorblind people. Also create a guideline on what component should use the

Create a possible new color scheme that take inspiration from the Sapphire color scheme currently implemented.

We need to look over our color schemes. During the presentation we received feedback from the customer whom both hardly could see the content and did not find it appealing. When questioning about the stile guides set by the schools webmaster the customer said it could be ignored. Based on this, research tools that can be utilized to generate a color-plate that is both appealing and excessive for colorblind people. Also create a guideline on what component should use the + Primary color + Secondary color + Accent + Possible tools that should be research + https://www.accessibility.build/tools/color-palette-generator + https://m3.material.io/ Create a possible new color scheme that take inspiration from the Sapphire color scheme currently implemented.
Collaborator

I did some research and here are my propositions:

  • Colors should be used sparingly. This is to direct the users attention to "where it should be looking", e.g. interactive parts, such as buttons. Thus most parts of the page, such as the background and cards, should be in neutral colors.
  • Primary color should be used for the primary actions, like add card and maybe the hamburger menu in the tool bar. Secondary color should be used for "less important" stuff, that is still interactive.
  • For high contrast, use a darker hue as primary in light mode. Text on this button should be light. This is for maximum contrast, and does not have to be followed exactly.
  • Using complementary colors as primary and secondary is also good for creating contrast on the page.

Here's how I propose we implement it using the current system:

  • In the theme.css file, the root class already has variables for primary and secondary colors, as well as hues of them for things such as hover, that are used for the buttons. We could use this structure for the different styles, instead of having --color1, --color2, and so on.
    image
  • For maximum ease of use, these colors (--primary, --secondary, --primary-hover and so on) should include colors for both dark and light mode, so that this responsibility does not fall on developers of components.
--primary: light-dark(#465106, #98b00c)
  • Regrettably, removing the previous color variables will mean a lot of the components will have to have their css changed, but I think this is the right decision for the maintainability of the app in the long run.
  • Color variables that stay the same across themes, such as hues of gray used for background etc. can be placed in the root class.
  • The card specific variables in the style data sets could be removed, if we decide that cards always should have the same color. They were added with the idea that whole cards should change color with different styles.
    image

These are just my suggestions

Key takeaway

  • I think that the current style data sets should be modified to contain variables for primary, secondary and accent colors, as well as different hues of them for eg. hover.
  • These variables should then be used sparingly in components that we want to direct the users attention to, such as the primary action buttons of the page.
  • The component specific variables, like the ones for the login component, should be removed from theme.css
I did some research and here are my propositions: + Colors should be used sparingly. This is to direct the users attention to "where it should be looking", e.g. interactive parts, such as buttons. Thus most parts of the page, such as the background and cards, should be in neutral colors. + Primary color should be used for the primary actions, like add card and maybe the hamburger menu in the tool bar. Secondary color should be used for "less important" stuff, that is still interactive. + For high contrast, use a darker hue as primary in light mode. Text on this button should be light. This is for maximum contrast, and does not have to be followed exactly. + Using complementary colors as primary and secondary is also good for creating contrast on the page. Here's how I propose we implement it using the current system: + In the theme.css file, the root class already has variables for primary and secondary colors, as well as hues of them for things such as hover, that are used for the buttons. We could use this structure for the different styles, instead of having --color1, --color2, and so on. ![image](/attachments/ddb93ffa-b8de-4e33-9ec2-03fbd6163766) + For maximum ease of use, these colors (--primary, --secondary, --primary-hover and so on) should include colors for both dark and light mode, so that this responsibility does not fall on developers of components. ```CSS --primary: light-dark(#465106, #98b00c) ``` + Regrettably, removing the previous color variables will mean a lot of the components will have to have their css changed, but I think this is the right decision for the maintainability of the app in the long run. + Color variables that stay the same across themes, such as hues of gray used for background etc. can be placed in the root class. + The card specific variables in the style data sets could be removed, if we decide that cards always should have the same color. They were added with the idea that whole cards should change color with different styles. ![image](/attachments/425ecc10-0706-40fb-aceb-52348220f377) These are just my suggestions ### Key takeaway + I think that the current style data sets should be modified to contain variables for primary, secondary and accent colors, as well as different hues of them for eg. hover. + These variables should then be used **sparingly** in components that we want to direct the users attention to, such as the primary action buttons of the page. + The component specific variables, like the ones for the login component, should be removed from theme.css
Collaborator

Good research and the guidelines for how colors should be used for primary, secondary and accent are explained well. I also agree with the focus on accessibility and contrast like using more neutral backgrounds and stronger colors for important actions.

However one thing that could be improved is adding a concrete color scheme inspired by the Sapphire theme using one of the provided tools as no example is currently provided.

Good research and the guidelines for how colors should be used for primary, secondary and accent are explained well. I also agree with the focus on accessibility and contrast like using more neutral backgrounds and stronger colors for important actions. However one thing that could be improved is adding a concrete color scheme inspired by the Sapphire theme using one of the provided tools as no example is currently provided.
Collaborator

Here is an example of how a color scheme could look. I generated the colors with https://www.accessibility.build/tools/color-palette-generator with complementary color harmony setting and chose the darker hues for light mode and lighter for dark mode. I tested the contrast with https://www.accessibility.build/tools/contrast-checker.

[data-style='sapphire'] {
	--primary: light-dark(#042d49, #25a1f4);
	--primary-hover: light-dark(#031e30, #86cbf9);
	--secondary: light-dark(#01476c, #f47825);
	--secondary-hover: light-dark(#301503, #f9b486);
	--danger: #dc2626;
	--danger-hover: #792222;
}

I'm thinking if we should have the danger/accent color be the same across all color schemes and dark and light mode, to make it as clear as possible. This is just a suggestion though. If so, its variables would not need to be in the selectors for the color schemes, but could be placed in root. To be noted is that the current danger color does not meet the highest standards when it comes to contrast, especially in dark mode.
If we want the neutral background colors to change as well, their variables would be placed in the selector as well.
A variable for --text-base could be added to the selector as well, if we want to change the text size for that specific color scheme.

image

Here is an example of how a color scheme could look. I generated the colors with https://www.accessibility.build/tools/color-palette-generator with complementary color harmony setting and chose the darker hues for light mode and lighter for dark mode. I tested the contrast with https://www.accessibility.build/tools/contrast-checker. ```CSS [data-style='sapphire'] { --primary: light-dark(#042d49, #25a1f4); --primary-hover: light-dark(#031e30, #86cbf9); --secondary: light-dark(#01476c, #f47825); --secondary-hover: light-dark(#301503, #f9b486); --danger: #dc2626; --danger-hover: #792222; } ``` I'm thinking if we should have the danger/accent color be the same across all color schemes and dark and light mode, to make it as clear as possible. This is just a suggestion though. If so, its variables would not need to be in the selectors for the color schemes, but could be placed in root. To be noted is that the current danger color does not meet the highest standards when it comes to contrast, especially in dark mode. If we want the neutral background colors to change as well, their variables would be placed in the selector as well. A variable for --text-base could be added to the selector as well, if we want to change the text size for that specific color scheme. ![image](/attachments/a2ad6596-ec41-4cd4-9454-41e299742c4c)
110 KiB
Author
Collaborator

A decision about this has been made

A decision about this has been made
Sign in to join this conversation.
No milestone
No project
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Andras/BoundlessFlowCampus2K#706
No description provided.