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