Aqua Inconsistency

laguila

laguila

http://www.5th-Sun.com/
I have a bit of a problem with a part of Aqua that I wanted to get opinions on. The problem isn't so much with the inconsistency, as much as the apparently arbitrary nature of it.

Why is it that the mouse pointer can action some of the controls in a non-active window and not others? Specifically, why can you close a non-active window using its top-left red control, but not activate a link on a non-active browser page?

Arguments could be made for either option (having that ability all the time vs. not having that ability all the time) but I don't think you can really defend a choice where you sometimes have this ability to activate controls. Is there one?

I'm open to other points of view.
 
Specifically, why can you close a non-active window using its top-left red control, but not activate a link on a non-active browser page?
Click to expand...

I love the feature that allows you to close, maximize or minimize windows that are behind your active window. That said, I don't think I'd like to see it apply to the Windows contents. It would be way to easy (especially with all that transparency) to accidentally click on a background pages items/links/etc. It also breaks the whole Window metaphor. The concept of being able to close background windows from a foreground window only bends the metaphor, it doesn't break it.
 
I see 2 solutions to your problem.

(a)
You have to activate the window before being able to do anything else with it, including closing, resizing, iconifying it. Most people wouldn't like that I guess. I wouldn't mind - and in fact usually do exactly this. (eg first activate it, then close it)

(b)
Clickling somewhere on the window not only activates it but also executes whatever action is under the mouse. While this sounds acceptable in the case of the close-button, it would be extremely annoying for the rest of the window. When I click in the content-area of an unactivated editor-window, I want to activate it only, NOT position the text cursor to whereever I clicked in the window!

So, while I could live well with option (a) I would um.. dislike option (b)

Sargon
 
I'm a little surprised at the negative reaction to being able to affect controls in non-active windows. Why is that such a bad thing? (I can certainly find uses for it!)

As far as "bending" vs "breaking" a metaphor: that's exactly the arbitrary behaviour I have a problem with! Who decides when a "bend" becomes a "break"?
 
Originally posted by laguila
I'm a little surprised at the negative reaction to being able to affect controls in non-active windows. Why is that such a bad thing? (I can certainly find uses for it!)
Click to expand...

You said the answer yourself: NON-ACTIVE windows. This implies that in order to react with the window contents, you need to activate it.

I would argue that closing/ minimizing a non-active window is not interacting with the window contents. You are simply changing a position of the window, and not changing the state of the window content.

So.... Aqua allows you to change the state of any window at any time. It never allows you to change the state of the window content unless that window is the active window.

Does that make sense?

FaRuvius
 
Like FaRuvius said, you aren't altering the contents of the window, you're altering the window itself. With that said, I can cite many things that you can do with inactive windows, but all do not control any of the content.

1) Window widgets. Minimize, close, or maximize an inactive window. Note that you can also hide and show the toolbar of an inactive window using the long button on the right side of the window title bar.

2) Move the window. Command click & hold on the title bar of an inactive window (make sure you aren't activating the popup window of the Finder to show the path, or similar function). Now drag the window around.

3) Change the toolbar (!). Once again, command click on buttons of a toolbar of an inactive window and you can change the position of the buttons, or you can take them off entirely.

Note that all 3 of these things do not alter the window contents, as FaRuvius pointed out. So there's no inconsistency here.
 
Yes, I understand your argument, but what you haven't explained is why that's better or good.
 
a) I have often wanted to be able to activate a link in a non-active window.

b) I have never wanted to change the toolbar of a non-active window.

Why is it better UI design that I not be able to do (a) while being able to do (b)?
 
Whether a program can respond to a click in the background has to do with a bit that is set in the program.

As the program is clicked on, and brought to the foreground, the bit tells the OS whether to ignore the click, or give it to the program (so the buttons get pressed, or something gets hilighted, whatever).

In some programs it doesn't make sense to react to the click when in the background. In some programs it's fine.

Try clicking on a Finder icon when it's in the background. It highlights before the Finder comes to the front. Now try clicking on a toolbar icon when the finder's in the background .. notice nothing happens, the window just comes to the front.

Since Apple's UI guidelines tell programmers to deactivate buttons & other controls while in the background, generally they won't respond to clicks in the background. I can't think of too many situations where I'd want a button to press in the background anyway.

By the way, this isn't Aqua behavior, it's been a function of the OS since Multifinder in System 6.


Minimizing windows is a feature of the window manager. Most programs shouldn't care what shape, size, or "minimization" state the window is in, so it doesn't matter whether you do it in the foreground or not. If a file needs to be saved, the program waits until you click "Save" before it closes the window, just like it does in the foreground.

The windows in OS X are much better "integrated" then they were in the classic model. You might notice that you can Command-Drag to move a window around in the background too*. That's way more useful than minimzing, imho.

* you could do this in previous OS's too, but only in the same program .. in X you can do it with any window you can see.
 
OK: here's why it's better to not allow content manipulation of inactive windows.

Suppose I wanted to change to an OmniWeb window, and I click on a part that has a link. Instead of switching to that window, the browser would go to another page: annoying!

This could get worse if you accidentally do something you don't want to do to the content of a crucial file, or something.

Basically, it's a security measure. If you could manipulate everything in the background, everything would get messed up, and you wouldn't know what happened to everything. Plus, it only takes one click to make an active window inactive.
 
This thread says 'inconsistency' in Aqua. I guess there are other 'features' to find that truly ARE inconsistent with other ones in Aqua. The one mentioned here is perfectly consistent. The system controls the outer elements of the window while the app controls the content of the window.

And you can change this behaviour as the developer of an application. For example iTunes reacts in background when you hit play or stop and then activates the window. This makes sense in that application. As mentioned before by others: We don't want to activate links in browser windows by accident, and we also don't want the cursor in a text editor, the focus of the text cursor in a database app and the like (also in design applications, I don't want to move objects by accident...).

It's not an inconsistency of Aqua, it's a feature. :) And I just today thought about how great it is and how quick OS X reacts to those close-that-window clicks. I was much slower closing popup windows in a browser under OS 9 than I'm now. :)
 
OK, OK, OK! :)

As I said at the start of this "I'm open to other points of view."

The more I think about it, the more I agree that this behaviour probably prevents more confusion than not.

Generally speaking, I see more and more that interfaces really are never either right or wrong, but a reflection of the particular priorities (conscious or not) that went into the design.

Thanks for all your comments!
 
You must log in or register to reply here.
Back
Top