What’s the rule of thumb for interacting with inactive OS X window content

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?

Best Answer

^{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.