I don't think it would entice more people into upgrading. People don't necessary want to stay on old versions, they just don't want to be interrupted. To make it more probable that a user updates, you need to make the interruption as little as possible: download stuff in the background, make it patches rather than full blown installer, ... to follow in your direction, if I have a popup that says "you just sorted rows alphabetically but there's a bug, do you want me to fix it ?" and the install takes 5 seconds then it's good. If it takes 30 minutes then screw your update
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
> I don't think it would entice more people into upgrading. People don't necessary want to stay on old versions, they just don't want to be interrupted.
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.
Can't agree more with everything you're saying, except for the last part: if bugfixes/security updates are in one stream, and new features are in another, the first one should be applied all the time without asking, and the second one should be the one that prompts a pop-up.
> 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
> bugfixes/security updates (...) should be applied all the time without asking
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.
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