On 4/7/2011 12:45 PM, Matthew Paul Thomas wrote: > > Some of its benefits (faster, saves space, more predictable direction) > lessen but don't go away entirely. The other benefits stay the same.
You didn't mention it introduces drawbacks as well. From my experience using GNOME, OS X and Windows on the same 22" screen with very similar tasks the global menubar is worse and not worth the benefits. I'm not even sure what benefits you have in mind here. Space There is non saved, in fact some space is wasted if you were nitpicking. Title bar and menubar are separate anyway in window mode. As long as the window isn't as wide as the screen the global menu takes up space at the top that is unneeded and unused (anything left of the Help menu). The only space saving I can think of is if you stack windows on top of each other, something I almost never do and I don't think that's a common scenario outside tiling WMs. More predictable location I'd argue the contrary. Realitve to the mouse position probably somewhere inside the window of the active application an in-window menu is always at the same place. Not so the global menu in conjunction with movable windows. I don't think that's much of a difference anyway. Muscle memory _inside_ the menu (how far down you move) is more important. Speed Here it depends. If the window is near the top menubar (in the same "focus area" as I called it - you don't have to move eyes/head from the active window to the menu) the global menu is easier to hit. This is not the case when the currently active area is somewhere down at the right side of the screen. Also if you want to access a menu of a non-active application it is with certainty slower. What other benefits are there? > In a browser, the tabs, sure. But most other windows don't even have tabs. I agree, but does that mean we should negate these applications the advantage of tabs on top? The main argument against this is consistency but I argued previously why I don't think that's going to be a problem, and if it is I'm convinced it's worth the trade off. > The "History" menu alone is deeper and more information-dense than the > spanner menu is. The one-button Chrome menu only has a link to "History", no menu beneath. It opens the a new "History" tab which is the layout you are supposed to use, with search, details, scrollbar and all. Or make use of the address box which searches the history as well. A two button menulayout of Chrome 10 would consist of two completely flat menus with 15 and 10 entries respectively, I'd argue the classic Firefox menu bar with 7 top level menu labels with sub-entries ranging from 4 to 11 and 8 sub-sub menus is slower, denser and less user friendly and by extension slower to use. Don't have access to a Mac version of Chrome right now and I imagine it's simpler but I doubt much better than a two button in-window layout that it warrants reducing the area available for web content by 20/24 pixels on a typical 576 high netbook screen (with now way to opt out except full fullscreen) AND use that area for infrequent accessed functions as opposed to the most frequently accessed "bar" of the browser. > I've long wondered why browsers don't make the Back button a narrow > strip down the left edge of the screen. That would both be much faster > to use *and* make visual sense. Oh, but that wouldn't work on Unity. Familiar problem? :P Opera uses that are for sliding in their left panel. > The reason they haven't had menus up till now is, rather mundanely, that > menus inside a dialog-like window look weird. Menus in a global menu bar > don't. > >> which would be a waste of space and cumbersome to use >> because it's nested. A dedicated single button is faster and more >> discoverable and ctrl+z could have implemented a long time ago without >> changing anything in the UI. > > The reason for not having a dedicated single button was, again > mundanely, that there was no consistent place to put it. > I see that and it makes sense but it doesn't strike me as a particular elegant or a reason for the use of a global menubar. There is no reason not to design these GNOME system settings in a way that allows such functions right from the main window in a logical and more discoverable way than a menu where you first have to look through if it even has that functions. Long term users might even never bother to look and just assume nothing has changed and from my experience really novice Mac users don't look through the menu either. If an obvious and main function doesn't have a nice big icon on the window they assume it's not there. > What's the keyboard shortcut for going into full-screen mode in Chrome? > And what are the keyboard shortcuts for making text smaller or larger? > The menu-button can't tell you, because it's cramming multiple menu > items into the same row, because it's trying to get by with a single menu. Fullscreen is no issue because it tells you right after you clicked on it how to get back (both via mouse and via keyboard shortcut). Learn as you go, pretty nifty solution. I think the missing keyboard shortcuts for zooming is an oversight, it could at least be tooltip inside the menu. But then people who do use keyboard shortcuts already know these standard combination anyway. It's a problem for completely new computer users and I agree that this is nothing we should copy. In Chrome OS they have a separate cheat sheet function so I guess that's the true reason they don't bother. Also if you click on Help in the menu and enter "Zoom", this is the first result: http://www.google.com/support/chrome/bin/answer.py?answer=96810 Still doesn't tell you about Ctrl+0 though. I also have to add neither classic menu nor any other solution tells you about scroll wheel+ctrl for example. The Firefox single menu button got the same issue, or even worse. It does not only not expose all keyboard shortcuts, it doesn't even expose all commands and functions available. But you can always hit the alt key and get the full classic menubar if you have to look something up. IMO the ideal setup for the two browsers would be a "?" or "Menu" button that slides in a menu bar and the wrench menu or possible two buttons with functions that are actually needed to access via menu (vs just duplication), without any keyboard hints and preferably a simpler layout than the two columns Firefox button menu or the nested IE9 menu. I think that's best of both worlds. You get the full menu that isn't overcrowded and you still get a nice clean interface that goes out of your way and makes place for the actual content. In any case I'd still prefer to have the menubar below the tabs. > > That may work for Microsoft Office, decked out as it is with ribbons and > buttons like a field marshal's uniform. But Ctrl+P working wouldn't > inform you that, for example, iTunes has a "Print" function for printing > CD covers. And putting a Print button, or even an all-in-one menubutton, > inside a music player window would be ugly. That's an interesting detail. But I think if you don't know that iTunes has this feature you are never going to look into the File menu looking for that function. Best thing happens is you discover it by accident. A well designed application will ask you if you want to print a cover if you just burned a CD. Users don't have to know that this function exists until they actually need that function. It's still nice to list it somewhere in the menu structure just for completeness sake. But does the menubar have to be always visible, and at the top for that? I also doubt an all in one button is ugly. Now we are arguing taste I'm afraid but if you look at the iTunes interface which already got tons of icons that no one complains about one more wouldn't kill its usability. I know I'm not representative but my favourite audio player is foobar2000. It has a menubar but you can completely change the interface to adapt it to your personal preferences, the menubar can be moved, removed or reduced to a single button. It may not be the right choice for a default audio player in an OS but it's certainly one of the more popular Windows applications. A global menubar would take away this total freedom over the interface and layout of an application that you have in the non-free Windows. Hey, isn't that what Linux is all about? (I know. Sorry, I will stop now.) > In the videos I've seen, full-screen applications in Lion do not provide > non-menu access to all the functions available in the menus. So either > the menu bar will still be accessible in full-screen mode, or you need > to exit full-screen mode to access the deeper functions. Obviously I haven't used it yet but if it's intelligent I doubt the menubar will slide in from the top when the mouse hits the screen edge simply because of Fitts's Law and considering Apple's priorities for aesthetic reasons as well. Considering how they think of usability and their users having a simple mode that doesn't give you full access to everything is a good thing in their book. Not sure we should copy that... > The Finder does "support" cut and paste, for the stuff that it actually > edits, i.e. filenames. What you mean is, you can't move files using Cut > and Paste, because that would be a mixed metaphor. > <http://homepage.mac.com/bradster/iarchitect/explore.htm#EXP3> (But then > Apple dithered and went halfway, allowing copying of files with Copy and > Paste.) A better file manager could have "File" > "Move To..." and > "File" > "Copy To..." commands, that didn't distort the clipboard > metaphor *or* rely on drag and drop. It's messed up and there is no good reason for this missing functionality. Speaking of cut and paste, I think Unity finally "fixed" the clipboard in Ubuntu. Select middle click still works like it used to though, oh the inconsistencies again :) _______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : [email protected] Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
