Your specific example is just repeating what I've said, but your generic point is wrong: let's say you have an important task in an app with unavoidable interruptions, during which you switch to your browser to mindlessly scroll.
You most likely want to return to the main task as soon as possible because that scrolling is just a time filler because you can't do anything productive. So you don't need any notification and extra action, just switch back asap and continue work with as little interruption as possible.
But even in the specific example that depends entirely on what you're switching from and to and for what reason. If it's for something quick non-interactive (I don't know, switch to a file browser to check the file name or something), then yes, you'd prefer to seamlessly be switched back to the main app to do the thing you launched it for.
But if it's not an important app, then yeah, you just want it to be ready for you and switch to it whenever you decide to avoid the launching delay later
Your example is wrong because the people who write apps always think they are the important work that should steal focus. The user on the other hand knows how to give focus to what they want to use when they want to use it and doesn't benefit from nondeterministic behavior.
My real presumption is that the user knows exactly what they want to happen, but can't encode that knowledge into OS configuration because people have no imagination for trivial use cases, so demand blanket bans. While another group is just as limited and encoded blanket allows
> Would I?
You would
> How do you know?
By being the omniscient being that came up with the conditions in the first place
Nope. I never want my front task just interrupted like that. Let's take your "check the filename or something" example, and while you're there, you realize you also need a new directory, so while you're typing the name, the other task steals focus and the character you're typing cancels the task - and now you have to start it again. This exact situation has happened so many times, and it's why focus stealing focus of any kind is a problem.
I don't care how important the app's developers think their app is. It's my computer, it's my decision how "important" something is.
Let's take the real example I've made up (which is also a situation that happened many times to warrant an automated solution to limit distraction), not a totally different one you've made up because you can't point how the original fails withotu changing the conditions.
Also, I've specifically mentioned typing as a different workfow/use case because that obviously requires different handling.
Fine. I'm checking the files as you say, focus changes while I'm still checking, now I have to switch back to finish checking. No. Do not want.
Also, no one else needs to be deciding how my "distractions need limiting" on my computer. I can handle that myself. Provide settings, an extension framework, whatever to allow people to manage their distractions, but don't force that on me and my device.
No, you're committing the exact same error again. You stopped checking in the first 0.5 sec while the app took 1 sec to start. If you're not capable of imagining a situation where this happens like some other commenters, that's ok, but that's a different argument.
> I don't get it, are you not capable of imagining a situation where
You're the one deciding that!!! That's what a properly designed system would allow you to do. But the system you advocate for does NOT. If decides for you that you'll never need it. Just like the current dumb systems decide for you that you always need it
Why do you presume to tell me how I perform a task? Do you know how many files I have to scan through to check? Do you know how far the Finder scroll has to move to show me what I want? Maybe it takes a glance. Maybe it takes ten seconds.
I don't particularly care what kind of activity you might be imagining, but nothing that steals focus should be happening without my consent. You have been arguing that it should and then later changing your argument to allowing configuration for such things.
> > I don't get it, are you not capable of imagining a situation where
I don't know where this came from, but it's not in my comments. I think your emotional response to this discussion has you conflating commenters.
If you want to advocate for configuration to allow focus stealing that's fine. But you've been arguing as if it's silly that anyone would want it any other way than you.
> Why do you presume to tell me how I perform a task?
Why do you keep presuming you can make up your own example when arguing about a different one??? The original premise "depends entirely on what you're switching from and to and for what reason", so of course if you change your conditions you'll have different outcome re. focus stealing!
> You have been arguing that it should
No, you've been missing the point this whole time.
> I don't know where this came from, but it's not in my comments
It is, I suggested you imagine the case where you'd like the change of focus to happen in response to some conditions you find favorable, yet several times you faield to address it as is and kept bringing up different conditiosn.
> I think your emotional response to this discussion has you conflating commenters.
I think if you're that bad at reading literal text you shouldn't attempt at trying to read emotional state of that author.
> If you want to advocate for configuration to allow focus stealing that's fine
So why do you keep arguing that it's not fine because you can't imagine a situation where it is?
> But you've been arguing as if it's silly that anyone would want it any other way than you.
Nope, that's you misreading again. I have no issue with people who want a dumbed down "never steal" config.
Maybe the silly part here is people ostensibly supporting computers respecting user choices arguing against being able to better configure your computer to respect user choices.
If computers could read thoughts and 100% reliably determine when the user is done with their current task and would like to switch back to the other application, then yes, it would definitely make sense to implement the functionality you're describing.
In the real world, where it's impossible for the OS to distinguish between the "You stopped checking in the first 0.5 sec while the app took 1 sec to start" scenario and the "you're still busy with the current task and don't want to switch to the other app yet" scenario, the safe choice is always to not steal the focus because the cost of switching too early is significantly higher than the cost of not switching.
If perfect is not possible let's do nothing? Your approach is likely the reason for the current bad global rule. You want to replace it with another bad global rule.
But in the real world I'd use proxy conditions to arrive at a rate of correct guesses that's satisfactory for me just like with everything else with computers (even basic mouse clicks), not use your total "safe" ban (safety has a trade-off, you can't resolve that universally)
I (and presumably a lot of other people) don't believe that it's possible to build a system that can dynamically determine when it's acceptable to steal focus with low enough error rate to make it better than a total ban.
Seemingly you disagree and believe that such a system is possible. Is there anything preventing you from implementing it to prove the doubters wrong?
It's not what I would call invisible, but yeah that's the behaviour I would expect. That's also similar, to what already happens when I type in one window, while I scroll in another.
Or on top of each other, so yeah it would only work, if at least one of them is not maximized/fullscreened. (And none has holes in the right places, but I have yet to see a program, that makes an actual use of this.)
My expectation is described in the comment you replied to and side comments
Microwave's ding is also bad UI, especially when it's repetitive as it's just useless noise. But even the first ding - what value does it have if you already have exactly the same notification category - audio cue - built right there in the process: the machine noise disappears when it stops working.
Brains work just fine and your typical kitchen/apartment range is small enough, but in general - the trade-off between comfort and reliability is not something you can resolve for others
You most likely want to return to the main task as soon as possible because that scrolling is just a time filler because you can't do anything productive. So you don't need any notification and extra action, just switch back asap and continue work with as little interruption as possible.
But even in the specific example that depends entirely on what you're switching from and to and for what reason. If it's for something quick non-interactive (I don't know, switch to a file browser to check the file name or something), then yes, you'd prefer to seamlessly be switched back to the main app to do the thing you launched it for.
But if it's not an important app, then yeah, you just want it to be ready for you and switch to it whenever you decide to avoid the launching delay later