Can someone please explain the factor 5? If the baseline time constant in fitts law is not completely neglegible this value seems out of place. Which assumptions were made? Are people really 5 times faster? Moreover, short movements are faster with fitts law so part of the difference in effective hight will be negated by smaller movement distance.
- I have attributed that to Tog who, if not the source of the 5x faster claim, at least repeats it in an easily linked fashion. What I have not addressed is how important the 5x factor is, since we are almost certainly talking about fractions of a second here. What would be more interesting to me is a "frustration factor" caused by users clicking on something other than the intended menu bar. Probably impossible to quantify, but interesting nonetheless.--Not Important 10:24, 1 July 2006 (UTC)
Is Tognazzini an unbiased source? His page also states that "Fitts' law dictates that the windows task bar will constantly and unnecessarily get in people's way, and this is proven out." (?!) --Rennep 15:47, 24 July 2006 (UTC)
This page doesn't define what a menu bar is. It simply defines how the Mac and Windows operating system implements them. This is both uninformative and narrow-focused.
Explaining what a Menu bar is
I'm trying to explain what a menu bar actually is. Would it be fine to say that the naming of the menu bar stems from the fact it is rectangular?--Improfane 21:33, 11 July 2007 (UTC)
Just give me a choice - please!
The Mac menu bar is a bad piece of design, and the ways that people try to excuse it and justify it are just amazing. I've heard about muscle memory, consistency, and now this nonsense about "infinite height". Just try it - drive your mouse up there and keep going and see what happens. Unless you push dead straight ahead, so the mouse stops at the top, then it will continue to slide over the the left, til it hits the corner. Then you have to come back to where you wanted to be (that is after you've had to reverse whatever hot-corner action is setup in the top-left). So, you can't use the menu as if it has infinite height - you have to aim for where you want to be and stop pushing the mouse when you get there. Just like you do on any other part of the screen. As if that is hard anyway!
- you only have to aim on the x axis with a mac, not both
Try using a mac with two monitors and see how much sense it makes. You move an application over to the second screen, and its menu stays on the first. That somehow makes sense, does it? No, it does not.
Apple - please give us the choice of where the menu goes - either at the top of the screen, or on the application window(s). I'd be very interested to see a survey of the choices that users make, after you've done that.
126.96.36.199 01:59, 16 August 2007 (UTC)
- Whether you like the Mac's approach or not, I bet it will never change on Mac OS X. That's because the API is deeply entrenched - it's still using code carried over from the original Mac toolbox, updated only slightly for Carbon, and still underpinning the entire menu system even for Cocoa apps. Too much of it has been exposed to applications for too long to be able to suddenly allow users to "opt" for adding menubars to windows, and also, since the Mac doesn't have a single window representing the application as a whole (i.e. no MDI) there's no alternative place to locate such a menubar. Overall I think the Mac's approach is a cleaner, though still imperfect, solution compared with Windows, et. al. 188.8.131.52 (talk) 04:09, 15 January 2008 (UTC)
Touch typists can be more productive if there as an alternative to moving the left hand off the keyboard to the Mouse in order to access the top menu. Additionally, all items that can be accessed directly via the keyboard from drop-down lists from the main menu should be clearly indicated. —Preceding unsigned comment added by 184.108.40.206 (talk) 19:54, 30 September 2007 (UTC)
Keyboard shortcuts are indicated in the menu itself, and always have been. You can access the menu bar to cursor through it, windows-style by hitting ctrl-f2
I removed this from the article because: 1. The source is a not notable. 2. It is just an editors opinion (however reasonable).
This assumes that the desired menu is currently enabled, however. If another application has "focus", the menu will belong to that application instead, requiring the user to check and see which menu is active before "throwing" the mouse, and often perform an extra step of focusing the desired application before using the menu, which is completely separate from the application it controls. The effectiveness of this technique is also reduced on larger screens or with low mouse acceleration curves, especially due to the time required to travel back to a target in the window after using the menu. When using dual monitors, the menu can be on an entirely different screen from the application it is controlling, requiring much more mouse movement. 220.127.116.11 (talk) 14:07, 15 May 2009 (UTC)
parts of speech?
The original Mac UI guidelines say they're verbs. The original Mac apps only had File, Edit, View, which can all be verbs. The only exception was the 'Special' menu in the Finder, which was a big deal at the time. Obviously it got messed up with developers using nonverb names. – WO89u (talk) 18:15, 28 February 2013 (UTC)