Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

In most operating systems, there is a major distinction between:

  • interactions which are available only when the element is in focus (for example typing in order to write a text in a text field) and:

  • interactions which are available at any moment (for example clicking on a button).

Being able to click anywhere, including on a non-active window, is sometimes disturbing. In fact, windows on background are usually not entirely visible, and clicking on them would have a risk of interacting with the window itself, instead of bringing the window to the front.

For example, if Windows Live Messenger discussion window is covered by the browser so that only the bottom is visible, activating the window by rapidly clicking on it becomes a random process, since it is possible, by mistake, to click on a button with an irreversible effect, like Voice call (see screenshot), given that the button is:

  • not recognizable as Voice call button, since you don't see neither the icon, nor the text.

  • not recognizable as a button, since the border is not shown until the cursor is over it.

The screenshot shows Windows Live Messenger window with its Voice call button. The window is covered by browser's window.

The alternative to the default behavior of being able to interact directly with inactive windows would be to disable elements on inactive windows.

  • The advantage would be that instead of pointing precisely on a non-interactive zone of a window (here, the small zone between the bottom of the window and the buttons of Windows Live Messenger), the user would be able to click anywhere on an inactive window to activate it.

  • Another advantage is that there is no confusion in the click action. Currently, depending on the state of the window, a click on a button may either start the button click event (if the window is already active), or both activate the window and start the click event (if the window was not active).

  • The problem is that it requires two clicks to interact with a window in cases where the goal is to interact with a well-visible element of a window. This is often the case when working with two applications or documents, side by side.

  • Another problem is that the visual response (disabled button) wouldn't be clear for sure: is it disabled because you can't interact with it, or because its window is inactive?

Questions:

  1. What may be the implications in terms of user efficiency, if any element of a window were disabled when the window is inactive?

  2. Are there applications which are actually disabling their controls when becoming inactive? Were their approach considered ineffective, UX-wise?

share|improve this question
2  
When considering efficiency you have to note you're also adding a click to every possible cross-window action, which can add up quick –  Ben Brocka Nov 7 '12 at 19:42
    
OS X actually tackles this issue nicely; Seeing as windows are effectively stacked upon one another, clicking on an inactive window (accidental or not), then activates that window and brings it to the foreground. This process then, avoids any unwanted actions such as selecting a button or inputting text etc, as the initial click only serves to activate the window. –  Daniel Meade Nov 7 '12 at 19:47
add comment

2 Answers

up vote 4 down vote accepted

There are two different parts to your question.

The first is whether it's more efficient to disable controls in inactive windows. I'd suggest that it isn't, because disabling a control means that it has no content worth the users attention - disable != readonly. In most cases a background window does have content the user may want to reference, concealing that information would make things much harder to use.

The second is whether it's a good idea to "swallow" the first click on a window, so that users don't inadvertently activate things they may not want. I think this is a great idea - and so does Microsoft (well, the Office team, anyway), as Microsoft Office does this throughout.

Try overlapping a Word or Excel window with other windows and see what clicking on the Office window does - doesn't matter where you click, it just activates the window. More applications should emulate this approach, IMHO.

share|improve this answer
    
I haven't noticed before that Microsoft Office applications were ignoring the first click. Great example. Thank you. –  MainMa Nov 8 '12 at 1:24
add comment

Great question (especially the part about accidentally clicking on an action button when selecting the inactive window).

I think it makes sense to disable/grey-out the inactive windows (the ones that are not currently receiving the user's input (mouse, keyboard and most importantly, attention) ONLY if they are overlapping each other even if it's just by a few millimeters. So the user knows just by looking at the partial view of the window behind the current active window, that it's disabled since it will look disabled with greyed-out icons and buttons and text, etc.

So clicking on the inactive window (anywhere on the window should work since the buttons & content are all disabled) will serve only one purpose - bringing it to life and then on it shall be the active window.

I must acknowledge that it would be an interesting programming challenge to detect if the windows are overlapping in the screen but it's certainly doable.

This way if the user is trying to work with two applications/windows side by side, they wouldn't have to click twice to activate one or the other.

Hope that helps.

share|improve this answer
    
isn't overlap check the same as a simple overlapping rectangles check done in the windowing system? –  ratchet freak Nov 8 '12 at 9:07
add comment

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.