You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Infinitely configurable accent colors are a problem for compatibility with light/dark theme for core UI elements (hyperlinks, buttons, headers, labels)
#2297
Open
nekohayo opened this issue
Jan 7, 2025
· 1 comment
I was wondering why I was still experiencing #1356 today with the latest paid SaaS v5 version, and I discovered that the too-dark-to-be-visible blue color in dark theme on my end was controlled by the user-settable single accent color in https://app.invoicing.co/#/settings/user_details/accent_color ; but if I set it to a lighter color, then when I switch to light theme I will have the inverse problem. This currently affects all hyperlinks, buttons, table headers, tab switchers above a table, etc.
With a single user-set color, either the colors are unreadable in light theme, or they are unreadable in dark theme, and it's a pain in the butt to change that setting (and the dark theme switch) because InvoiceNinja's UI prompts you for password confirmation privilege escalation every time you want to change any of those two settings.
I don't think the current approach can work, especially in the ideal future context of automatic light/dark theme switching (#1359).
Suggestions
My suggestion: kill the configurable accent colors and hardcode pairs of colors that work in light and dark themes no matter what. Or at least, limit the accent colors to a specific palette of well-tested color pairs, not millions of possibilities. Particularly when it comes to task status colors, each color in the palette should have a light vs dark variant.
Alternatively, you could offer the user to choose a pair of light and dark accent colors themselves (or try to mathematically "guess" what the user intended to adjust the color depending on the context), but I don't believe that's what "average joe" users want/need. I'd much rather want your app's theme to be opiniated and to use hardcoded colors that have been tested to work everywhere 100% of the time.
The text was updated successfully, but these errors were encountered:
Problem statement
I was wondering why I was still experiencing #1356 today with the latest paid SaaS v5 version, and I discovered that the too-dark-to-be-visible blue color in dark theme on my end was controlled by the user-settable single accent color in https://app.invoicing.co/#/settings/user_details/accent_color ; but if I set it to a lighter color, then when I switch to light theme I will have the inverse problem. This currently affects all hyperlinks, buttons, table headers, tab switchers above a table, etc.
With a single user-set color, either the colors are unreadable in light theme, or they are unreadable in dark theme, and it's a pain in the butt to change that setting (and the dark theme switch) because InvoiceNinja's UI prompts you for password confirmation privilege escalation every time you want to change any of those two settings.
I don't think the current approach can work, especially in the ideal future context of automatic light/dark theme switching (#1359).
Suggestions
My suggestion: kill the configurable accent colors and hardcode pairs of colors that work in light and dark themes no matter what. Or at least, limit the accent colors to a specific palette of well-tested color pairs, not millions of possibilities. Particularly when it comes to task status colors, each color in the palette should have a light vs dark variant.
Alternatively, you could offer the user to choose a pair of light and dark accent colors themselves (or try to mathematically "guess" what the user intended to adjust the color depending on the context), but I don't believe that's what "average joe" users want/need. I'd much rather want your app's theme to be opiniated and to use hardcoded colors that have been tested to work everywhere 100% of the time.
The text was updated successfully, but these errors were encountered: