Talk:Menu bar

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Factor 5[edit]

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)

Bad Article[edit]

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.

Fixed that a bit. --Kainaw (talk) 16:30, 29 June 2006 (UTC)

Explaining what a Menu bar is[edit]

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![edit]

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. 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. (talk) 04:09, 15 January 2008 (UTC)

A better keyboard shortcut to access the Mac menu is needed[edit]

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

Does the menu bar include...[edit]

Does it include the gray space on the right of the rightmost menu (the Help menu, in most applications)? -Pgan002 (talk) 05:40, 28 November 2008 (UTC)

unsourced comments[edit]

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.[1] When using dual monitors, the menu can be on an entirely different screen from the application it is controlling, requiring much more mouse movement. (talk) 14:07, 15 May 2009 (UTC)

This is actually extremely accurate, and self-evident as you can prove in any window base application using multiple applications at once. BAD EDIT removing this. // FrankB 19:36, 3 March 2014 (UTC)


parts of speech?[edit]

What parts of speech should menu bar items be? Verbs or nouns? “File” “Edit” “View” “Tools” “Help” do not seem to be consistent. – Kaihsu (talk) 20:22, 24 March 2011 (UTC)

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)

Mergeto/Mergefrom proposal killed[edit]

Edit summary:

Editor... didn't even follow directions to link and initialize a talk discussion with his/her reasoning. // FrankB 19:38, 3 March 2014 (UTC)