Though setting aside practicality for a bit I wish we would design software to be more backwards compatible so old versions of things could continue to work for longer. I shouldn't have to buy a new phone every three years, for example.
Also for a tool like Audacity, I rarely need to update it. It doesn't depend on a service, so I don't need to worry about an API falling out of support and he security risks are much lower. I wish we could design more of our software to work this way.
Obviously for internet connected things like browsers this isn't possible as the security impacts are significantly higher, but why should I need to update Word every month if I don't plan to use the online components, for example.
I also wonder if there is a liability component to this that makes force updating a common pattern.
I'm imagining some automated tooling where changelogs are tied to specific git commits, and when you go down a code path that has a changelog entry tied to it in this way, it pops up the dialog. The program downloads the changelogs in the background (if the user chooses), but doesn't pop up a notification unless it's relevant to the user.
I think what we need is another way of architecturing software. I'm thinking of Erlang's actors and hot reloading: the whole language and its environment were built to allow upgrading parts of the app without turning the whole thing off, thanks to actors that compartmentalize state and minimize the places where it can change. That's extremely useful for servers, but why can't I have the same for desktop apps ? For your example again, maybe have some "actor" that can give me a sort, and when updates come the old instance is killed and the new instance takes its place. No need to turn down the app, to lose my current work, to waste dozens of minutes.
Unfortunately desktop apps are pretty much dead for the masses, and webapps solve both the problem of not updating (next time you come it'll be updated) and atomic updates (a client side app can load some javascript when needed). If we want desktop apps to come back (I do) we need to find a way to do the same
It might, if you did it like GP posted:
>> a little note pops up informing me that there's a bug in sorting non-ascii characters that was fixed recently
>> The program downloads the changelogs in the background (if the user chooses)
Note the stark deviation from standard practice: GP would like the popups to actually tell you what's in the update.
In my experience with both techies and non-techies alike, the main reason everyone hates updates is that it's always a cat in a bag. You'll likely get some bug fixes. You may get some new features. Some of those may even be useful. It's more likely the app will become slower instead of faster. It's quite likely there will be disruptive UI changes. Often completely gratuitous ones.
Random recent example: I noticed my wife has an OS update on her phone pending for the past three months. I asked, she agreed, I did the update round. Told her, "wow, you're getting a version bump, I envy you". I immediately noticed some user-set icons were wrong[0], but quickly corrected it without saying anything. I though that's the worst of it. Couple hours later, she comes back to me complaining that the update messed up notification sounds and the new keyboard has changed scaling, breaking her muscle memory for touch typing. Also the battery life dropped significantly.
Updates today are like loot boxes in games, except most of the "rewards" make your life worse.
One solution to this problem would be to have a separate stream for feature updates, and a separate one for bugfixes and security updates - and only ever bother the user about the latter. But that would increase the costs for the software vendor, and we can't have that. Who are you, the user, to complain about what your lord does? SaaS stands for Serfdom as a Service.
--
[0] - The ones you assign to your SIM cards in dual-SIM use scenario. The update added new icons to the set, and apparently the OS must have been storing user choice as an index into that set, instead of using icon ID.
> SaaS stands for Serfdom as a Service
It's interesting that the SaaS term was born from the Cloud, but its tenets still apply to desktop applications
I'd agree in most cases, but I'd still leave some grace period for updates that require rebooting the app or the OS. Nag and cajole the user all you want, but don't ever lose their data, or interrupt them during a meeting.
> SaaS term was born from the Cloud, but its tenets still apply to desktop applications
There are two main facets of SaaS - a nice one, and a nasty one. The nice one is that it outsources ops/maintenance. You're just using the software, someone else is keeping it running and up to date - and it's more efficient this way. The nasty one is, the party controlling the software is in position of power - they can make you pay rent, lock you in and hold your data ransom, and exploit your data in ways you don't want - and you can't do anything to stop it.
Desktop apps relinquish most of the benefits of SaaS, but the drawbacks were backported to local software by means of normalizing subscriptions and automatic updates.
Grandpa goes: Sorting? Wha? Non-ASCII? What's ASCII? Characters? Like on TV??