I'm sorry..I strongly disagree. You have me on the video support...OS X does a much better job there. You even have a point on audio drivers...they can be a pain at times. But design? Gnome 3 and Unity to me are FAR superior to OS X in terms of UI experience. YMMV of course. I bought a Macbook, gave it a fair shot, and it ended up being a dust collector simply because the desktop experience was painful compared to Ubuntu or Fedora (well, that and the fact that I got maybe three hours of the supposed 7 hour battery, and the fact that I can't upgrade it past 4 GB of ram o.O). Perhaps I'm set in my ways, but the absolute insanse window switching behavior, the piss poor excuse for a terminal, the fact that apps continue to run in the background after you close the last window, and the general SLOW performance made my $2500 investment one I'll regret for very long time. Switching to a Lenovo running Ubuntu was a far better (and MUCH cheaper) experience.
It sounds like you expected a clone of Windows and were predictably disappointed.
> I got maybe three hours of the supposed 7 hour battery
You should have taken it back. Seriously.
> Perhaps I'm set in my ways
You hit the nail on the head here. There's nothing wrong with that but most of your complaints amount to "this is not what I am used to".
> the absolute insanse window switching behavior
On Windows and Linux I cannot switch to an app bringing all windows to the front, I have to do it one at a time. Anyone used to one behaviour could claim the other is insane just because it is different.
> the piss poor excuse for a terminal
What on earth are you talking about? The Terminal app? Get iTerm2 or something else then. If you don't like gnome-terminal you don't whine about it, you just install urxvt or whatever.
> the fact that apps continue to run in the background after you close the last window
The fact that you have to have visible windows for an app to run on Windows and Linux could be perceived the same way. What if I wanted to switch back and use that app again?
On (...) Linux I cannot switch to an app bringing all windows to the front, I have to do it one at a time.
Sure you can. Just launch (or move) each application to its own virtual desktop. You can even group them logically, like an email reader with an IM client!
What if I wanted to switch back and use that app again?
Window and Linux applications are not disposable, they can be launched more than once.
> Window and Linux applications are not disposable, they can be launched more than once.
But when the last window is closed the application quits. What if I want to keep it running because I will switch back and open something in a minute? On Windows & Linux I have to launch the app again.
I'm not arguing for one or the other here, just illustrating that this argument is based on familiarity not one actually being better than the other. Each has pluses and minuses.
That's my point. It's not that a lot of people like it. In fact, whether people like it or not isn't really relevant.
It's that this is the correct way to do it.
When the menu bar is at the top of the screen, the user is much faster at getting the mouse over a menu item and clicking to open the menu.
It works better. This isn't opinion, it's measurable scientifically.
When the menu is on a window, you overshoot with your mouse and come down and have to hunt to get on the menu to open it. This slows you down.
But the thing is-- people get used to being slower and less efficient and then when on a better solution, they think the better solution is worse because it goes against all the compensations they've had to build up over the years to get around the other, poorer, design.
Now, I'm not saying that you can't prefer a windows style UI and menubar, but I am saying it is most likely because this is what you've been taught to use, and thus it feels more natural to you, even though it is less efficient for you.
Except when you have multiple monitors. How is it the correct way to do it to force me to mouse 4000 pixels to the left or right to get to the menu for an application that isn't on the same screen as the menu?
There's never just one correct way to do things. Your arrogance towards other implementations is overwhelming.
The arrogance comes in the way you deliver your argument and insist that your preference is the only valid choice, regardless of any difference in conditions; it has nothing to do with the science.
I took the same Human Factors class that cites the same decades-old studies that you're pushing as ultimate truth; all of that science was done when multi-monitor setups weren't even supported, let alone common. I have no problem agreeing that a universal menu is optimal for certain sets of conditions, but that doesn't mean it's the one true way for everything.
For a start, it precludes a sane implementation of focus-follows-mouse.
Secondly, for frequently used commands, keyboard shortcuts will be faster anyway (I'm aware of the study you're probably going to mention, but plenty of other studies have had different conclusions).
Lastly, and this is pure conjecture on my part, wouldn't having the menu bar at the top of the screen result in a much narrower arc from the current mouse position to the desired entry? The theory also seems to ignore the fact that in most cases you'd want to move the mouse back to the original window, or hit some specific (and often quite small) target in that window. Which is now made more difficult by the mouse being farther away. Just some idle wonderings, they were quite possibly addressed in that study.
I know that you started your post with "Whether people like it or not isn't really relevant. It's that this is the correct way to do it.", and thus are unlikely to be swayed from your opinions; it's worth considering though that every choice has pros and cons, and sometimes the total value of each side very much depends on the person.
(although I share your "Screw the people, this is /correct/!" view when it comes to tau: no-one's perfect)
much narrower arc from the current mouse position to the desired entry
Particularly since the top left option (in the easy-to-hit corner) isn't usually one that you want to access much in the use of a program. Sure, you can get your mouse in the vicinity, but you still have to hunt for the menu you actually want. If your screen(s) is large enough that this requires moving your head (or even your eyes significantly), it rapidly eats up any trivial advantage you gain from 'knowing where the menu bar is'.
Science says that it's faster to hit a distant infinite target given sufficient mouse speed vs a small but local target.
given sufficient speed.
However it says nothing about whether an application's menu bar is important enough to warrant that extra acquisition speed.
Also the mac menu bar does not present an infinite target, particularly if you have any significant horizontal velocity, which is extremely common with wide screen monitors or multiple monitors.
Also with the advent of large/multiple monitors there is the need to change where you're looking causing extra delay for refocus.
It is not the correct way to do it. It has some very simple problems.
First, if I have a bunch of little windows on a big screen--something very common on Apple computers--I have to drag my mouse all the way to the top of the screen and then drag it back. For me, this was an serious problem. Partly this was because I was also using one of the horrible Apple mice (the "mighty mouse" or something of that nature). This was particularly annoying because I would often lose focus by clicking on something else by accident and have to go all the way back to my original window and then all the way back to the top... Incredibly annoying.
Second, not all programs have--or need--options on top. I essentially live out of Emacs and Chrome these days; neither uses a menu. That would make the Apple bar just a waste of screen space--completely absurd. Moreover, I've found that bar to be superfluous on other software I use as well. Having more minimalistic interfaces is a breath of fresh air--and completely impossible on OS X.
It also fails to generalize well to multiple screens.
Oh, and there are going to be problems if you want to make the available options context-dependent. This is a reasonable design decision if you have a complex program with a bunch of small, discrete windows for different tasks--something else that isn't uncommon on OS X. This sort of behavior is far clearer if there is a menu per window than if there is a single menu for whatever is currently active.
I submit that we are talking about a physiological issue, not a preference.
Attempting to hit a target in the middle of the screen is more difficult for humans than hitting a target at the very top of the screen.
When you overshoot the target in the middle of the screen, you have to come back around to click on it.
When you overshoot the target at the top of the screen, the pointer is stopped by the border of the display. Stopped right on the target, and you can just click.
It may not feel faster to you-- that's perception.
My point is that it is faster. And I haven't seen an argument for why the two things would be reversed for any specific person.
It's the nature of the latency between our eyes, mind and muscles.
So you're saying that humans have laser-like accuracy in the horizontal dimension, and sloppy accuracy in the vertical? Your interpretation of the science is poor.
I don't know how you get that interpretation from the parent post. Only having to worry about one degree of freedom in your movement is much easier / faster than having to manage two.
The OS X menu bar is modal. It depends on what application is current. There's also research indicating that the usability of modal UIs is poor; it's also measurable scientifically.
I personally don't mind the OS X menu bar's location, but its modality is a big pain point. Combined with the fact that apps often don't exit when all their windows are closed, it's a bit of a magic box of functionality where I'm never certain of what's going to be there, and how to get it back if it disappears. At least Windows' menu bars have a sense of location.
Some people don't use menus often. From my experience, I use menus 2-5 times a day at most. However, if you rely heavily on clicking menus, learning keyboard shortcuts can be a really good time-saver.
And the second argument against this "smart" (or maybe legacy?) menu placement: In some applications menus have sub-menus, and sub-sub-menus, etc. And it is impossible to put all sub-sub-...-menu items on the top menu bar, so you have to click many times in different parts of the screen anyway. (Oh, yes, this is not an issue for a program with simple menu, but then the keyboard shortcuts can be the way to go).
So, there are many shades of "correct", I think. Alternatives must be at least considered, I think that it's better to let the user decide what they prefer.
What's wrong with the Terminal.app? Except for the fact, that it does not really work?
Yeah, for simple stdout/stderr output it is fine, but for medium-sized ncurses apps it is a major PITA. Even Icaza's own Midnight Commander does not work there.
No, seriously, what’s wrong with mc in Terminal.app? I mean, OS X and Terminal.app take over function keys for other purposes like, I don't know, changing the volume, but these things can be disabled if you want to use function keys for something else, like mc commands.
