Personally I almost never agree with these "the desktop is dead" kind of articles. If anything, the problem this author has to be exacerbated by the move away from the traditional desktop style than an embrace of it. That preview close dialog is not something you'd see 20 years but is something you see in "apps" all the time.
Perhaps the problem is, as you allude to, that software is hostile to the user now. There's always something more than simply being a tool that you buy, use, and close. Now most programs are merely portals for "services".
> That preview close dialog is not something you'd see 20 years
That’s because the application would straight up lose the files without prompting.
Also pretty sure text editors had something similar 50 years back, that’s why you :q! from vim, :q would tell you that you have unsaved buffers (or whatever the lingo is) and refuse.
TFA is literally abusing a crash-resistance feature out of laziness, and will no doubt complain when it fails them. 20 years back we’d all trained ourselves to save with regularity to avoid issues, that feature would be considered manna from the heavens, and tfa absolutely mental.
Completely stupidly too, I must add:
> This is the dialog that I see every time I want to close the Preview app to clear my desktop of all that clutter in a hurry for a video call.
MacOS has a shortcut to minimize all windows! It even has a shortcut to hide all aplications but the current one! You don’t need to close anything to “clear your desktop in a hurry”!
Yeah but the semantic difference between "hide" and "quit" is a very technical one that doesn't need to exist. On mobile it doesn't happen, and we can thank Android for that, as they insisted from day one that multi-tasking APIs should not require the user to manually manage memory on the device. When Apple added multi-tasking to iOS later they copied the Android design more or less exactly. Browsers do something similar for browser tabs now.
However this was never brought to the desktop, largely because native desktop APIs are dead and none of the companies that fund them are interested in improving them. We get the web and if it sucks, well too bad.
> Yeah but the semantic difference between "hide" and "quit" is a very technical one that doesn't need to exist.
Funny, because I think the exact opposite. "Hide" means, "stop showing it for now, but keep it around". "Quit" means, "I'm done with you and I expect you to not be doing any work until I start you again". It's a very significant usability difference.
> On mobile it doesn't happen, and we can thank Android for that
To this day I consider it to be the worst, most dumb idea Android ever had. I hate it. It's the reason I hated my first smartphone. It's the reason why, from the second phone on, I only ever buy top-of-the-line most overpriced flagships available - I have to overprovision resources to ensure the phone works smoothly, because there are countless of background processes doing god knows what, that cannot be killed and prevented from restarting.
I know best when I'm done with an app. I want to be able to kill it, and all its background processes, and I want them to stay dead until I change my mind. If I were designing a mobile OS, I'd make the distinction between "hide" and "quit" as clear as day, and make it an app store policy violation for an app to execute anything in the background after being "quitted" by the user (polling for notifications would be handled by the system).
I agree with you about this distinction being important, but I come at it from a different angle - I don't mind if most apps operate in the background as they need, with preemptive scheduling like Android. But I really, Really mind if I don't have a rock solid way to quickly and easily kill an app (and all related tasks/processes/async jobs/etc).
1. There are times I want to make sure an app is not running (think zoom/hangouts with video access), or a work app that records location
2. The single best way to fix a problem, any problem, is still 'turn it off and back on again'.
I don't want to kill the current activity and hope that the background jobs stop at some point in the nearish future with absolutely no feedback or insight. I want "killall <root app process>" then give the app 5ish seconds to cleanup and if it's still around "killall -9 <root app process>".
On mobile there are ways to force quit apps. They just aren't front and centre, nor mandatory for users to understand, like it is on the desktop.
Too many apps abusing resources and affecting UI speed is a separate issue, and mobile OS's developed a lot of techniques and technologies to allow apps to work in the background without bothering the user, and without overloading the device's resources. It's a nice set of systems, really, and I would be happy if desktops worked the same way. Nobody would be taking force quit away from me, even if such a system were to be implemented.
> On mobile it doesn't happen, and we can thank Android for that, as they insisted from day one that multi-tasking APIs should not require the user to manually manage memory on the device.
Yes, and this turns my phone into an amnesiac the moment I have a hundred tabs and fifteen apps open. Switch to a different app, switch back... Oops, all gone! Enjoy recreating the state from history manually, if that's even possible.
There are no words to express how unhappy this makes me. We've got gigabytes of memory on our handhelds these days, why can't the phone just deal with it?
This is spot on. People want to hand over responsibility for their computations to some big company offering a "free" service so long as you use the official app, and then they wonder why they don't feel like they have any power or freedom.
Perhaps the problem is, as you allude to, that software is hostile to the user now. There's always something more than simply being a tool that you buy, use, and close. Now most programs are merely portals for "services".