My computer is a workstation, not a playground, and I don't need things randomly rearranged for me.
I resisted for a long time, because Linux seemed like a "hassle", but once I'd had to reconfigure everything several times after upgrades, I realized that I was essentially going through the same process, only on someone else's schedule and not by choice.
After trying out a couple of WMs and choosing one to become familiar with, I've NEVER AGAIN had that experience. Even if a distro has a different default setup, it's a matter of copying the config file I already have saved from a previous install.
What a load off my shoulders!
For what? Linux is even worse on that aspect.
First for the OS GUI (Desktop manager, finder, launcher, and config apps) - both Gnome and KDE and Canonical and others have the tendency to remake it (usually worse) every few years and every major release. Then there's the fact that key things keep missing in action (like image preview in the file selector in Gnome iirc).
And that's for the core desktop (launcher + config apps). It gets worse with regular apps. Some being GTK and others KDE/QT based, some use bizarro or legacy frameworks, some with custom cross-platform UIs that kind of match the look of just GTK apps usually, and so on.
Sure, as you did, you can always go with a minimal setup (just some terminals and a very simple window manager), and that will stay stable, but that's really retreating from UI, not a holy grail of stable UI. And it doesn't include your UI apps (which suffer from what I described above).
I've also tried Ubuntu, Debian, and a few others, and had to abandon them for the same reasons.
Eventually, I settled on [redacted], which is pretty raw and immature, but once I get it tweaked out, I can move the config file to another distro and have it work roughly the same.
Basically, I doubled down and committed to cutting out all the software which pulls that kind of shit, which means I no longer use Chromium or Firefox (except for testing), Gnome, etc.
I found a lightweight WM which seems to be relatively stable in "poor emulation of Windows 95 plus a few additions" mode, which is available across several different distros, and I keep a repo with my config for it so that I can readjust it from whatever the distro defaults it to.
It's not a day's worth of work, and not even a year, but now I'm fairly confident that I can sit down at my WORKSTATION and something hasn't randomly changed and I can't get it back to how it was before.
In fact, I've been able to get this experience while not buying or using any new devices, since I only use secondhand hardware for ethical/moral reasons.
To be fair, I don't think Windows has had this advantage over Linux for over 20 years. Maybe macOS has, but in Windows, almost every application is built with a weird custom proprietary toolkit. Even Office and Visual Studio, Microsoft's flagship Windows programs, are. That desktop Linux only has two major toolkits is a blessing. With the rise of UWP and official Microsoft Electron apps like VS Code and Teams, it's not even clear what the look and feel of a native Windows program is supposed to be anymore.
You're not, but then you're left behind on functional, security, and functionality updates as well (which you do want), not just on useless UI changes (which you don't).
The trouble with that epistemology is that it makes it impossible to discern (or at least pointless to discuss) any qualities of a user interface except how popular the interface is or how much humans enjoy using the interface.
> When you change something—be it a GUI or an API—you need to take into account not just whether the change is better, but also whether it's worth the very high inherent cost of change.
This sounds dangerously close to the awful epistemology that is the precautionary principle. Both are saying that if there is some proposal for which we don't have any good knowledge about its potential downsides, we ought to reject the proposal. Your variation seems to be that we should assign the proposal some baseline cost (and thus reject the proposal unless we have knowledge that the benefit exceeds the cost). I simply don't think there is any way of establishing that baseline cost.
But I believe that UI updates, when they happen, should be infrequent, well-considered, and purposeful, with a bias towards leaving things as is. What really bothers me is when feedback is considered invalid because it's assumed to reflect some natural adversity to change. Maybe it does—but that pain your users are feeling is real!
I almost wish software updates still had to be distributed on discs, so that vendors would be required to think and plan instead of essentially performing perpetual experiments on their customers.
In this regard, I find Linux XWindows and WMs to strike a good balance. It allows me to choose Xfce, or even i3. It gets most of the bad bits about modern computing (notifications, desktop sounds, panels, popups, windows-fiddling, desktop icons, shortcuts, ads, whatever will they come up with next), to just go away and not torment me anymore.
Has anyone ever counted the number of times that Firefox has changed its UI. I would bet they have people working on a new one right now.
What do we call it when people keep "fixing" things that are not broken. When people misuse the word "broken" to signify their dislike for something.
If we dig down deep enough in the source code of things, I am sure we can some interfaces that do not change much.
Because it duplicates options, separates the users in two camps, adds 2 (or more if you keep doing it) interfaces for the dev team to keep supporting, and so on...
IME, observing other users, it is the forced change that is offensive to some. They do not complain about "lack of support" (many want to be self-suficient and do not want to keep asking for "support"), they complain about changes that they see as unnecessary and that will just require more effort to learn.
A change in UI must generally be so good, as to completely overshadow the costs of change. Hence, most changes will NOT pass that high bar, and are thus bad changes.
Unless some UI/UX feature you're considering received overwhelming support from your users (both regular and power-users), it's probably not worth doing and you should be directing your efforts anywhere else.
That's not an "ergo." Initially not liking something doesn't make it bad.
You seem to be extremely overestimating the cost of change. A few people can complain loudly for 24 hours, and then everyone's practically forgotten what the old UX was even like.
Kids can be averse to eating their vegetables, it doesn't mean we stop giving them to them. Similarly, when consumers actually benefit from the changes, it's not always immediately apparent, so they complain until they realize that son of a gun, the app is actually better/faster/easier now -- and then they rarely go back and talk about how great the new way is, they just use it without comment.
Using "humans are adverse to change" as an argument to not change is a pretty terrible way to go about things.
I'm not saying change for change's sake is good... but that people are actually happy for positive change even when it's small, even if they gripe about it at first. Remember, actions (continued usage) are louder than words.
(If people are leaving your app, on the other hand, it's probably not because of change in itself -- it's because the change was bad. We all make mistakes. Just fix it!)
How do you know how many have forgotten the old UX vs. simply given up after being dismissed or ignored? How do you distinguish between someone who has learned to like the change, and someone who is quietly enduring it or has left the conversation to migrate away from the problematic software?
I don't know a way to measure those two groups better than simply talking to them, but I can say with certainty that the latter exists. I have felt the impact of short-sighted, change-happy, dismissive UI development more than a few times.
This bit from the article resonates with me:
> What matters to [most regular people] is continuity and reliability. Again, this isn’t being change-averse. Regular users typically welcome change if it brings something interesting to the table and, most of all, if it improves functionality in meaningful ways.
I like continual improvement as much as the next creative mind, but I also have great respect for the users of my software and understand that disruption is frustrating and costly to them. I therefore avoid releasing workflow-breaking changes until I am fairly sure they make things objectively better and I can also provide backward compatibility and/or a smooth migration path to folks who need it. If I can't, then I seriously consider redesigning or discarding the change I had in mind.
To put it a different way: Once I have encouraged people to use my software, I feel a responsibility to them. It no longer belongs exclusively to me, and I am not necessarily the most qualified judge of what is "better".
I think you're projecting/generalizing here. I for one love change, I get bored of interfaces if they stay the same for too long, stuff starts to "feel old". I install OS updates as soon as possible and I love to use the refreshed designs. The world around us changes constantly, it's not static. Fashion evolves, aesthetics evolve, and hardware and software design evolves too.
Now whether your preference for no change or my preference for change is more common in the population is a different question.
It doesn't matter!
The funny thing about human-computer interfaces is that they are used by humans. Humans are adverse to change; ergo, a constantly-changing interface is also a bad interface.
When you change something—be it a GUI or an API—you need to take into account not just whether the change is better, but also whether it's worth the very high inherent cost of change. I don't think the modern tech industry does this anywhere near enough.