Frontend: Accent Colors

[SeanPM5]

Problem: Themes aren't user-friendly

1. Themes aren't easy to discover. There isn't a nice theme gallery with thumbnails, search/filters, and user ratings or anything like that. You have to click some link to the docs and then find a link to the community forum on that page, and then browse through forum threads.
2. Themes aren't easy to install. You have to copy and paste YAML into a text editor, make sure it's under frontend: and that everything is indented properly etc. Then you either have to restart or call the frontend.reload_themes service.
3. Themes aren't easy to make. There's no official list of variables (yet), and no official theme creator yet.
4. Themes aren't always stable. They break (and will continue to break) as variables change. Some theme authors are good at keeping up to date, others get sort of abandoned. Often fixes are shared by community members in the replies, but original post doesn't get updated, so unless you read two years of replies to that forum topic you'd unknowingly be using an outdated theme with issues.
5. Lastly there's other confusing aspects like the whole "Backend-selected" thing.

This stuff isn't too hard for people like you and I who update regularly and follow changelogs etc. Anybody that's reading this post is more of an advanced user. But for normal, regular people it's too difficult - there's absolutely zero chance that your parents could figure this stuff out for example.

Solution: Accent Colors

macOS, Windows, and the latest version of Android have this concept of accent colors. Popular websites like Twitter and Tumblr also have this when you customize your profile on those sites.

There'd be maybe like ~10 curated colors that look good and provide variety. User clicks on a color and it'd change the header background, hyperlinks, toggle switches, input sliders, buttons, etc to that color. Here is a mockup of how this could look on the profile page:

You'll notice a color wheel button here too. This allows the user to select literally _any_ color and not just the predefined ones. Everyone is familiar with this already since that's how you change lights in Home Assistant. As you move the wheel, the theme would be updated in real time.

Clear benefits to this approach. It's literally one click to customize your theme, it doesn't require any text editors or YAML, it's so simple there's no documentation needed, it will always look good, it won't break or have issues.

What happens to themes?

Themes won't go away, but would now fall under the "Advanced mode" umbrella. This better aligns it with the Home Assistant 1.0 "Simple mode" vision:

No YAML
Simple mode will be fully controlled via the UI. No features should be exposed that require users to open a text editor. For example, a config flow that requires a user to add client_id/secret to the configuration.yaml should not be part of simple mode.

It's a safe assumption that almost everyone using themes today is familiar with YAML and would have advanced mode toggled on, so there's really no change for existing users.

---

If there isn't any opposition to this proposal, there's still a few things that need to be figured out. How would this be handled in the card editors? If a user has advanced mode on and it shows both "Theme" and "Accent Color" options, which one gets priority / how is that handled? etc.

[Dino-Tech]

Suggestion: Since pretty much every app is offering a dark and light mode themes and the popularity of dark theme demands have been increasingly growing, this would be a great option as well for HA as we are looking toward the future. 2 different HA base theme structures with the correct text color variables to be visible on every text field combined with the accent color choices seems like a win/win.
Having 2 main themes, dark and light, could serve as a 'backbone' for creating themes and tracking variable changes, etc. This would help those of us who like to be creative and share with others our themes, keep a consistency among old and new users alike.

[SeanPM5]

Couldn't agree more @Dino-Tech. An official dark theme is something I've personally wanted for a long time. Previously it was a "nice to have" feature, but with iOS, Android, macOS, and Windows all having system-wide dark modes now, I feel that it's almost a necessity these days.

I proposed accent colors first since I believe a theme cleanup would make this a lot easier. The idea being that if a lot of variables can get standardized around the Accent Colors concept, it'd make it possible to re-use like 95% of code between a light and dark theme.

At that point the dark mode toggle would only have to change like a handful of variables relating to backgrounds and text colors: primary-background-color, primary-text-color, secondary-text-color, disabled-text-color, card-background-color, sidebar-icon-color ...

I haven't really done a deep dive into all the theme variables yet, so I'm sure that I'm missing some things and it probably won't be quite that easy, but that's the general idea.

A few reasons that dark mode would be awesome:

• Would make the demo website feel super polished and kickass. Makes a much better first impression when a website or app seamlessly matches your operating system.
• Users would no longer need the "Set dark theme for the night" automation in the frontend docs because the OS has built-in scheduling options for this.
• Could streamline things like the Map panel in sidebar and Lovelace Map card to name one example. Wouldn't need the "Dark Mode?" toggle anymore, it could just change the map tiles automatically to fit in with the users OS using the prefers-color-scheme media query.

[bramkragten]

I think these are great ideas, I would also like to reduce our official theming variables to:

Text styles

The text styles (referred to as <TEXT_STYLE> below) used in the color system:

Text style | Description
--- | ---
primary | Used for most text (e.g., text-primary-on-light)
secondary | Used for text which is lower in the visual hierarchy (e.g., text-secondary-on-light)
hint | Used for text hints, such as those in text fields and labels (e.g., text-hint-on-light)
disabled | Used for text in disabled components and content (e.g., text-disabled-on-light)
icon | Used for icons (e.g., text-icon-on-light)

Here are the example usages of primary text style:

• CSS Custom property: --theme-text-primary-on-light

Theme

CSS Custom property | Description
--- | ---
--theme-primary | The theme primary color
--theme-secondary | The theme secondary color
--theme-background | The theme background color
--theme-surface | The theme surface color
--theme-on-primary | Text color on top of a primary background
--theme-on-secondary | Text color on top of a secondary background
--theme-on-surface | Text color on top of a surface background
--theme-text-<TEXT_STYLE>-on-light | Text color for TEXT_STYLE on top of light background. Please see text styles section.
--theme-text-<TEXT_STYLE>-on-dark | Text color for TEXT_STYLE on top of dark background. Please see text styles section.

[Dino-Tech]

Sounds great! Since the release of Android 10, I have been working on a dark theme structure that is designed to reuse color variables and shading, focusing on accent colors for personal preference. The accent color changes are applied with a button click and the results have been pretty consistent with multiple colors I've tried so far, which means this is very achievable. I am by no means a dev or programmer, but feel free to grab any inspiration if needed https://github.com/Dino-Tech/Home-Assistant-Main and I'll be glad to help @SeanPM5 if you need anything.

[SeanPM5]

Thanks, I will take a look tomorrow when I have a little more free time. I know that you like to fully customize _everything_ so I'm sure that'll be a huge help in listing all the possible variables 😄

Came up with a mostly working initial version yesterday. Still needs some tweaks but I'm pretty happy with the overall style so far. Here is how it would look on the demo site:

Seems that the only tricky aspect of this idea will be the dark-primary-color and light-primary-color variables. I don't think these can be hardcoded values since they'll be dependent on the accent color (which can be changed on the fly).

So I think when user selects an accent color, it needs to generate a darker and lighter shade of their selected accent color (found this tool which does that). Not sure this is too important anyway, since these two variables seem rarely used from what I can tell? This is how I have them defined for now:

      # SET ACCENT COLOR HERE - THIS WILL CHANGE MOST UI ELEMENTS
      accent: "#26659c"

      # ALL ACCENT COLOR CHANGES UNDER HERE
      primary-color: "var(--accent)"
      dark-primary-color: "var(--accent)"
      light-primary-color: "var(--accent)"

The rest of this seems like it'll be fairly straightforward, just a little time consuming. I will share the theme here once I make some more progress and clean things up a bit, then it can be revised based on feedback.

[Dino-Tech]

Also, take a look here https://github.com/chipriley/lovelace-css-values hasn't been updated for a few months, but was a great reference tool back then. Specifically, the known_css_refs.md

[SeanPM5]

Forgot to close this earlier, Bram implemented in 0.114 / https://github.com/home-assistant/frontend/pull/6430 and it's awesome 🎉 🎉 🎉