Please Don't Steal My Focus
codinghorror.com
codinghorror.com
Usually these bugs are caused by someone fixing another bug. It seems even wronger when a dialog box or some other new window comes up, and the focus is not on it. This gets reported, and the programmer fixes the problem by taking focus.
You could probably take away the ability for an app to grab focus for itself (but an app with focus could assign focus) with no real loss - just mandate that the notification area be used instead. Of course, that's ignoring legacy apps, so it can't really be done (smoothly), but there probably is a clean, correct in hindsight solution to this problem.
Then again, if they're going to break stuff just because in Vista... might as well add something useful!
-------
Why can't I get Help from this program?
The Help for this program was created in Windows Help format, which was used in previous versions of Windows and it is not supported in Windows Vista.
For more information, see Windows Help program (WinHlp32.exe) is no longer included with Windows on the Microsoft support website.
Generally speaking, I agree there are a lot of complicated race conditions in GUIs. Parts of solutions: more global undos and event logs, disabling controls for the minimum human reaction time, less invasive dialogs and event notifications, faster feedback...
The real solution is to have a coherent security policy in the OS. Then things won't get urgent for automatic updates. Beyond updates, there shouldn't be much need to ever have an app take focus after already running. A visual notification like those little hopping icons in OS X works very well.
Your point about an app taking focus makes sense. It's really a question of etiquette. A reasonable underlying system would allow apps to take focus, but it would less often be urgent and most likely in response to user input, not not interrupting.
_User_ triggered apps/windows/dialogs are allowed to take focus, because it's clearly the user's intention to open/use that app. This does not hold true for automatic updater windows, such as update boxes, new chat messages, etc.
OS X for example gets this half right, with the play sound and bounce dock icon features. The perpetually bouncing icons can drive me crazy, so the best solution would be if cmd-tab automatically put apps demanding user attention first in the open apps list, so that as soon as there's a dock bounce, I can get to it with one quick cmd-tab. That way I can get to it fast and I don't run the risk of the spacebar-ok|cancel disaster (which in minor forms has happened to me before too).
http://www.microsoft.com/windowsxp/downloads/powertoys/xppow...
"Apps should never steal focus" is a pretty broad generalization that's not always right. Then again, most Linux apps do not randomly pop up dialogs trying to alert you of something.
Happened to my wife yesterday - she was trying to use the BART website to print herself a one-day parking pass. She was using an OSX 10.4 powerbook with Firefox and choose Save As PDF. Unfortunately something went wrong with Firefox at that moment and another modal dialog appeared.
This dialog unfortunately obscured the first one but for some reason did not have the focus. She freaked out because now she couldn't safely quit the application and she was afraid that she wouldn't be able to get back to the site without having to pay again.
Luckily the number for her parking pass was visible on the screen so she recorded that and called the help line.
I don't think this is a browser issue, and I think the only solution is to insist that all modal dialogs implement the ESC key as Cancel. The vi editor got this right 30 years ago: you should always be allowed to press ESC to get out of whatever mode you're in.
As for the Esc thing, I can't recall a case where a Mac native application didn't press "Cancel" when I hit escape. I think there might be problems with ported applications though.