Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

I have to admit I'm a bit mystified in trying to understand one particular part of the OS X user interface: interacting with content in "inactive" windows.

For example, let's say we have Chrome & Safari each taking up 50% of the viewable screen estate. We're "in" Chrome and want to click a link in Safari - why the need to click twice? (once to activate Safari, again to interact with the link)

In other operating systems, clicking anything that's viewable will generally "just work". I can understand Mac OS shielding a user from having to account for their every errant click, but it seems that OS X's "interface" elements only require one click (hitting "play" in iTunes, closing a tab in Firefox, etc.), which are ironically the actions that carry the most dramatic consequences if clicked accidentally.

Is there some method to this madness or am I forever to have to click and anxiously wait to see if I need to click again?

share|improve this question
1  
Gruber wrote a good piece on this. It's called "click-through" daringfireball.net/2003/05/the_problems_with_click-through –  Paul Eccles Aug 2 '11 at 7:24
    
A good piece in 2003 :) It's interesting to see how the OS X UI has (and hasn't) changed since then. –  jtbandes Aug 2 '11 at 7:31
    
I'd also like to add: it helps to keep your hand on command-tab! –  jtbandes Aug 2 '11 at 7:37
add comment

1 Answer

up vote 3 down vote accepted

Sit, my children, and let me tell you of the world and its tricks...

Scrolling

You can basically always scroll inactive window content. I can't even think of a case where this isn't true. (This also means that scroll-to-navigate works in Lion.)

Dragging

In many cases, you can drag content from inactive windows/apps without focusing the app. For example, you can drag a file from Finder or a message from Mail.

Clicking

When you click a button that's on a window, it usually "accepts first mouse events" — meaning your mouse-down will both focus the window and act as a mouse-down event on the button. Then when you let go, the button will carry out its duty.

(Also note: in the case of the close/minimize/zoom widgets,

you can actually click them without focusing the window.)

(Second aside: in toolbars, it's not uncommon to disable some buttons while they're inactive, so you don't accidentally click them — take Mail's delete button, for instance. However, this functionality is slightly broken in Lion, because if you start clicking (so the window focuses) and then drag, you can actually still activate the button.)

However, this mostly only works for buttons. As you've noticed, when you try to click a link (or select text, or another similar action), you have to focus the window first by clicking, and only then can you interact with the content.

The Great Workaround

(or the rule of thumb, as you say; hehe)

To get to the point: In most cases, when you hold down ⌘ Command, you can interact with inactive window content. You can hold down and select (and even drag) text in the background, drag things around (including scrollbars!), click buttons, and more, without activating the window.

"But wait!" I hear you say. "Holding down opens links in a new tab!" Ay, there's the rub:

When you hold down and click a link in Safari or Chrome, it will work without activating the window... but the link will open in a new tab.

And to my knowledge there's no Great Workaround for that, unless you want to disable -clicking in your browser.

There you have the facts — make the workflow you will of them!


An update, quoting some content from Apple's Human Interface Guidelines (this is just for reference, not to prove a point):

Avoid providing click-through for an item or action whose result might be dangerous or undesirable. Specifically, avoid enabling click-through for an item that:

  • Performs a potentially harmful action that users can’t cancel (for example, the Delete button in Mail)
  • Performs an action that is difficult or impossible to cancel (such as the Send button in Mail)
  • Dismisses a dialog without telling the user what action was taken (for example, the Save button in a Save dialog that overwrites an existing file and automatically dismisses the dialog)
  • Removes the user from the current context (for example, selecting a new item in a Finder column that changes the target of the Finder window)

Clicking in any one of these situations should cause the window that contains the item to be brought forward, but no other action to be taken.

In general, it’s safe to provide click-through for an item that asks the user for confirmation before executing, even if the command ultimately results in destruction of data. For example, you can provide click-through for a delete button if you also make sure to give users the opportunity to cancel or confirm the action before it proceeds.

Think twice before supporting click-through for items that don’t provide confirmation feedback. Specifically, consider how dangerous the action might be, and determine how difficult it will be for the user to undo the action after it’s performed. For example, the Mail Delete button does not provide click-through because it deletes a message without asking for confirmation, which is a potentially harmful action that can be difficult to undo. On the other hand, click-through for the New button in Mail is fine because its resulting action is not harmful and is easy to undo.

Ensure that items that do not support click-through appear disabled when their window is inactive. The disabled appearance helps users understand that these controls are unavailable. For example, the delete and mark as junk buttons in the inactive Mail window shown below do not support click-through.

share|improve this answer
    
Your Great Workaround seems to be in line with any sort of "augmented click", along the lines of right-clicking (which brings up a contextual menu for a link in a background window, not the window itself). While this is helpful info, I'm looking for some sort of rhyme or reason behind this behavior in general, whereas all I'm seeing are inconsistencies. –  Samuel Hulick Aug 2 '11 at 7:40
1  
To be an apologist: I guess the idea is that most of the time when people click on apps, they want to focus them. Apple tends to cater to "most of the time", most of the time. It's not totally inconsistent to hold a modifier key while you're doing something to get a little extra functionality (like holding option when clicking certain menu extras, etc.). So I'm pretty sure it wasn't Apple's priority to allow interaction with inactive windows, because come on, why would you (most people) ever want to? And now I'm curious, what would your ideal interaction model look like? –  jtbandes Aug 2 '11 at 7:56
    
Regarding inconsistency: I can't speak for other operating systems, but I think the key point here is that: it works for buttons and other system controls; it doesn't work (without holding command) for other (usually text-based) content, including web pages. –  jtbandes Aug 2 '11 at 7:57
    
I've updated my answer with a quote from the HIG on this topic. –  jtbandes Aug 2 '11 at 8:02
    
You get my vote with the HIG reference - thanks for finding that! –  Samuel Hulick Aug 4 '11 at 11:37
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.