The feature of “narrow width” was lost. It seems like it was traded away for cosmetics; adorn every value with an icon. For badges, that’s ‘form over function’.
BTW, it’s worrisome when a long post explains the difficulty of pleasing everyone, how too many choices confuse people, more features mean more code maintenance, how resources are short, etc. Reading between the lines, no further changes will be considered so get used to it.
Please note that your post explains in great detail that the new badges were changed to meet the aesthetic of new design specifications. For the people who were using them for their compactness, the new design is a Breaking Change.
Nowhere has this been explicitly acknowledged but it has been keenly felt by long-time users of badges whose concerns have been dismissed via silence or evasive replies.
They are both self-submitted dashboards and dashboards our community think is good. With that said, we should extend the dataset with more submissions for the next phase. Stay tuned.
Somehow we’ve completely missed that this was effectively being tested with that decision in mind. Don’t think I saw an announcement or invitation to actively test this particular design decision.
I wish more people would have participated, but without announcing an active test like this, my guess is people just weren’t aware.
I did try to rally some extra users by announcing it in a thread but apparently it failed to attract a lot of users…
You cant be surprised this is experienced as a contradictio in terminis… What ever you felt about the old style badges, their main feature was the fixed width (aesthetic) and the customization choice… leaving that out, and replacing it with a new design that has an obligatory icon, and has a variable width one can not control (remember we could control the variable height of the old style badge by changing its name) can not be called ‘feature parity’.
If the ‘unfortunately’ here pertains to the ‘still working’, then most of the users here will forgive you
This is great news for those that would like to keep using the old style badge: a custom card (exactly the migration strategy we asked for) by the HA frontend team. Yes please! Truly a great start of the day to read your post as the first of the day, thanks for that.
I had already opened a Github repo, hoping people would join in in developing such a card, but can now close that (it has been extremely quiet there…), this sounds so much more promising
Add a few config options to the new badge card (no icon, configurable theme variables, allow inside card in view) and even more users will embrace the new shiny badge sooner than later.
Thanks for your extensive contribution here, much appreciated.
The low usage might have something to do with the fact that badges were removed from the autogenerated dashboards over 3 years ago.
Couple that with the fact that up till last month, there was no way to add badges via the UI - you had to delve into the Raw Configuration Editor of a dashboard to add them. Most people might simply be unaware of them.
You’d hardly expect a higher usage for something which was, for all intents and purposes, obscured.
Alexa media player is broken on most versions of HA. It’s best you use the automation band aide that restarts the integration 15-30 seconds after HA restarts/boots up.
FYI, there’s a sticky post in Configuration explaining that the integration has basically been abandoned by its developers.
Yes, it’s correct. Right now, myself, @dbrunt, and a few others are keeping the integration alive with minor PRs. But in order to fully correct many of the issues, the entire integration and it’s upstream lib need to be rewritten from the ground up.
@dbrunt is putting in most of the recent efforts and is learning the library as he goes. So the fixes pace will be slow for a while.
