Non-Windows users might also not have their browser take up the entirety of the screen. I'm running on 1920x1200 here, but my web browser is only 1200-odd wide, maybe 900-odd tall.
In my experience (and yes, anecdote is not the singular of data), Windows users run everything in maximised, full-screen mode. Mac OS users have overlapping windows. Linux users do whatever seemed reasonable to whoever wrote their window manager.
Quite why this is I couldn't say; if you pushed me, I'd say it was to do with Fitt's law (http://en.wikipedia.org/wiki/Fitts's_law), and more specifically the fact that in Mac OS the menu bar is always at the top of the screen, and therefore very easy to hit, because if your mouse goes up too far that doesn't matter. Windows applications have the menu at the top of the window, so people tend to maximise their windows to fit the entire screen to get the same effect. (Perhaps because you don't need to do this so much, the maximise button on Mac OS only makes the window as big as it needs to be, not as big as the screen.)
The menu bar always being at the top regardless of where the window is is one of those crippling UI failures that Macheads keep telling me is a "feature". Dammit, disassociating the controls from the window and making it impossible to reach more than one control set at a time *and* making it difficult to tell which control set is "live" is MUCH worse than the marginal advantage you get by pinning the menu to the top so that imprecise clickers have an easier time clicking imprecisely. And said imprecise clickers then have to click precisely again to select the correct entry *on* the menu, so it's not like you're lowering any ACTUAL attention requirements in practice.
Grr, argh.
(Worse UI fail: Closing the window *does not stop the program*. This is WRONG AND BACKWARDS. If I wanted the program to keep running while the window just disappeared, I'd have used MINIMISE, not CLOSE. Close means STOP, dammit.)
But I suspect you find more Mac users running multiple windows that way because Macs are a closed hardware environment that sacrifices a great deal in favour of "looking good" - which means that Macs tend to have large screens with a high resolution and the ability to hold multiple windows at a decent size each. Combine that with the deliberate by-design crippling of your ability to switch to programs that you can't see and click on an active window of? It makes MUCH more sense to have multiple small windows open all the time.
With Windows users who get similar screen real estate, what I find is multiple non-maximised windows, all placed so that if they do overlap, it's a single click at a place just past the edge of the previous window to bring the new one to the front. Which is, really, similar to the way the Mac users do it.
(Windows 7's various "pin to whereever" functions are just plain useful, for this - drag a window to the top of the screen and it maximises. Drag it to the left or right and it resizes to take up half the screen. It's simple, it's easy, the UI shows you what will happen when you release the button before you do it - it's the kind of UI changed that I like because it's small and unobtrusive and Just Works.)
Also: If you find the menu too small to click easily, the solution is not to keep it the same size, disassociate it from the object it controls, and smash it up on the top to take advantage of the "infinite vertical space". No, the solution is to provide OPTIONS to MAKE THE MENU BUTTONS BIGGER for the people who need that.
But, hey, options and configuration and usability concerns aimed at real users? Can't have THAT, this is a MAC!
While selecting a menu entry once you've got to the right part of the screen is indeed no faster or easier on Mac OS than on Windows, the point of Fitt's Law is that it's much faster and easier to get to the menu bar from wherever your mouse pointer might be.
As for closing the window == quitting the application, I think that makes sense in a situation where you have multiple levels of windows, as you do with a multiple document interface. Closing child windows == closing a document; closing the parent window == closing the application. Fine. But if you don't have the metaphor of a parent window (because you don't need a special window to put the menu bar in - this also lets you interleave multiple windows belonging to different applications), then you need another way of saying "OK, I'm done with this application now".
For some applications where there's one window, and that window pretty much is the application, quitting when you close that window makes sense, so that's what Mac OS applications do (e.g. System Preferences, Calculator.) For any application that can have multiple similar windows open at the same time (e.g. any web browser, any document editor), it makes more sense to have an explicit quit option, and stay running if someone closes the last window (possibly because they're about to open a new one, and that last window they closed was the blank Untitled document that opened up when the application first started up, or when they clicked on the Dock icon and the application didn't have any windows currently open).
And yeah, you can either use the dock or command-tab to switch between applications, even if they don't have windows open.
the point of Fitt's Law is that it's much faster and easier to get to the menu bar from wherever your mouse pointer might be.
Except it's *not* easier to go "to the top of the screen" if you're working in the bottom corner. It's much easier to get to the top of your workspace, which should only be "the top of the screen" if your WORKSPACE is at the top of the screen. It's a shorter distance to something closer to both your cursor and the focal point of your attention. The Mac way of doing things is *inefficient* and *counterintuitive*, as well as *slow*.
But if you don't have the metaphor of a parent window
Of course you do - the last window of the application, exactly like how *all* sane multi-window applications have worked, for decades.
you need another way of saying "OK, I'm done with this application now".
Closing all the instances of the application isn't enough?
(Hint: It's enough. Applications that don't close when you close all their windows *are wrong*. You closed all the windows! You have STOPPED USING THAT PROGRAM! It should damn well *exit* and free up the resources for programs that you ARE USING. There are a VERY few exceptions - things like an IM client where the window you closed is not the sole functionality of the application. The application is meant to sit in the background and provide a service, and the fact that you closed the "select people to chat with" window actually *doesn't* mean you're done with the app. But a web browser or a document editor? Those DO NOT provide services while closed and SHOULD NOT be doing a damn thing while you're not using them.)
And yeah, you can either use the dock or command-tab to switch between applications, even if they don't have windows open.
The dock is an extra-special level of bad - an extremely limited number of icons, combined with minor graphical effects to tell you "running/not running", combined with icons that move and dance when you're trying to get to them so they're NO LONGER WHERE THEY WERE WHEN YOU STARTED YOUR MOUSE MOVEMENT? Ugh.
I mean, the Start menu in 7 "scrolls open" by default, but it only changes when you click on it, it goes *fast* because they understand that chasing a moving icon is a pain in the ass, and the scrolling behaviour is a single checkbox to turn it into straight "snap open/closed without animation"
The point of Fitt's law is that it's easier to hit a larger target than a smaller one. When applied to clicking on something with a mouse, though, you have to also bear in mind that when the mouse pointer hits the edge of the screen, it stops. So the small 40-odd pixel high menu bar at the top of the screen may well be hundreds or thousands of pixels high; you could aim at any point at or above the menu bar, and your mouse pointer would end up over it, no matter how accurate or inaccurate you were.
It's the same reason the Windows Start button is in a corner of the screen: it's very, very easy to hit.
And when I was talking about multiple levels of windows, parent and child windows, I meant multiple levels of windows: one large window which contains the menu, and in turns contains document windows (see Wikipedia (http://en.wikipedia.org/wiki/Multiple_document_interface), criticism (http://www.pixelcentric.net/article.php?art=docs)). Like, say, this screenshot I randomly grabbed off the Web (http://www.datacad.com/products/Whats_New_files/MDI.jpg). In this case, closing each individual document shouldn't (and doesn't) quit the main application; only closing the enclosing window, or choosing the Quit or Exit menu option, closes the application.
But however you present it, I think that on a desktop operating system, where you start up and quit applications, the consequences of closing a document window should be consistent, simple and painless. Why should the application quit I close a window if that was the last one, but not if I had another open? Why should there be a difference between a) opening a new window and then closing the previous window (that works), and b) closing the old window (the application quits), restarting the application, remembering not to close the random untitled empty document it's just opened, opening a new window, and closing the untitled document?
Oh, and the annoying magnification effect in the Dock was always something you could turn off, and is no longer the default option, if it ever was. I think the latest versions of Mac OS also make running applications clearer.
No, I'm talking about something fundamentally different.
It's easier to hit a large target than a small one, but it's also better for your target to be near your work area and attention focus than far away. You could put The One Button That Does Everything in the corner of the screen (the way Windows does, for example), and that's not going to help you in the slightest when you want *your program's options*.
So the small 40-odd pixel high menu bar at the top of the screen may well be hundreds or thousands of pixels high; you could aim at any point at or above the menu bar, and your mouse pointer would end up over it, no matter how accurate or inaccurate you were.
You still have to hit left-right carefully, and you still have to precise with your up-down selection once the menu opens and you are choosing the option you want. You're not fixing anything except the first initial click of what's necessarily at least a two-click process - AND you've eliminated a lot of the one-click options.
Fundamentally, if the problem is that the option are too small and difficult to hit, planting them against a screen barrier does help to make them "bigger" in one respect, but makes things *more* difficult because you now have to go all the way to that barrier every single time AND now you have all your applications competing for the same bit of real estate AND you've severely limited the ability of the user to access different options in different programs quickly and seamlessly. So you've partially solved one problem by creating THREE OTHERS, and all three of the ones you've created are worse than the original.
You've looked at the problem of "it's very bright outside" and decided that your solution should be "becoming predominantly nocturnal and wearing a blindfold at all times", not "sunglasses"
In this case, closing each individual document shouldn't (and doesn't) quit the main application; only closing the enclosing window, or choosing the Quit or Exit menu option, closes the application.
In that case, though, the "child" windows are children of the parent object, like tabs in a web browser. They're not multiple windows, like, say, having two Word documents open.
the consequences of closing a document window should be consistent, simple and painless.
I agree. You're being misleading by conflating "document sub-window" with "window", however, and you're ignoring that in that app, if you *do* close the "main" window, the program stops. Which is not the case in the annoying behaviour I'm describing.
Why should the application quit I close a window if that was the last one, but not if I had another open?
Because you just closed the application.
Why should there be a difference between a) opening a new window and then closing the previous window (that works), and b) closing the old window (the application quits), restarting the application, remembering not to close the random untitled empty document it's just opened, opening a new window, and closing the untitled document?
I have a different question: Why are you *complaining* when you give a quit program command and the program quits, and then you give a Create New Document command and it creates a new document, and then you finally give the Open Existing Document command and it opens the existing document?
The program is doing *exactly what you told it to do*, and you just gave it a stupid series of commands to get what you actually *wanted* it to do.
This is CORRECT, DESIRABLE BEHAVIOUR. The Mac habit of "I know better than you do what you wanted, so I'm not going to do what you told me to" is *bad*.
To paraphrase a complaint from many years ago: When I want toast, I put bread in the toaster. I do not wave bread at my kitchen and hope it figures it out. And my kitchen had DAMN WELL BETTER not say "Oh, you gave me this bread and told me to put it away. I know! You REALLY want toast, despite specifically telling me something different! I'll make toast."
I don't understand why you want to access different menu options for different applications in rapid succession. Or, if you do (e.g. to open each application's Preferences dialogue box?), why each application's menu bar being in a different place would help you do this. Surely there's more mousing around?
(Acorn's Risc OS, that ran on the Archimedes and Risc PC series of computers, had a three-button mouse and used the middle button for 'Menu', so you could click anywhere in an application's window, or in its Icon bar [sort of dock homologue] icon, and get a menu, which avoided all of this hunting down the application menu problem. At the expense of all menus being multi-level, and requiring you to have and understand multiple buttons on a mouse.)
It's not that you necessarily want them all in quick succession, it's that you might want to go directly from app A to the menu of app B.
Disassociating the controls from the application is bad. Forcing all the controls on top of each other is bad. The usability improvement in "making the target larger" by giving it infinite vertical space without increasing horizontal space is very much *not* enough to offset the usability decline.
You keep on begging the question. Of course, if the only true way to do things is "the menu bar must be attached to the main window of an application", then it logically follows that Mac OS disassociates the controls from the application. (I'm not sure if it necessarily follows from there that it "forces all the controls on top of each other", though, given that you can only ever see one menu bar at once. It's not like you could misclick and accidentally get the wrong application's Help menu, say.)
Conversely, though, if you assume that the menu bar must always be at the top of the screen and change depending on which application is active, then you will indeed be confused when confronted with a number of Windows applications not running full-screen, where the menu bar jumps around from one part of the screen to another depending on which application you're in. (That's if you have a menu bar at all, visible or invisible, but that's another UI issue.)
(As an aside, if you have all windows maximised, then barring menu bar skulduggery from applications perhaps trying to be too clever, your menu bar will indeed always be in the same place at the top of the screen, just like a Mac. I've seen enough people do this that I suspect there might be a reason for it - other than the historically bad multi-level window concept that Windows started out with, which made it difficult to interleave windows from different applications, and therefore difficult to compare windows side by side or drag and drop between two apps).
As for going directly from application A to the menu of application B, is your point really that it's hard to switch applications unless you can click on another application's menu bar? I mean, let's say that for some reason you decided that what you wanted to do in another application was to choose a non-trivial menu option (not, say, Quit or Exit, which there are common shortcuts in both Windows and Mac OS for), but not make sure that you had first put the cursor in the right place in the second application's document, or selected some part of that document. (In which case you're trying to switch to another window, do things, then find a menu option, at which point your mouse pointer is so far away from where it started off that where the menu bar of the second application is is probably a moot point.) Are you actually saying that you make a point, in your everyday life, of lining up your windows in such a way that you can see each of their menu bars from other windows? Not just some part of the window so you can click on it, but the entirety of the menu bar?
I really do think that being able to rely on the menu bar always being in the same place (a region which is easy to get to from wherever your mouse pointer might be), and as consistent as possible (e.g. File, Edit, Help share basic similarities in every application, Preferences is always in the same place rather than randomly being under Edit, Tools or Options) is a big win.
Oh, and the annoying magnification effect in the Dock was always something you could turn off, and is no longer the default option, if it ever was. I think the latest versions of Mac OS also make running applications clearer.
Correcting the annoying animation and making running apps "clearer" does not change that the Dock is fundamentally a usability and interface nightmare from the concept on up. Whee, the turd has been polished, slightly.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2010-04-16 02:56 pm (UTC)(no subject)
Date: 2010-04-16 03:33 pm (UTC)(no subject)
Date: 2010-04-16 03:41 pm (UTC)Quite why this is I couldn't say; if you pushed me, I'd say it was to do with Fitt's law (http://en.wikipedia.org/wiki/Fitts's_law), and more specifically the fact that in Mac OS the menu bar is always at the top of the screen, and therefore very easy to hit, because if your mouse goes up too far that doesn't matter. Windows applications have the menu at the top of the window, so people tend to maximise their windows to fit the entire screen to get the same effect. (Perhaps because you don't need to do this so much, the maximise button on Mac OS only makes the window as big as it needs to be, not as big as the screen.)
(no subject)
Date: 2010-04-16 04:12 pm (UTC)Grr, argh.
(Worse UI fail: Closing the window *does not stop the program*. This is WRONG AND BACKWARDS. If I wanted the program to keep running while the window just disappeared, I'd have used MINIMISE, not CLOSE. Close means STOP, dammit.)
But I suspect you find more Mac users running multiple windows that way because Macs are a closed hardware environment that sacrifices a great deal in favour of "looking good" - which means that Macs tend to have large screens with a high resolution and the ability to hold multiple windows at a decent size each. Combine that with the deliberate by-design crippling of your ability to switch to programs that you can't see and click on an active window of? It makes MUCH more sense to have multiple small windows open all the time.
With Windows users who get similar screen real estate, what I find is multiple non-maximised windows, all placed so that if they do overlap, it's a single click at a place just past the edge of the previous window to bring the new one to the front. Which is, really, similar to the way the Mac users do it.
(Windows 7's various "pin to whereever" functions are just plain useful, for this - drag a window to the top of the screen and it maximises. Drag it to the left or right and it resizes to take up half the screen. It's simple, it's easy, the UI shows you what will happen when you release the button before you do it - it's the kind of UI changed that I like because it's small and unobtrusive and Just Works.)
(no subject)
Date: 2010-04-16 04:14 pm (UTC)But, hey, options and configuration and usability concerns aimed at real users? Can't have THAT, this is a MAC!
I get stabby.
(no subject)
Date: 2010-04-16 05:02 pm (UTC)As for closing the window == quitting the application, I think that makes sense in a situation where you have multiple levels of windows, as you do with a multiple document interface. Closing child windows == closing a document; closing the parent window == closing the application. Fine. But if you don't have the metaphor of a parent window (because you don't need a special window to put the menu bar in - this also lets you interleave multiple windows belonging to different applications), then you need another way of saying "OK, I'm done with this application now".
For some applications where there's one window, and that window pretty much is the application, quitting when you close that window makes sense, so that's what Mac OS applications do (e.g. System Preferences, Calculator.) For any application that can have multiple similar windows open at the same time (e.g. any web browser, any document editor), it makes more sense to have an explicit quit option, and stay running if someone closes the last window (possibly because they're about to open a new one, and that last window they closed was the blank Untitled document that opened up when the application first started up, or when they clicked on the Dock icon and the application didn't have any windows currently open).
And yeah, you can either use the dock or command-tab to switch between applications, even if they don't have windows open.
(no subject)
Date: 2010-04-16 07:38 pm (UTC)Except it's *not* easier to go "to the top of the screen" if you're working in the bottom corner. It's much easier to get to the top of your workspace, which should only be "the top of the screen" if your WORKSPACE is at the top of the screen. It's a shorter distance to something closer to both your cursor and the focal point of your attention. The Mac way of doing things is *inefficient* and *counterintuitive*, as well as *slow*.
But if you don't have the metaphor of a parent window
Of course you do - the last window of the application, exactly like how *all* sane multi-window applications have worked, for decades.
you need another way of saying "OK, I'm done with this application now".
Closing all the instances of the application isn't enough?
(Hint: It's enough. Applications that don't close when you close all their windows *are wrong*. You closed all the windows! You have STOPPED USING THAT PROGRAM! It should damn well *exit* and free up the resources for programs that you ARE USING. There are a VERY few exceptions - things like an IM client where the window you closed is not the sole functionality of the application. The application is meant to sit in the background and provide a service, and the fact that you closed the "select people to chat with" window actually *doesn't* mean you're done with the app. But a web browser or a document editor? Those DO NOT provide services while closed and SHOULD NOT be doing a damn thing while you're not using them.)
And yeah, you can either use the dock or command-tab to switch between applications, even if they don't have windows open.
The dock is an extra-special level of bad - an extremely limited number of icons, combined with minor graphical effects to tell you "running/not running", combined with icons that move and dance when you're trying to get to them so they're NO LONGER WHERE THEY WERE WHEN YOU STARTED YOUR MOUSE MOVEMENT? Ugh.
I mean, the Start menu in 7 "scrolls open" by default, but it only changes when you click on it, it goes *fast* because they understand that chasing a moving icon is a pain in the ass, and the scrolling behaviour is a single checkbox to turn it into straight "snap open/closed without animation"
(no subject)
Date: 2010-04-16 09:24 pm (UTC)The point of Fitt's law is that it's easier to hit a larger target than a smaller one. When applied to clicking on something with a mouse, though, you have to also bear in mind that when the mouse pointer hits the edge of the screen, it stops. So the small 40-odd pixel high menu bar at the top of the screen may well be hundreds or thousands of pixels high; you could aim at any point at or above the menu bar, and your mouse pointer would end up over it, no matter how accurate or inaccurate you were.
It's the same reason the Windows Start button is in a corner of the screen: it's very, very easy to hit.
And when I was talking about multiple levels of windows, parent and child windows, I meant multiple levels of windows: one large window which contains the menu, and in turns contains document windows (see Wikipedia (http://en.wikipedia.org/wiki/Multiple_document_interface), criticism (http://www.pixelcentric.net/article.php?art=docs)). Like, say, this screenshot I randomly grabbed off the Web (http://www.datacad.com/products/Whats_New_files/MDI.jpg). In this case, closing each individual document shouldn't (and doesn't) quit the main application; only closing the enclosing window, or choosing the Quit or Exit menu option, closes the application.
But however you present it, I think that on a desktop operating system, where you start up and quit applications, the consequences of closing a document window should be consistent, simple and painless. Why should the application quit I close a window if that was the last one, but not if I had another open? Why should there be a difference between a) opening a new window and then closing the previous window (that works), and b) closing the old window (the application quits), restarting the application, remembering not to close the random untitled empty document it's just opened, opening a new window, and closing the untitled document?
Oh, and the annoying magnification effect in the Dock was always something you could turn off, and is no longer the default option, if it ever was. I think the latest versions of Mac OS also make running applications clearer.
(no subject)
Date: 2010-04-17 12:15 am (UTC)No, I'm talking about something fundamentally different.
It's easier to hit a large target than a small one, but it's also better for your target to be near your work area and attention focus than far away. You could put The One Button That Does Everything in the corner of the screen (the way Windows does, for example), and that's not going to help you in the slightest when you want *your program's options*.
So the small 40-odd pixel high menu bar at the top of the screen may well be hundreds or thousands of pixels high; you could aim at any point at or above the menu bar, and your mouse pointer would end up over it, no matter how accurate or inaccurate you were.
You still have to hit left-right carefully, and you still have to precise with your up-down selection once the menu opens and you are choosing the option you want. You're not fixing anything except the first initial click of what's necessarily at least a two-click process - AND you've eliminated a lot of the one-click options.
Fundamentally, if the problem is that the option are too small and difficult to hit, planting them against a screen barrier does help to make them "bigger" in one respect, but makes things *more* difficult because you now have to go all the way to that barrier every single time AND now you have all your applications competing for the same bit of real estate AND you've severely limited the ability of the user to access different options in different programs quickly and seamlessly. So you've partially solved one problem by creating THREE OTHERS, and all three of the ones you've created are worse than the original.
You've looked at the problem of "it's very bright outside" and decided that your solution should be "becoming predominantly nocturnal and wearing a blindfold at all times", not "sunglasses"
In this case, closing each individual document shouldn't (and doesn't) quit the main application; only closing the enclosing window, or choosing the Quit or Exit menu option, closes the application.
In that case, though, the "child" windows are children of the parent object, like tabs in a web browser. They're not multiple windows, like, say, having two Word documents open.
the consequences of closing a document window should be consistent, simple and painless.
I agree. You're being misleading by conflating "document sub-window" with "window", however, and you're ignoring that in that app, if you *do* close the "main" window, the program stops. Which is not the case in the annoying behaviour I'm describing.
Why should the application quit I close a window if that was the last one, but not if I had another open?
Because you just closed the application.
Why should there be a difference between a) opening a new window and then closing the previous window (that works), and b) closing the old window (the application quits), restarting the application, remembering not to close the random untitled empty document it's just opened, opening a new window, and closing the untitled document?
I have a different question: Why are you *complaining* when you give a quit program command and the program quits, and then you give a Create New Document command and it creates a new document, and then you finally give the Open Existing Document command and it opens the existing document?
The program is doing *exactly what you told it to do*, and you just gave it a stupid series of commands to get what you actually *wanted* it to do.
This is CORRECT, DESIRABLE BEHAVIOUR. The Mac habit of "I know better than you do what you wanted, so I'm not going to do what you told me to" is *bad*.
To paraphrase a complaint from many years ago: When I want toast, I put bread in the toaster. I do not wave bread at my kitchen and hope it figures it out. And my kitchen had DAMN WELL BETTER not say "Oh, you gave me this bread and told me to put it away. I know! You REALLY want toast, despite specifically telling me something different! I'll make toast."
(no subject)
Date: 2010-04-17 04:47 pm (UTC)(Acorn's Risc OS, that ran on the Archimedes and Risc PC series of computers, had a three-button mouse and used the middle button for 'Menu', so you could click anywhere in an application's window, or in its Icon bar [sort of dock homologue] icon, and get a menu, which avoided all of this hunting down the application menu problem. At the expense of all menus being multi-level, and requiring you to have and understand multiple buttons on a mouse.)
(no subject)
Date: 2010-04-17 05:25 pm (UTC)Disassociating the controls from the application is bad. Forcing all the controls on top of each other is bad. The usability improvement in "making the target larger" by giving it infinite vertical space without increasing horizontal space is very much *not* enough to offset the usability decline.
(no subject)
Date: 2010-04-17 08:04 pm (UTC)Conversely, though, if you assume that the menu bar must always be at the top of the screen and change depending on which application is active, then you will indeed be confused when confronted with a number of Windows applications not running full-screen, where the menu bar jumps around from one part of the screen to another depending on which application you're in. (That's if you have a menu bar at all, visible or invisible, but that's another UI issue.)
(As an aside, if you have all windows maximised, then barring menu bar skulduggery from applications perhaps trying to be too clever, your menu bar will indeed always be in the same place at the top of the screen, just like a Mac. I've seen enough people do this that I suspect there might be a reason for it - other than the historically bad multi-level window concept that Windows started out with, which made it difficult to interleave windows from different applications, and therefore difficult to compare windows side by side or drag and drop between two apps).
As for going directly from application A to the menu of application B, is your point really that it's hard to switch applications unless you can click on another application's menu bar? I mean, let's say that for some reason you decided that what you wanted to do in another application was to choose a non-trivial menu option (not, say, Quit or Exit, which there are common shortcuts in both Windows and Mac OS for), but not make sure that you had first put the cursor in the right place in the second application's document, or selected some part of that document. (In which case you're trying to switch to another window, do things, then find a menu option, at which point your mouse pointer is so far away from where it started off that where the menu bar of the second application is is probably a moot point.) Are you actually saying that you make a point, in your everyday life, of lining up your windows in such a way that you can see each of their menu bars from other windows? Not just some part of the window so you can click on it, but the entirety of the menu bar?
I really do think that being able to rely on the menu bar always being in the same place (a region which is easy to get to from wherever your mouse pointer might be), and as consistent as possible (e.g. File, Edit, Help share basic similarities in every application, Preferences is always in the same place rather than randomly being under Edit, Tools or Options) is a big win.
(no subject)
Date: 2010-04-17 12:15 am (UTC)Correcting the annoying animation and making running apps "clearer" does not change that the Dock is fundamentally a usability and interface nightmare from the concept on up. Whee, the turd has been polished, slightly.