What you say about Windows users switching to the Mac platform is true: they want to use their new computer like they used to with Windows. That must not necessarily mean, though, that Apple should (or will) change their GUI to match those user's preferences. The maximising thing is discutable, no doubt about that.
But - although I know car anologies are not allowed here - imagine you lived in the US and you willingly move to the UK (because, let's hypothetically say, things are better there: less crime, better government, less taxes or whatever): you have to accept by moving to the UK that cars drive on the other side of the street. Or if you buy a (sorry, another car analogy) car with stick shift because the power gets transmitted better than with the automatic car you had - you have to accept that the two different cars don't behave the same and that certain things have to be done in a different way.
Let's face it: different products by different manufacturers are - guess what - different. And a certain effort to learn the new things must be made no matter what product you use (think of the way MS Office changes its GUI and behaviour all the time (say: ribbons instead of menus) - and that is on the same platform... But it is a newer, different product).
So you think it is faster to read a menu bar to see which app is active instead of it looking at the big square window right in front of you?
Yes, it is. Well, to be exact, you have to look at the window first, to see whether it is active or not, and - if you're still not sure if the application is the right one, then there is the application name in the top left corner of the screen. VoilÃ*!
(Or get used to using keyboard shortcuts if you can - most of those are the same in every application on the Mac platform: Command-Q (quit application), W (close window), P (print), A (select all), X (cut), C (copy), V (paste), M (hide window).
P.S. To be really exact, things about selecting windows get confused because of the following: As you have to select the text first when you want to change its font size, for example, you have to select the window in/whith which you want to do something. Then you select the command you want to execute from the menu bar - which in OS X is always at the top of the screen. So those are two steps, as in basic computing: select something and then do something with or to it (execute). For example, you can't close a tab in Safari directly (when that window is inactive) when you have a Finder window open in the foreground (i.e. active window). You must click onto the Safari window and then click the close button on the same window's tab.
In Windows, however, those two steps mentioned above are often done in one single step (I don't say which one is better, but the Windows way is a bit less logical): by selecting a command in the windows' menu, you're automatically also selecting that specific window in the same step, making that specific window become active.
Now things got really complicated in OS X since you can also close or minimize inactive windows by clicking on the red button (that turns red as soon as the mouse pointer is over the three coloured round buttons - even in inactive windows). That is, in my opinion, against the logic behind the "select and execute" metaphor - although I must also say that it saves me a lot of time and a few clicks per day.
All in all, the basic confusion around the behaviour of windows in an operating system comes from the basic question: do I have to click the window first to execute a command - or can I execute that command directly without having to select the window first.
P.S. Linux, on the other hand, usually uses a feature called "mouse over": whatever window the mouse pointer is in is the active window. You can then directly, for example, write text into that window.
Yes, it is. Well, to be exact, you have to look at the window first, to see whether it is active or not, and then - if you're still not sure if the application is the right one, then there is the application name in the top left corner of the screen. VoilÃ*!
I guess I wasn't clear because that's not what I meant. What I meant was to compare two different scenarios and see which one is faster.
Scenario one was the way OSX is currently, where you would have to do what you explain above.
Scenario two is if OSX (say, through an option) always had the active window's (in this case the window staring at you in the face) menu active. So you don't have to see if it is active. If it is in the foreground, it is the active app.
My point being that it is faster (microseconds) to identify a picture in front of you rather than moving your eyes to a specific area on the screen (upper left corner) and read a menu item. I just think it is very confusing to have a situation where an application window is in the foreground but a different application's menubar active.
I guess I wasn't clear because that's not what I meant. What I meant was to compare two different scenarios and see which one is faster.
Scenario one was the way OSX is currently, where you would have to do what you explain above.
Scenario two is if OSX (say, through an option) always had the active window's (in this case the window staring at you in the face) menu active. So you don't have to see if it is active. If it is in the foreground, it is the active app.
My point being that it is faster (microseconds) to identify a picture in front of you rather than moving your eyes to a specific area on the screen (upper left corner) and read a menu item. I just think it is very confusing to have a situation where an application window is in the foreground but a different application's menubar active.
Huh, now that is confusing now. How and when can a window be in the foreground - i.e. active - and NOT have the respective application's menu bar active? I can't think of an occasion when that happens - except fot the close/maximising thing I mentioned in the P.S. above. Do you have a reproducable example?
OK, you explained a lot of things in your P.S. I agree with everything you say, except that I think it is better to do things quickly than to stick to some GUI convention of select first, then execute. If you can do both in one action (faster) and you understand you are doing both, then why not do it faster?
I believe this is refered to as "click-through" and OSX doesn't stick to this 100% of the time itself.
On my computer, if a Finder window is open, then there is the Finder's menu bar. When Safari is open and the window is active, Safari's menu options are there. Hmm, maybe we don't agree on what "foreground" (active window, red, orange and yellow button) and "background" (inactive window, three grey close/maximise/minimise buttons) means?
Huh, now that is confusing now. How and when can a window be in the foreground - i.e. active - and NOT have the respective application's menu bar active? I can't think of an occasion when that happens - except fot the close/maximising thing I mentioned in the P.S. above. Do you have a reproducable example?
Foreground is not equal to active. Close/minimize are two occasions. Also, Ctrl+tab to an application only brings its menu active, if the app is minimized. Why not restore the window if I've Ctrl+tab to it?
On my computer, if a Finder window is open, then there is the Finder's menu bar. When Safari is open and the window is active, Safari's menu options are there. Hmm, maybe we don't agree on what "foreground" (active window, red, orange and yellow button) and "background" (inactive window, three grey close/maximise/minimise buttons) means?
These are my definitions...
Foreground is a window that is "on top" (not necessarily active). Active is an application that has keyboard control. These definitions are for both OSX and Windows.
Foreground is not equal to active. Close/minimize are two occasions. Also, Ctrl+tab to an application only brings its menu active, if the app is minimized. Why not restore the window if I've Ctrl+tab to it?
Well, now I guess I know what you mean. Actually, there is no "foreground" in OS X as there is only active and inactive windows - and those windows steer which application's menu is visible. In Windows, that's different, I know. Different terminology and different behaviour.
I do agree that OS X should have the "click-through" implemented in a better way. Closing a window is clear, that works the same on both platforms (click X in both OS's). In the end, I guess, this all comes to a matter of preference. I agree that certain people would like to see more options in how things behave concerning the windows, but I also see the danger in things getting even more out of logic in OS X when you want to have all that Windows has plus all the things as they always were in Mac OS.
That's why I think Apple will not change its OS radically in terms of window behaviour. Microsoft's way of doing this is maybe more consequent, but Apple is - and has always been - a bit different when it comes to its GUI.
"Also, Ctrl+tab to an application only brings its menu active, if the app is minimized": that is not correct, though, because not the application is minimized, but its window. If you chose "Hide Safari" in the File menu, then the application is hidden - but not minimized. If you hide an application, all the windows that belong to that application are hidden, too, including those that are down in the Dock. If you minimize a window, however, the application (and maybe also the menu bar) is still there, being still the active application until you select the window of a different application.
Basically, on the Mac, there are only three states: (1) hidden application with all windows hidden as well, (2) active application's window visible, (3) active application's window minimized. (and of course (4): visible windows that don't belong to the active application). I guess you know what I mean, I'm getting a bit confused myself now...
Foreground is a window that is "on top" (not necessarily active). Active is an application that has keyboard control. These definitions are for both OSX and Windows.
Na, that does not work for OS X. Windows is focused on the application whereas in OS X, the focus is on the windows themselves. There are only active and inactive windows - and the application is steered by whichever window is active right now. It's as easy as that. (Except for hiding, where the windows follow the application).
Scenario two is if OSX (say, through an option) always had the active window's (in this case the window staring at you in the face) menu active. So you don't have to see if it is active. If it is in the foreground, it is the active app.
You're confusing a window that you can see with a window that is the "frontmost" window. Just because you can see it does not mean it is frontmost. This is because Windows is window-oriented and Mac OS X is application-oriented.
For a window to be "frontmost", it has to be the frontmost window OF THE FRONTMOST APP. If the frontmost app has no open windows, then the window that you see really belongs to another app that is NOT frontmost.
The frontmost APP is the one whose name appears in the menu bar. If that app has one or more windows open, then the frontmost of THOSE windows will have its title bar un-dimmed and its "traffic light" lit up.
If the frontmost APP does NOT have any windows open, then any windows that you see will NOT have the "traffic light" on and their title bar will be dimmed, and they are not focus for any typing. If you click on them, their app will be made frontmost, as you can see by the change in the menu bar, and their traffic light will come on and their title bar will un-dim.
Basically, on the Mac, there are only three states: (1) hidden application with all windows hidden as well, (2) active application's window visible, (3) active application's window minimized. (and of course (4): visible windows that don't belong to the active application). I guess you know what I mean, I'm getting a bit confused myself now...
You were doing O.K. until you got here. There are quite a few possibilities:
1.) App with open windows
2.) App with open windows and minimised windows
3.) App with only minimised windows
4.) App with no open windows (minimised or not)
5 - 8.) All the above, but with the app in question hidden.
The situations that can give rise to confusion are 3.) and 4.), as the app can be active (i.e. have control of the menu bar), but any windows that you can see don't belong to that app. So if you don't notice that the window you're looking at isn't active, and don't notice the application name in the top left, you may issue a command to the wrong app.
I wouldn't say the situation is all that much better in Windows. Many application windows look similar to one another e.g. a Firefox and IE browser window, and in Windows there is no fixed convention as to where exactly the application name should appear. You can normally read it in the title bar of the window and sometimes in the task bar, but neither is a fixed place on the screen. In Mac OS X the active application name is always in exactly the same place - easy.
What doesn't work for OSX? In OSX, if you have a stack of windows open what do you call the one in front or on top?
Quote:
Windows is focused on the application whereas in OS X, the focus is on the windows themselves.
Are you sure about that? On OS X, when I minimize an window, why does the menubar of the minimized window's app stay active then? To me, this sounds like OSX is application-centric. Meaning, you've minimized a window of the app, but not quit the app itself, so the app's menubar stays the active one.
Are you sure about that? On OS X, when I minimize an window, why does the menubar of the minimized window's app stay active then? To me, this sounds like OSX is application-centric. Meaning, you've minimized a window of the app, but not quit the app itself, so the app's menubar stays the active one.
Indeed, gwoodpecker got it totally backwards on that one. Windows is window-centric, OS X is application-centric, having a proper distinction between apps and windows.
I was always looking at what happens to the window - and only then what happens to its application as a consequence. That's why I called it window-centric.
If you focus on what happens to the application, however, things get a lot more complicated and harder to explain. But technically, you might be correct.
Are you sure about that? On OS X, when I minimize an window, why does the menubar of the minimized window's app stay active then? To me, this sounds like OSX is application-centric. Meaning, you've minimized a window of the app, but not quit the app itself, so the app's menubar stays the active one.
See above.
What makes OS X different from Windows is that when you do something to the window of an application, it does not necessarily mean the application is hidden or gone or whatever. Its menu bar stays visible until you select a different application via the dock or via command-tab - or until you select the (inactive) window of another application. In that case, that window becomes active and the application's menu bar is now visible.
Hiding does the opposite: the application takes all its active and inactive windows into invisibility. So hiding and minimizing are not the same.
If you focus on what happens to the application, however, things get a lot more comlicated and harder to explain. But technically, you might be correct.
And I think that is where the confusion comes in...albiet, for Windows users/switchers. In Windows, when you think of an application, you think of, well, a window. This is not necessarily the case in OSX, where the menubar seems to be the application....er, something like that.
And I think that is where the confusion comes in...albiet, for Windows users/switchers. In Windows, when you think of an application, you think of, well, a window. This is not necessarily the case in OSX, where the menubar seems to be the application....er, something like that.
That's correct. In OS X, the application is not represented by its window(s) but by the menu bar.
#2. And I guess you can attribute it to my still fairly recent switcher status. (About 5 mos. now). Yes, when I close the last window of an app, I expect that app to quit. Still unlearning that one.
Heh. Yeah, chalk that up to practicality under Windows. The VM system is... weak. When an app has no more windows open, it auto-quits to free up resources. The VM system on MacOS X is nicely robust, so you can just leave crap open and it won't cause any problems. (Makes bringing that app up again a lot faster, obviously...) FWIW, I *HATE* the 'no windows = app quits' approach. It forces me to make sure I open my *next* document before closing out the one I'm done with. Lame? *shrug* Anyway, look at it this way - I have a single GB of RAM right now on a 4yr old PowerBook. I currently have 16 apps open for work, and somewhere between 40 and 50 windows... and no slowdowns. Leave the apps open. Heck, leave the windows open, and just hide the apps.
Quote:
So you think it is faster to read a menu bar to see which app is active instead of it looking at the big square window right in front of you?
No, I was saying that it is faster to hit, with the cursor, a target on the edge of the screen than one floating in the middle. ie, why the menu bar is at the top, on an edge, instead of wedged into each and every window. The claim that it's faster to hit the one in the window is false, and has been demonstrated to be so for about 30 years. Fitt's Law has nothing to do with the readability aspect of which window is active, and therefore which app.
For that, I have no answer for you, other than if you're looking at the window in front of you, presumably you know which app it goes with, right?
Quote:
I don't expect it to work like Windows. But I think a lot of the concepts that are used in Windows can be useful OPTIONS on the Mac.
Some, yes. But the issue that comes up is when overloading with lesser options becomes just adding crap to a good system in the name of feature creep. I've been doing UI research for almost a decade, and been a strong advocate of it for much longer - I've done quite a bit of analysis of a large number of UI features on different operating systems and window managers, and, generally, the gee-whiz features that people get so hooked on are there because they are trying to fill a *really big hole* in the UI. ie, people love them because they had a massive pain-point in their interaction with the system. Go back, figure out what the pain-point was, and plug that hole directly, and you'll be much better off.
In general, that's what Apple has done with MacOS X's UI - instead of grabbing every gee-whiz thing they can from every other OS, they took a step back, and came up with a nicely logical, hierarchical abstraction set to work from. They prevented the holes in the first place, instead of slapping a bubblegum and duct tape solution over the top and marketing it as 'innovation'. (cf: The new Ribbon up in Redmond.)
Yeah, it's different... but for very good reasons. Don't expect it to act like Windows, and instead try and understand the reasons behind the differences. You'll find a whole new level of interaction and power that simply doesn't exist on any other UI I've tried in the past 20+ years of doing this.
Quote:
And BTW, the Windows experience that I grew tired of was not with their menu-ing system, but rather the viruses, the need to reinstall every 6 months to get performance back, the need for all the security updates, the reboots.....etc.
Right. And the same company that brought you a well-designed core, to avoid those problems, brought you an equally well-designed UI layer. If you trust them on the inner layers, try trusting them on the outer ones too.
First I have been using Apple machines for over 20 years. That doesn't stop the fact that I disagree with some ways they work.
Well sure, I have things I don't particularly care for either (FTFF!), but I think it's more than a little disingenuous to say that Apple has been standing still while MS hasn't. The changes over the past few years have been huge, from top to bottom, on the Apple side.
Quote:
To try and answer your last question. I don't think Windows users who are switching really want a totally different OS. I haven't personally heard a lot of Windows users complain about the usability of Windows. If anything they complain about the viruses and the stability and all the other crap. To Windows users the way Windows works with it's taskbar and maximize is how a computer is supposed to work. Because that's what they are used to. And really you can't fault them for that.
I can't fault them for being used to something, but I do believe that the idea that "If Windows works like this, then all computers should work like this" is just an idiotic stance to have as a consumer. I don't expect a Ford and an Audi to work exactly the same. Mostly, but not exactly. And heck, that took what, almost 100 years for interfaces on cars to come to parity across most lines? My '76 Jeep had the highbeams switch on the *floor* as a foot switch. I still tap there with my left foot sometimes on my new car... but I don't expect a current car manufacturer to place a switch there just for me.
A new product requires new learning. That should be obvious.
Quote:
I know when I first swtiched back to mac with OSX I had a hard time with it's graphic elements in the dock versus reading things in the Windows taskbar. My mind had grown used to the way Windows worked and I became fast with it. My wife who uses a PC not all that long ago told me she doesn't like my computer because "it's hard to use". It's hard to use because she's not used it. And according to her she doesn't see any reason in wasting her time learning a new computer OS when the one she has works perfectly fine. Though she does like the dock magnifying and thinks the machine is nice looking.
Then that's her decision to make, isn't it? I'm not someone who thinks that the Mac is the end-all and be-all of personal computing, and that anyone who doesn't use it is a dolt. There are good reasons (a dwindling set, but there are still some) why a consumer would choose a Windows machine. If the pain of using one hasn't yet reached the point that they're looking at options, then I say let them be.
Once they've made the leap, however, I would hope that they would *not* expect a Windows experience. That just seems silly to me. I am forced to use a Windows machine at work, but I don't expect it to work like my Mac, nor do I expect there to be options to make it so. It's a different OS, a different UI, and that's that. Just because there are workflows that I am used to, doesn't mean it would be reasonable for me to demand that they be put into Windows.
Quote:
So I think that's what it comes down to. Many Windows users are drawn to Macs because of the nice hardware and some of the interesting features. Including no viruses and a more stable backend. But at the end of the day they want to be able to use the system the way they've always used it, with the option to do things differently. And if Apple really wants more Windows users they should really take a long hard look at the idea of allowing OSX to do some Windows-like things. Even if some snobby old Mac users would protest. Most mac users are open minded and would go for more options and customizing.
Ah, but which Windows-like things? Most Windows UI 'features' are poorly thought out and strangely implemented. See my above post regarding the evolution of many of those features - they expose a flaw in the underlying UI design, or simply a disregard for solid UI research. Just because it's what a potential consumer is 'used to', doesn't necessarily make it a reasonable candidate for inclusion in the Mac UI, *especially* when it adds complexity and does *not* add to the overall experience or integrity of the design.
There would have to be a compelling reason to add those features to the Mac UI, in such a way that they would make the Mac UI *better*. If not, then there's no reason to include them.
Comments
But - although I know car anologies are not allowed here - imagine you lived in the US and you willingly move to the UK (because, let's hypothetically say, things are better there: less crime, better government, less taxes or whatever): you have to accept by moving to the UK that cars drive on the other side of the street. Or if you buy a (sorry, another car analogy) car with stick shift because the power gets transmitted better than with the automatic car you had - you have to accept that the two different cars don't behave the same and that certain things have to be done in a different way.
Let's face it: different products by different manufacturers are - guess what - different. And a certain effort to learn the new things must be made no matter what product you use (think of the way MS Office changes its GUI and behaviour all the time (say: ribbons instead of menus) - and that is on the same platform... But it is a newer, different product).
So you think it is faster to read a menu bar to see which app is active instead of it looking at the big square window right in front of you?
Yes, it is. Well, to be exact, you have to look at the window first, to see whether it is active or not, and - if you're still not sure if the application is the right one, then there is the application name in the top left corner of the screen. VoilÃ*!
(Or get used to using keyboard shortcuts if you can - most of those are the same in every application on the Mac platform: Command-Q (quit application), W (close window), P (print), A (select all), X (cut), C (copy), V (paste), M (hide window).
P.S. To be really exact, things about selecting windows get confused because of the following: As you have to select the text first when you want to change its font size, for example, you have to select the window in/whith which you want to do something. Then you select the command you want to execute from the menu bar - which in OS X is always at the top of the screen. So those are two steps, as in basic computing: select something and then do something with or to it (execute). For example, you can't close a tab in Safari directly (when that window is inactive) when you have a Finder window open in the foreground (i.e. active window). You must click onto the Safari window and then click the close button on the same window's tab.
In Windows, however, those two steps mentioned above are often done in one single step (I don't say which one is better, but the Windows way is a bit less logical): by selecting a command in the windows' menu, you're automatically also selecting that specific window in the same step, making that specific window become active.
Now things got really complicated in OS X since you can also close or minimize inactive windows by clicking on the red button (that turns red as soon as the mouse pointer is over the three coloured round buttons - even in inactive windows). That is, in my opinion, against the logic behind the "select and execute" metaphor - although I must also say that it saves me a lot of time and a few clicks per day.
All in all, the basic confusion around the behaviour of windows in an operating system comes from the basic question: do I have to click the window first to execute a command - or can I execute that command directly without having to select the window first.
P.S. Linux, on the other hand, usually uses a feature called "mouse over": whatever window the mouse pointer is in is the active window. You can then directly, for example, write text into that window.
Yes, it is. Well, to be exact, you have to look at the window first, to see whether it is active or not, and then - if you're still not sure if the application is the right one, then there is the application name in the top left corner of the screen. VoilÃ*!
I guess I wasn't clear because that's not what I meant. What I meant was to compare two different scenarios and see which one is faster.
Scenario one was the way OSX is currently, where you would have to do what you explain above.
Scenario two is if OSX (say, through an option) always had the active window's (in this case the window staring at you in the face) menu active. So you don't have to see if it is active. If it is in the foreground, it is the active app.
My point being that it is faster (microseconds) to identify a picture in front of you rather than moving your eyes to a specific area on the screen (upper left corner) and read a menu item. I just think it is very confusing to have a situation where an application window is in the foreground but a different application's menubar active.
I guess I wasn't clear because that's not what I meant. What I meant was to compare two different scenarios and see which one is faster.
Scenario one was the way OSX is currently, where you would have to do what you explain above.
Scenario two is if OSX (say, through an option) always had the active window's (in this case the window staring at you in the face) menu active. So you don't have to see if it is active. If it is in the foreground, it is the active app.
My point being that it is faster (microseconds) to identify a picture in front of you rather than moving your eyes to a specific area on the screen (upper left corner) and read a menu item. I just think it is very confusing to have a situation where an application window is in the foreground but a different application's menubar active.
Huh, now that is confusing now. How and when can a window be in the foreground - i.e. active - and NOT have the respective application's menu bar active? I can't think of an occasion when that happens - except fot the close/maximising thing I mentioned in the P.S. above. Do you have a reproducable example?
I believe this is refered to as "click-through" and OSX doesn't stick to this 100% of the time itself.
Huh, now that is confusing now. How and when can a window be in the foreground - i.e. active - and NOT have the respective application's menu bar active? I can't think of an occasion when that happens - except fot the close/maximising thing I mentioned in the P.S. above. Do you have a reproducable example?
Foreground is not equal to active. Close/minimize are two occasions. Also, Ctrl+tab to an application only brings its menu active, if the app is minimized. Why not restore the window if I've Ctrl+tab to it?
On my computer, if a Finder window is open, then there is the Finder's menu bar. When Safari is open and the window is active, Safari's menu options are there. Hmm, maybe we don't agree on what "foreground" (active window, red, orange and yellow button) and "background" (inactive window, three grey close/maximise/minimise buttons) means?
These are my definitions...
Foreground is a window that is "on top" (not necessarily active). Active is an application that has keyboard control. These definitions are for both OSX and Windows.
Foreground is not equal to active. Close/minimize are two occasions. Also, Ctrl+tab to an application only brings its menu active, if the app is minimized. Why not restore the window if I've Ctrl+tab to it?
Well, now I guess I know what you mean. Actually, there is no "foreground" in OS X as there is only active and inactive windows - and those windows steer which application's menu is visible. In Windows, that's different, I know. Different terminology and different behaviour.
I do agree that OS X should have the "click-through" implemented in a better way. Closing a window is clear, that works the same on both platforms (click X in both OS's). In the end, I guess, this all comes to a matter of preference. I agree that certain people would like to see more options in how things behave concerning the windows, but I also see the danger in things getting even more out of logic in OS X when you want to have all that Windows has plus all the things as they always were in Mac OS.
That's why I think Apple will not change its OS radically in terms of window behaviour. Microsoft's way of doing this is maybe more consequent, but Apple is - and has always been - a bit different when it comes to its GUI.
"Also, Ctrl+tab to an application only brings its menu active, if the app is minimized": that is not correct, though, because not the application is minimized, but its window. If you chose "Hide Safari" in the File menu, then the application is hidden - but not minimized. If you hide an application, all the windows that belong to that application are hidden, too, including those that are down in the Dock. If you minimize a window, however, the application (and maybe also the menu bar) is still there, being still the active application until you select the window of a different application.
Basically, on the Mac, there are only three states: (1) hidden application with all windows hidden as well, (2) active application's window visible, (3) active application's window minimized. (and of course (4): visible windows that don't belong to the active application). I guess you know what I mean, I'm getting a bit confused myself now...
These are my definitions...
Foreground is a window that is "on top" (not necessarily active). Active is an application that has keyboard control. These definitions are for both OSX and Windows.
Na, that does not work for OS X. Windows is focused on the application whereas in OS X, the focus is on the windows themselves. There are only active and inactive windows - and the application is steered by whichever window is active right now. It's as easy as that. (Except for hiding, where the windows follow the application).
Scenario two is if OSX (say, through an option) always had the active window's (in this case the window staring at you in the face) menu active. So you don't have to see if it is active. If it is in the foreground, it is the active app.
You're confusing a window that you can see with a window that is the "frontmost" window. Just because you can see it does not mean it is frontmost. This is because Windows is window-oriented and Mac OS X is application-oriented.
For a window to be "frontmost", it has to be the frontmost window OF THE FRONTMOST APP. If the frontmost app has no open windows, then the window that you see really belongs to another app that is NOT frontmost.
The frontmost APP is the one whose name appears in the menu bar. If that app has one or more windows open, then the frontmost of THOSE windows will have its title bar un-dimmed and its "traffic light" lit up.
If the frontmost APP does NOT have any windows open, then any windows that you see will NOT have the "traffic light" on and their title bar will be dimmed, and they are not focus for any typing. If you click on them, their app will be made frontmost, as you can see by the change in the menu bar, and their traffic light will come on and their title bar will un-dim.
Basically, on the Mac, there are only three states: (1) hidden application with all windows hidden as well, (2) active application's window visible, (3) active application's window minimized. (and of course (4): visible windows that don't belong to the active application). I guess you know what I mean, I'm getting a bit confused myself now...
You were doing O.K. until you got here. There are quite a few possibilities:
1.) App with open windows
2.) App with open windows and minimised windows
3.) App with only minimised windows
4.) App with no open windows (minimised or not)
5 - 8.) All the above, but with the app in question hidden.
The situations that can give rise to confusion are 3.) and 4.), as the app can be active (i.e. have control of the menu bar), but any windows that you can see don't belong to that app. So if you don't notice that the window you're looking at isn't active, and don't notice the application name in the top left, you may issue a command to the wrong app.
I wouldn't say the situation is all that much better in Windows. Many application windows look similar to one another e.g. a Firefox and IE browser window, and in Windows there is no fixed convention as to where exactly the application name should appear. You can normally read it in the title bar of the window and sometimes in the task bar, but neither is a fixed place on the screen. In Mac OS X the active application name is always in exactly the same place - easy.
Na, that does not work for OS X.
What doesn't work for OSX? In OSX, if you have a stack of windows open what do you call the one in front or on top?
Windows is focused on the application whereas in OS X, the focus is on the windows themselves.
Are you sure about that? On OS X, when I minimize an window, why does the menubar of the minimized window's app stay active then? To me, this sounds like OSX is application-centric. Meaning, you've minimized a window of the app, but not quit the app itself, so the app's menubar stays the active one.
Are you sure about that? On OS X, when I minimize an window, why does the menubar of the minimized window's app stay active then? To me, this sounds like OSX is application-centric. Meaning, you've minimized a window of the app, but not quit the app itself, so the app's menubar stays the active one.
Indeed, gwoodpecker got it totally backwards on that one. Windows is window-centric, OS X is application-centric, having a proper distinction between apps and windows.
If you focus on what happens to the application, however, things get a lot more complicated and harder to explain. But technically, you might be correct.
Are you sure about that? On OS X, when I minimize an window, why does the menubar of the minimized window's app stay active then? To me, this sounds like OSX is application-centric. Meaning, you've minimized a window of the app, but not quit the app itself, so the app's menubar stays the active one.
See above.
What makes OS X different from Windows is that when you do something to the window of an application, it does not necessarily mean the application is hidden or gone or whatever. Its menu bar stays visible until you select a different application via the dock or via command-tab - or until you select the (inactive) window of another application. In that case, that window becomes active and the application's menu bar is now visible.
Hiding does the opposite: the application takes all its active and inactive windows into invisibility. So hiding and minimizing are not the same.
If you focus on what happens to the application, however, things get a lot more comlicated and harder to explain. But technically, you might be correct.
And I think that is where the confusion comes in...albiet, for Windows users/switchers. In Windows, when you think of an application, you think of, well, a window. This is not necessarily the case in OSX, where the menubar seems to be the application....er, something like that.
And I think that is where the confusion comes in...albiet, for Windows users/switchers. In Windows, when you think of an application, you think of, well, a window. This is not necessarily the case in OSX, where the menubar seems to be the application....er, something like that.
That's correct. In OS X, the application is not represented by its window(s) but by the menu bar.
#2. And I guess you can attribute it to my still fairly recent switcher status. (About 5 mos. now). Yes, when I close the last window of an app, I expect that app to quit. Still unlearning that one.
Heh. Yeah, chalk that up to practicality under Windows. The VM system is... weak. When an app has no more windows open, it auto-quits to free up resources. The VM system on MacOS X is nicely robust, so you can just leave crap open and it won't cause any problems.
So you think it is faster to read a menu bar to see which app is active instead of it looking at the big square window right in front of you?
No, I was saying that it is faster to hit, with the cursor, a target on the edge of the screen than one floating in the middle. ie, why the menu bar is at the top, on an edge, instead of wedged into each and every window. The claim that it's faster to hit the one in the window is false, and has been demonstrated to be so for about 30 years. Fitt's Law has nothing to do with the readability aspect of which window is active, and therefore which app.
For that, I have no answer for you, other than if you're looking at the window in front of you, presumably you know which app it goes with, right?
I don't expect it to work like Windows. But I think a lot of the concepts that are used in Windows can be useful OPTIONS on the Mac.
Some, yes. But the issue that comes up is when overloading with lesser options becomes just adding crap to a good system in the name of feature creep. I've been doing UI research for almost a decade, and been a strong advocate of it for much longer - I've done quite a bit of analysis of a large number of UI features on different operating systems and window managers, and, generally, the gee-whiz features that people get so hooked on are there because they are trying to fill a *really big hole* in the UI. ie, people love them because they had a massive pain-point in their interaction with the system. Go back, figure out what the pain-point was, and plug that hole directly, and you'll be much better off.
In general, that's what Apple has done with MacOS X's UI - instead of grabbing every gee-whiz thing they can from every other OS, they took a step back, and came up with a nicely logical, hierarchical abstraction set to work from. They prevented the holes in the first place, instead of slapping a bubblegum and duct tape solution over the top and marketing it as 'innovation'. (cf: The new Ribbon up in Redmond.)
Yeah, it's different... but for very good reasons. Don't expect it to act like Windows, and instead try and understand the reasons behind the differences. You'll find a whole new level of interaction and power that simply doesn't exist on any other UI I've tried in the past 20+ years of doing this.
And BTW, the Windows experience that I grew tired of was not with their menu-ing system, but rather the viruses, the need to reinstall every 6 months to get performance back, the need for all the security updates, the reboots.....etc.
Right. And the same company that brought you a well-designed core, to avoid those problems, brought you an equally well-designed UI layer. If you trust them on the inner layers, try trusting them on the outer ones too.
First I have been using Apple machines for over 20 years. That doesn't stop the fact that I disagree with some ways they work.
Well sure, I have things I don't particularly care for either (FTFF!), but I think it's more than a little disingenuous to say that Apple has been standing still while MS hasn't. The changes over the past few years have been huge, from top to bottom, on the Apple side.
To try and answer your last question. I don't think Windows users who are switching really want a totally different OS. I haven't personally heard a lot of Windows users complain about the usability of Windows. If anything they complain about the viruses and the stability and all the other crap. To Windows users the way Windows works with it's taskbar and maximize is how a computer is supposed to work. Because that's what they are used to. And really you can't fault them for that.
I can't fault them for being used to something, but I do believe that the idea that "If Windows works like this, then all computers should work like this" is just an idiotic stance to have as a consumer. I don't expect a Ford and an Audi to work exactly the same. Mostly, but not exactly. And heck, that took what, almost 100 years for interfaces on cars to come to parity across most lines? My '76 Jeep had the highbeams switch on the *floor* as a foot switch. I still tap there with my left foot sometimes on my new car... but I don't expect a current car manufacturer to place a switch there just for me.
A new product requires new learning. That should be obvious.
I know when I first swtiched back to mac with OSX I had a hard time with it's graphic elements in the dock versus reading things in the Windows taskbar. My mind had grown used to the way Windows worked and I became fast with it. My wife who uses a PC not all that long ago told me she doesn't like my computer because "it's hard to use". It's hard to use because she's not used it. And according to her she doesn't see any reason in wasting her time learning a new computer OS when the one she has works perfectly fine. Though she does like the dock magnifying and thinks the machine is nice looking.
Then that's her decision to make, isn't it? I'm not someone who thinks that the Mac is the end-all and be-all of personal computing, and that anyone who doesn't use it is a dolt. There are good reasons (a dwindling set, but there are still some) why a consumer would choose a Windows machine. If the pain of using one hasn't yet reached the point that they're looking at options, then I say let them be.
Once they've made the leap, however, I would hope that they would *not* expect a Windows experience. That just seems silly to me. I am forced to use a Windows machine at work, but I don't expect it to work like my Mac, nor do I expect there to be options to make it so. It's a different OS, a different UI, and that's that. Just because there are workflows that I am used to, doesn't mean it would be reasonable for me to demand that they be put into Windows.
So I think that's what it comes down to. Many Windows users are drawn to Macs because of the nice hardware and some of the interesting features. Including no viruses and a more stable backend. But at the end of the day they want to be able to use the system the way they've always used it, with the option to do things differently. And if Apple really wants more Windows users they should really take a long hard look at the idea of allowing OSX to do some Windows-like things. Even if some snobby old Mac users would protest. Most mac users are open minded and would go for more options and customizing.
Ah, but which Windows-like things? Most Windows UI 'features' are poorly thought out and strangely implemented. See my above post regarding the evolution of many of those features - they expose a flaw in the underlying UI design, or simply a disregard for solid UI research. Just because it's what a potential consumer is 'used to', doesn't necessarily make it a reasonable candidate for inclusion in the Mac UI, *especially* when it adds complexity and does *not* add to the overall experience or integrity of the design.
There would have to be a compelling reason to add those features to the Mac UI, in such a way that they would make the Mac UI *better*. If not, then there's no reason to include them.