This is 100% the issue with the recent UI changes. Its not about whether its a ‘good’ change ot not. Frankly that doesn’t matter. It was a very VERY impactful user facing change. In my previous life as a Support manager for a global software publisher, that would have MANDATED a study on the effects and a UAT before deployment to the production branch. It would have also mandatory to make the change an opt-in by the user. So no checkbox, old behavior, checbox that user MUST click on thier own… New behavior. Pain from a dev perspective but a very simple method to allow users to adopt new changes.
It would have been an easy mitigation too… Had they published intent to change UI in the blog for the 12.x release and held it until the 2022.2.x release, people would have had two whole months to comment and flesh out issues (like cant access companion app settings when a non admin user, or a critical use case that got hammered by the removal of an entry point.)
But mentioning that, ‘hey I might want to change some things this month’ on a Git thread and then just doing it by the end of month (yes I read ths entire thread, thats basically what it amounts to, change intent in first week of November and change added to the December release. Less thab one month.) Not very good organizational change management…
I hope lessons were learned from this and it won’t happen again. Change can be managed, but you have to at least try. I hope they do better.