User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Why is it an industry-standard to have a windows automatically grab focus?

From a usability point of view, why is it considered "good practice" for a desktop application to grab (more like hijack) the window focus when opening or whenever the program decides to do so? i.e. why is it even an option to let a window "violently" grab the focus like that? I am asuming it's considered good practice because it seems prevalent on all Windows versions since I can remember. Can't comment on Linux or Mac, but maybe someone else can.

I understand that if I open a program that requires input (a password field or something) I would maybe like that element to be the one that gets focus so that I can start typing the required info ASAP.

However this only works (in my opinion) if I only open one window at a time. The problem arises when I open several programs in succesion and one or more of those request auto-focus.

For example (and this happens to me quite frequently), I open Outlook and Pidgin and SublimeText in succesion. When Oulook gets focused, I start typing my password to login, but in the middle of typing SublimeText gets auto-focused and then half my password is sitting in plain view for anyone to see.

Why is this deemed a good practice? Considering that most people has to look at the keyboard when typing, that means you don't realize the focus has changed to somethig that might expose your password, potentially while someone is standing right next to you.

And even if no passwords or other sensitive information is involved, it's very annoying to be, for example, typing a long document and after several seconds of typing you turn up your head to the screen and find out half of what you typed is not there because some window just hijacked the focus.

So my question is, what are the usability considerations for doing auto-focus, regardless of what the user wants, i.e. if I have a focused window it's because I chose to be that way, why would a computer have the ability to decide otherwise? What would be a better alternative? for example, if programs wouldn't just take the focus and just flash in the task bar (like they already do), is that not sufficient notice to the user? And finally, is there ANY way to disable this annoying behavior in Windows? I'm not sure about details on Linux or Mac, so I can't comment on that.

share|improve this question
    
as for your 'and finally ...' you won't get that answered here, try superuser.com, or Google – Toni Leigh Feb 6 '14 at 19:05
    
@ColinSharpe You are correct. I think I was just caught in the flow of my rant :P. I actually have searched for a solution to no avail though. – Acapulco Feb 6 '14 at 19:09
    
It is hardly an industry standard. It is good UX when the window opens as a result of explicit user action, would be kinda weird if it didn't in this case. It is very bad UX for non-explicit opening windows. This is in fact now actively discouraged by Windows. Both in its guidelines as well as in its making "put me in front" much harder to achieve. Unfortunately old habits die hard and code using the old API's is still out there. – Marjan Venema Feb 7 '14 at 11:53
1  
I'm not sure it's good ux even when the user has triggered the action by opening the application, only when the user specifically triggers a 'view this application' operation – Toni Leigh Feb 10 '14 at 20:31
    
Just speculating (so not an answer), but I think application models have been slow-ish to catch up with the notion that typically when you launch an application you have no intention of looking at it and therefore you want to have to take a separate action to see it. It would better if an app were given the focus and then starts all its slow stuff (during which it can lose the focus) rather than doing all its slow stuff and takes focus at the end of that. That would accommodate both users who want to see what they run and users who don't. – Steve Jessop Apr 4 '14 at 13:38
up vote 4 down vote accepted

This is not good UX and wouldn't be considered best practice by any user experience experts, except in extreme circumstances such as warning workers in a dangerous environment that something was seriously wrong. Not a typical desktop application !

The reason is simply that the software has been lazily implemented in this particular context. Or possibly because it has been designed like this in order to try and get users to click on an advertising link.

Some really big folk in tech tell us this is not a good idea:

http://www.codinghorror.com/blog/2007/12/please-dont-steal-my-focus.html

And it's even considered a type of bug by Mozilla:

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=focus+stealing

And an answer right here with plenty of votes mentioning focus stealing as a UX anti pattern:

What are your desktop UI pet peeves?

share|improve this answer
1  
One of the worst offenders of this I have ever seen is the PHPStorm application. When I launch the program, and while it is loading, I switch to another application while waiting. Then PHPStorm switches focus back to itself... I switch back to my other program... and PHPStorm steals the focus again! – Michael Butler Apr 19 '14 at 15:29
    
personally I find Open Office is a bad one, the number of times I've ended up with the second half of a URL, search term or piece of computer code in a Writer document lol, worse still, those characters then sometimes go on to clutter the shut down process with 'would you like to save' dialogs #first-world-problems – Toni Leigh Feb 17 '15 at 18:42

Because a lot of the time it's a good idea.

Way back when I had a Unix GUI set up not to do this and it was just as annoying as focus-on-open. The problem is this: most of the time when you open a program, it's because you want to interact with it. Not switching to the new application immediately means that your starting a program process requires a separate, annoying, step. So doing it the other way has disadvantages too.

Also, it's probably the case that usage patterns has shifted since the decision was made; it's a lot more common to have a whole load of programs running now than it was when this behaviour was decided upon. This increase in the number of programs opened at once means you're seeing the stealing behaviour a lot more often relative to the desirable one-click play option.

I doubt there is a way to always pick the correct option, although I think you could get close with a heuristic based on how recently you interacted with the current window.

share|improve this answer
    
Not switching to the new application immediately may be annoying. But stealing focus asynchronously is a security bug. – Krazy Glew Feb 15 at 20:39

@ToniLeigh says "focus stealing is bad UX."

@JackAidley says that not switching to a new application can be annoying.

While I agree with @ToniLeigh that "focus stealing is bad", it is many places. On Mac OS-X. On Windows. Many people think that Apple haas good UX, but I have been plagued by focus stealing on MacOS today.

I think that part of the problem is that people treat focus stealing like a UX issue. User experience. User Interface. The responsibility of the application programmer.

Maybe so, but more important, in my opinion, is the fact that focus stealing is a potential security hole. Focus stealing can lead to data corruption and destruction. It can lead to secrets being exposed.

I.e. focus stealing needs to be treated like an OS issue. A window manager issue. A system software issue. We must not simply blame bad application programmers for stealing focus: we must blame the platform they are running on, for allowing focus to be stolen.

Note: here I consider a web browser system software, not an application, because a web browser is a platform on which software from different sources can run.

Nevertheless, @JackAidley says that not switching to a new application can be annoying. And he is correct: It is a pain to click a button that opens a new window or aa dialog box, and then have to transfer focus by doing something like clicking in the title bar and then clicking on a button. And it is not really good practice to say "Any mouseclick in a new window/widget changes focus", especially not if apps can be opened in front of other apps.

But there is a middle ground.

Focus is a security property. We must never allow focus to be moved from software in one privilege domain to software in another privilege domain, unless the user accepts and expects such a transfer of focus. But we don't want that transfer of focus to be painful.

When you open a new app - when you click on a button, etc. - we may say that there is an implicit transfer of focus. If the new app window or widget opens immediately, great, you expected that transfer.

But oftentimes the new app does not open immediately. So the user transfers focus somewhere else. And then gets bitten when the new app window or widget finally opens, and steals focus.

I.e. part of the problem is that there can be a race condition. Which is a subset of a larger issue, that the transfer of focus can be asynchronous. This is by no means the whole problem, but if we can't solve this simple aspect of the problem, we will probably not be able to solve the rest of it.

Part of the problem is that there is a race, a window, between clicking on a button and the new app saying "Hey, I want focus now!". That window is often so small as to be unnoticeable, but when it is large enough for the user to switch away, then focus stealing becomes exceptionally painful.

So we have to solve this like any other problem in concurrent or parallel programming: we need to close the window. The SW system where the button is being clicked needs to agree to give up focus. The SW system that the button click is triggering needs to agree to accept focus.

I.e. focus needs to be transferred, with explicit cooperation of sender, receiver, and user. Not requested and granted, by only sender. Not stolen. Given. Transferred.

Initially focus is in SW domain 1.

User does something that triggers SW domain 2 to be started. Eventually, but not immediately.

Focus is transferred from SW domain 1 to an intermediate state, waiting for SW domain 2 to be ready to accept focus.

In the intermediate state, user input may be an error. Or it may be buffered for eventual delivery, if you like type ahead. But typeahead is dangerous here.

Eventually SW domain 2 is up and ready to accept input. So now the transfer of focus is complete.

If SW domain 2 is slow to start, the user can explicitly transfer away from the intermediate state, and transfer focus back some other SW domain, SW domain 3, or even SW domain 1. If the user has transferred focus away, then when SW domain 2 eventually starts, it does not automatically receive focus. It may have to notify the user, e.g. by bouncing an icon, and the user will have to explicitly transfer focus back.

I.e. focus transfer is easy and implicit when you start a new app - but only if user has not transferred focus away while the new app was starting. If the user has transferred focus elsewhere, then transferring focus back to the new app must be more explicit.

It is best if SW domain 1 knows the identity of SW domain 2, where focus is to be eventually transferred. It is impractical, in general, for SW domain 2 to know all of the possible SW domains 1 that can transfer focus to it. It may not even be practical for SW domain 1 to know who the recipient is going to be - e.g. consider a button that starts an AppleScript or shell script or ... - but it sure would be nice if it focus could be passed along, like a token, like a capability, from SWC domain 1, through any intervening scripts, to SW domain 2.

If SW domain 1 knows that it has transferred focus away to SW domain 2, then an explicit attempt to transfer back to SW domain 1 might be delegated, thereby raising SW domain 2, which may have delegated to SW domain 3, ... to some dialog box that is waiting for a button click. If the sender does not know about the transfer, then you can get into ugly situations where the user switches back to the original sender, and tries to type, but cannot, error bells ringing - until the user walks through the window and widget hierarchy to find an open dialog box. I.e. if the SW domains know that certain actions should transfer focus, then we can automatically go to the currently active domain in a "focus path".

But if SW doesn't know - if it treats all buttons the same, some being local actions that do not require focus transfer, some being actions that start dependent apps to which the user might want to transfer focus - well, it is safer not to transfer focus than to transfer.

I.e. some buttons or user actions are marked as "Focus Transfer Expected", and some as "No Focus Transfer". In the latter, an explicit action by the user is need to switch to any new window. In the former, focus is transferred from sender SW domain 1 to the intermediate state to receiver SW domain 2, with no special actions by the user. But the user can explicitly change focus.

There is no asynchronous transfer of focus between SW domain 1 and SW domain 2. Asynchronous transfer requires explicit user action.

The user is, of course, able to transfer focus around explicitly whenever they want.

(Or, you may think of it as "asynchronous transfer of focus is a special privilege", normally given only to special software such as the OS or window manager. Something like a browser may be considered as having the right to transfer focus asynchronously between the domains it manages, but not to domains outside its control. I.e. privilege domains are hierarchically nested, for the purposes of asynchronous transfer of focus, as so many other things. Ideally, the same hierarchy applies.)

(Looming issue: how can the user explicitly control focus? There must be some user actions, e.g. meta+mouse-click, that will always allow the user to take control. This is really part of the "secure input channel" for windowing GUI systems. The problem is that there are few standards for such gauranteed behavior.)

"You can't give away what you don't have" ==> focus is transferred cooperatively, not taken asynchronously. So a shell script or AppleScript, running in the background, without focus, cannot open apps that can steal focus. But running in the foreground such a script can open an app to which focus can be transferred. Again, focus would be transferred through an intermediate state - and special operations would be provided to transfer focus to that which is being opened, or not.

E.g. for MacOS's "open" https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/open.1.html, focus transfer would be a parameter to the open command used by shell scripts.

Probably similar for UNIX-style fork, exec, and spawn system or library calls. Even at such a low level. This is part of the OS.

(Probably would have to deprecate the UNIX behavior where both parent and child can read from the same file descriptor concurrently. That is the low level equivalent of focus stealing.)

===> Funny: I just got bitten by focus stealing as I was writing this - in Chrome, on MacOS. The Rescuetime activity monitor opened a new webpage and received typing intended for this.

This is not rocket science!!!! But it is concurrent programming.

I conjecture that focus stealing became so prevalent because many windowing systems evolved on relatively underpowered computers, often without multitasking. Think early windows or Mac. X-Windows historically had more options for forbidding focus stealing because the early UNIX workstations were concurrent from day 1. But even on W-Windows, the usability advantages of focus transfer won out in many environments, like the fvwm window manager.

So long as the argument is "Focus Stealing, Yes or No", we will make no progress.

We must recognize

(1) implicit focus transfer has usability advantages. Nobody wants to have to take special actions every time they open a new app.

but

(2) but focus stealing overall is a security hole, and only secondarily an app design issue.

If we fix the security hole in a way that allows (1), then we have a chance.

share|improve this answer

QuickBooks has a feature whereby you can export a report to Excel. QB "automates" the process, and turns over focus to Excel, which takes the foreground. A feature greatly appreciated by users.

Now my users need massive amounts of QB data to be in spreadsheets. So I write a program that collects the dates, types, names, etc, and feeds keystrokes to QuickBooks, creating the appropriate reports and exporting the data to Excel and then saving them with appropriate filenames that my program has constructed, based on the user tasks and input data.

Once the user starts my program, my splash screen notifies them that the program is going to steal focus and operation of the other programs, and to not mess with the mouse or keyboard until my procedure completes. It also provides the option to cancel at the splash screen and at other points during the operation. No doubt, the user knows my program is taking over.

Why should Windows be made to block my program from taking focus from other programs when the user is aware, and benefits from my "automation" of other apps?

share|improve this answer
    
the scheme I describe would allow QuickBooks to deliberately transfer focus to Excel. That's a synchronous transfer. – Krazy Glew yesterday
    
note that power uses may often be calling your application, with its splash screen, from a script that they have written. My script wants to provide input to your app - I may not want you to get that input from the actual mouse and keyboard. – Krazy Glew yesterday

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.