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