Nathan,
I generally agree with don’t change the default, but many times due to the direction the core is going , an api change or an integration by an out side vendor it is a necessity (I.E weather attributes, Aladdin, etc). Usually this is explained and users have ample time to come up with solutions months prior to any changes or during beta so solution can be given to the forum or in the release notes.
This changed to me came out of nowhere. The beta which was taking about new badges had an issue with many users. I struggling with it due to the Android companion app not working with the new badges. I did not look at the badges due to this issue until the end of beta and never addressed the issue it in the beta discord.
I believe if enough of us did during beta either the developers or the advanced users would have come up with a solution prior to the release.
I appreciate the optimistic position but my experience in product dev says. No, screams, otherwise.
Users like thier settings. The minute you’re changing them - EVEN for a worthy cause. You lost the game. You will NEVER (yes an absolute) please the user community if you are changing thier existing setting. The ONLY exception is if the setting g is depricated and doesn’t matter anymore.
Over my career I saw it happen to product after product. Usually when a new PM was added. And in those cases products that suffered this issue had it happen again. The post mortem basically went - did we not learn our lesson last time?
Edit: because someone asked. No I absolutely hate the old badges and think they should die in fire.
Not sure that I was optimistic, I was just pointing out what I have experienced in the many years using HA that either the coders, experienced users or sometimes the change is pulled when enough people point out the issue and it gets resolved very quickly. Most of the time (not all) I find the people making decisions in the direction of HA to be very reasonable.
I agree with what your are saying 100% of the time that no one likes changing to the existing settings. This has happened many times in the many years of me using HA. Most of the time the changes required extra work to get my system to work as before the release was made.
I’ll add my two cents worth of feedback on the new badges. I wanted to give it several days to see how it worked out. This feedback is particularly in regards to a tablet that I use running HA on FKB. The tablet is located at a fixed position on a countertop underneath a cabinet and I use it like a wall-mounted controller. My Tablet’s display is 8 inches and the distance from it to a user’s eyes is around 24 to 28 inches.
State information - font size is OK.
Name - font size is very much too small (can barely read it). The old badge’s font size was OK.
Icon size - is really too small. You can make it out, but more pleasing to the eye if larger. Again, the old Badge’s icon size was fine.
Width of the badge is probably OK, but prefer a smaller width in order to fit more badges on a single row.
@madelena Some honest general questions - please don’t take this as a negative criticism of you or your team’s current methods:
Wouldn’t it be more simple to put up a post asking for the forum’s feedback way before work on any major change is started?
Can feedback be gleaned in a more efficient and open way rather than targeted surveys?
Can main (read: maintainers of their system) users’ be more involved and their responses more heavily weighted when compared to “casual” (read: family members of the maintainers) users’ responses?
Wouldn’t it be a more efficient use of the devs’ time, motivation and resources to release something which is overwhelmingly liked on day 1, instead of them having to go back and revert some of their latest changes in order to achieve this?
Is there a way to at least aim for feature parity when changing something before it’s released? (This also applies to yaml to UI conversions).
I’ve been working in this sector for long enough to understand that people don’t usually complain about the above when you launch new features (Voice and Music Assistant are a couple of good cases in point).
They will definitely complain when you “improve” an existing feature and they end up with less options and have to constantly apply workarounds in order to maintain current functionality.
At a certain point, upgrade fatigue will start to set in, and instead of looking forward to the next release, they will start to dread it.
I work in software development and have a slightly different view. Almost every software project I have been associated with has calcified after five years or so. Generally, there is no money to fix problems. Instead the goal is to add as many features as possible. But the new features were not envisioned at the start and are just shoved in. Soon it is a house of cards to change anything.
A few times I have seen it where they are willing to break things to move forward. Even with the initial pain, the results are better for everyone.
I may be in the minority here. But I would rather see the HA team break things to move forward.
Would you be happy if Apple or Microsoft followed that strategy?
If the HA team is truly in a corner with a feature and they explained that, I’m sure people would understand.
I agree that sometimes a breaking change cannot be avoided, but in those cases provide a migration sttagegy and/or a deprecation timeline.
The kind of projects you describe won’t survive for long anyway, I’d think. Features and innovation is important, but it doesn’t need to preclude maintenance. HA is in a healthy state. Those risks aren’t necessary.
As a user of 5yrs I have gone through this at least twice. Always because of breaking changes that weren’t properly documented.
The first being the classic bluetooth tracker where there was zilch acknowledgment of the issue and second with the stock thermostat card. Another UI change that broke things.
In the latter case it took nearly 3 months for the community to come up with card-mod styles to replicate what was never broken in the first place!
It appears now that, whilst not acknowledged, it has been learnt that there should be a way back although this has had to be “discovered” by the users.
I refer to @madelena here.
“Before then, the problem was somewhat resolved with the discovery of custom:hui-state-badge-element”
So, whilst painful, it appears lessons are being learnt I hope
Frankly, I’d prefer HA not use Apple or Micro$oft as a role model.
I’m old enough to remember when people used to look forward to an update from M$. This was a time (believe it or not) when M$ actually conducted user testing. They watched how users interacted with their products, and worked hard to make those users’ day-to-day jobs easier. The changes were incremental; shave a few moments, or one click, off a process that the user repeats a thousand times a day, and you’ve made a big improvement.
Now we all dread their updates. There are no usability improvements. Everything is “dumbed down” so that it looks clean and fashionable to the designers and reviewers - people who never actually use the product. Everything is shuffled around, names are changed and advanced features are hidden or made more complex to access. Some features are dropped in the name of simplicity for the beginner. Experienced users are worse off.
