In the GNOME bugzilla, there is an ongoing discussion about whether or not to include a patch into the default GNOME installation which would enable GNOME to (optionally) have a global application menubar, similar to that of the Mac OS and KDE (in the latter it is optional and off by default). Installation instructions and .deb packages, as well as a 60-page (and counting) discussion of the patch, are available on the UbuntuForums. Read on for a poll on this issue.Note: This poll requires javascript to both vote and view.
What’s the reason behind removing menubars from the windows and moving them to the top of display? The only one I can think of is “shiny, OSX has it”.
The question you should be asking is this: “why not?”
“””
The question you should be asking is this: “why not?”
“””
No. The question is “why?”. Options should not be added to the UI needlessly. It must have a solid reason to be there.
I’m surprised that you, Eugenia, would look at it that way. I would have expected that including UI options without solid reason would go against your philosophy, as I understand it.
You’re absolutely right. The reason is simple: I find it to be a UI enhancement. Changing the question to “why not” really makes a solid point. UI camps are divided on the issue, but it’s a fairly equal division. It’s times like that where having it as an option that’s off by default is the best route.
The answer to “why” is very simple: because there are enough users out there that find it useful to warrant such inclusion as an option that’s off by default.
“Why not” is brought up because so many are immensely and adamantly opposed and, quite frankly, for no reason other than that they don’t particularly want it.
That’s not to say that every option need be present in Gnome. This particular one, however, deserves a place.
1) Because if you put the menues in a OSX-like menubar, then the windows doesn’t needs to have enougth width to have them in the window. If you have used Adium, you have like 7 menues, or even more, in the OS-X menu bar. The Adium window design only could have 2 or 3. Having menues in a separate bar separes the menues design from the GUI design.
2) Microsoft have tried to design an interface that has the same objective (make the menu bar disappear from the window UI), the ribbon thing. The Apple approach looks cleaner IMO.
3) Cleaner window UI, due to 1)
4) It’s easier to find the menues that way, they are always on top of the screen
4) Since all the windows share the same menu bar, you save screen space when you’ve multiple apps opened.
5) You can use it as “system” menu bar. This saves you from using the app launcher to find the “shutdown” function.
6) Because Apple is the most usable OS, they really care about usability and there must be some reason why they do it (sorry for the weak reasonement but it’s true)
Disadvantage: The menues are separated so it’s not directly obvious that they’re related to the app you’ve opened. It’s ver very easy to get used to it, though.
Edited 2007-05-17 21:16
7) It’s been proven to be a faster method of using a menu. It’s late and I can’t remember the reference though. By having it at the top of the screen you can just move your mouse upwards without having to target a specific vertical space. Because the mouse is bounded by the screen that small bar becomes, in terms of hand movements needed, a much larger area.
The usability gurus seem to love it but personally I hate it.
“Proven” is a bit of a strong word. “Some studies have indicated” would be more accurate. And even those studies show that even if the there is a quantifiable difference, it is really very tiny and largely irrelevant when compared to the time other tasks take. And really if you are that worried about shaving 2/10th of a second off the time to do a task, you’ll memorize the keyboard shortcut.
The question is “who chose to put application menus at the top of every window?” It’s a waste of space.
Personally, as by now I have no doubt said many times here, I’m holding out for menus that disappear unless you click a mouse button.
I’m sorry, I think “why” is very much the better question. For the last few years, Gnome has put a lot of effort to stripping its applications of excessive options and advanced settings. Some people might not like this, but it seems to be working for them. There has been a lot of positive response to a FOSS desktop environment with a minimalist interface, sane defaults, and large focus on HIG. Thus, they have to be very careful about adding options that allow users to change the core interface of the Desktop Environment.
Why? Because some people prefer it that way. I don’t, but I can understand that some people do.
He knows that. Assume he is asking why they like it better.
Who cares? If they like it better, isn’t that reason enough?
I think having it as an optional feature that’s off by default is quite reasonable – unless, you know, it breaks one of Apple’s patents… 😉
I think the question is “Why should it be default”
I think the answer is ‘duh’. It should be AN OPTION BY DEFAULT
Whether or not it’s enabled I have no opinion as I haven’t used it…
The question you should be asking is this: “why not?”
Please explain how that is a better question to ask??
why not. because when windows aren’t maximized they are confusing. controls that work for a program are off of the window. AND on the window. which is weird. either have the controls ON or off the window. why both? it just makes it confusing.
it’s not my way of working, and i wouldn’t want it as default.. but why not just have it as an option? it’s always nice to have options. Especially with something as often used as the main gnome bar. It’s just one of those things that MUST be configurable so that it can please any user.
Because global menu bars suck on large screens or dual screens. They work very well on traditional screens but they have severe limitations on larger screen areas. It starts to take longer and longer to access the menu via mouse the larger the screen area gets. The global menu bar paradigm is failing now that technology is surpassing its usefulness.
To make the display even more non-cluttered and mainly to save space.
Menubars at the top of the screen are the pedagogical example of the utilization of Fitt’s Law.
Fitt’s Law is given by:
T = a + b log2(D/W + 1)
Where a and b are empirically-determined constants, D is the distance to the target, W is the size of the target in the direction of travel, and T is the time required to perform the motion.
(http://en.wikipedia.org/wiki/Fitts_law)
Moving the menubar to the top of the screen has the effect of increasing D*, but also has the effect of drastically increasing W (since overshooting the target is not possible), leading to an overall decrease in T. Fitt’s law is particularly important for menubars, which tend to have a fairly small height, and thus a very low W unless they are at the edge of the screen.
*) By a moderate amount. It’s likely that the tops of most windows are near the top of the screen anyway, so the increase in D is unlikely to be even a factor of 2.
I have a hard time believing that. It doesn’t take into account that menubars for not active windows are hidden and require bringing them “up” which in reality places mouse about 10 pixels from place where classic menubar would be. If the app is not taking the whole screen the distance between area that you operate on and menu is quite big and grows annoying if you have to access it frequently. At least that’s my impression after using OSX.
First, its a very well-established empirical equation in user-interface research. If you don’t believe it, I presume you have some evidence to counter all the studies that have supported it?
Second, yes, it doesn’t take into account that menubars for inactive windows are hidden, but that’s beyond the scope of the equation. In anycase, if you’re having to click regularly on the menubars of inactive windows, then there is something wrong with the design of your applications.
Third, yes, the overall distance of travel increases, but because the target gets larger, you can use a much sloppier (and much faster) motion to traverse it. That’s the whole idea embodied in the equation: the less accurately you need to aim, the faster a motion you can use. Absolute mouse movement speed is rarely the bottleneck in clicking on a screen element. Rather, the bottleneck is how fast you can move the mouse while retaining the required accuracy, and that speed is *much* lower.
First, its a very well-established empirical equation in user-interface research. If you don’t believe it, I presume you have some evidence to counter all the studies that have supported it?
I’m not that bored
Second, yes, it doesn’t take into account that menubars for inactive windows are hidden, but that’s beyond the scope of the equation. In anycase, if you’re having to click regularly on the menubars of inactive windows, then there is something wrong with the design of your applications.
Wrong design? How about Gaim/Pidgin or other IM apps? It’s perfectly reasonable to have main contacts windows and separate chat windows with their own menubars. And I’m usually running more than one application.
Third, yes, the overall distance of travel increases, but because the target gets larger, you can use a much sloppier (and much faster) motion to traverse it. That’s the whole idea embodied in the equation: the less accurately you need to aim, the faster a motion you can use. Absolute mouse movement speed is rarely the bottleneck in clicking on a screen element. Rather, the bottleneck is how fast you can move the mouse while retaining the required accuracy, and that speed is *much* lower.
Neither this patch nor OSX moves toolbars with the menubar. Somehow I’m supposed to have a hard time clicking menus but for small icons it’s ignored? I’m already focused on the app, menubar is there, it’s not hard or counterintuitive to aim there.
Edit:
Is it me / my browser or are the OSn-v4 bbcode tags broken? I can’t use multiple quote tags (only first and last one work) and italics tag looks strange o_O
Edited 2007-05-17 20:36 UTC
‘Third, yes, the overall distance of travel increases, but because the target gets larger, you can use a much sloppier (and much faster) motion to traverse it. That’s the whole idea embodied in the equation: the less accurately you need to aim, the faster a motion you can use. Absolute mouse movement speed is rarely the bottleneck in clicking on a screen element. Rather, the bottleneck is how fast you can move the mouse while retaining the required accuracy, and that speed is *much* lower.’
— Great with todays monitors, but surely the problem you’ll incounter when monitors increase in size is that the amount the mouse pointer can be moved is dictated by the space on the physical desktop for one to move the mouse in.
I may be able to move the mouse pointer 20 times or whatever faster because I don’t have to aim at a target, but come the day I can buy a new better bigger monitor and several thousand pixels of space to traverse moving the mouse just once, no matter how fast, ain’t going to reach the menu bar at the top of my huge display. Factor in the time taken to move my mouse to some space on my physical desktop so that I can ‘push’ the pointer upwards again and I’ve probably added time to what I’m trying to do.
I don’t really know how it is in Linux land, but the faster I move my mouse in MOSX, the further distance it travels… It takes barely any mouse movement at all to get to the menu.
Same on linux, and you can configure initial speed and how many acceleration you want, too.
Rather than clicking in the window then clicking the menubar inside the window, which is currently the default on Gnome?
Rimmer’s Law 271 states just as clearly, “No chance you metal bastard.”
Fitt’s Law is for you and your fellow robots, a few fractions of a few ms saved aiming the mouse at a menu option only annoy those who have to repeat tasks ad infinitum: like machines. To people just editing documents, creating websites, reading the news and who aren’t spending 24/7 online the time save by Fitt’s Law isn’t worth worrying about.
Edited 2007-05-17 20:00
Watch my parents trying to click a button or a menu item.
WATCH THEM. Have your stopwatch handy.
Then you will understand which dimensions in time Fitt’s Law can be about.
I use Fitt’s law to reach scrollbars all the time, and get *very* frustrated if they don’t touch the edge o the screen. I think frustration by not being able to hit a button easily should be factored into your thinking.
Can you tag an english conclusion onto that so I know what you’re talking about?
“Moving the menubar to the top of the screen has the effect of increasing [variable], but also has the effect of drastically increasing [other variable]”
What you’re trying to say in a very mathematical way is that moving the menu bar to the top makes it easier to access it. But who says the menubar — an extremely old UI paradigm — deserves this level of attention? Why not move the toolbar up there instead, which contains the most useful commands for any given application, rather than every possible command?
I’d say if an application needs this focus on the menu bar, it’s badly designed.
The menubar might be old, but then again, so is thermodynamics and classical physics. All are still around, well, because they’re as useful today as they were decades or centuries ago.
Part of the reason for putting the menubar there instead of the toolbar is because the toolbar is already pretty large to begin with. The menubar, consisting of text, is much smaller and harder to target.
But who says the menubar — an extremely old UI paradigm — deserves this level of attention?
The menubar may well be an old concept, but there are programs for which it is vital.
Quick example: try to move all the functions OpenOffice has on the toolbar rather than in the menubar. It will fill up half of the damn screen.
The menubar and the toolbar have their own place in a GUI. The functions which are used so often that they should not only be readily available, but displayed in full view, are on the toolbar. The rest can be moved in the menubar, in a hierarchic structure (i.e the File menu will contain all operations related to files; the Export to… submenu will contain all the formats something can be exported to).
The “logical” trend is to find a way to keep a balance between them. Move everything that is not so essential that nobody should click a menu in order to find it out of the toolbox. Provide keyboard shortcuts for everything, and so on. All these come from one logical fact: windows are to display your work, not what the application can do. If an application has a toolbar with more than 10-12 icons, a reasonable maximum for one’s short-term visual memory, it has too many and, in order for the user to find the relevant option, he’ll have to hover the mouse over the icon to get a tooltip — which ruins the whole point of having icons in the toolbar.
Then, you may ask, why do Windows and X11 programs have such a cluttered toolbar? I mean, compare, say, Kdevelop’s interface (this: http://www.ellak.gr/pub/knoppel/shots/kdevelop.jpg ) to Xcode’s: http://zovirl.com/2006/07/xcode_pics/xcode.jpg .
Quick answer: because accessing them from the menu became very painful.
Back in the days when the earliest Mac OS was conceived, the menubar was established for a good reason: screen space. On a 512×384 screen, having 12 16×16 buttons was already a lot of space — not to mention that if a menu was longer, once placed in a window, there was a chance you actually had to move the window up in order for the damn menu to fit.
Later, with the advance of high-res displays, Apple didn’t abandon the idea — and for a reasonably good ideas: context menus and past habits.
It’s a false idea that “everything” is concentrated in the menubar. Instead, the menubar contains (or should contain, in an ideal world of GUIs) only general, readily-accessible functions. For instance, if a function refers only to a certain kind of object (i.e. a Select Color item for a shape in a vector drawing program), it doesn’t belong to the menubar, it belongs to a contextual menu you get by right-clicking the object..
The other important thing was that virtually all the audience of OS X was already used to having a top-screen menubar. For anyone switching fomr OS X to something else, it’s an equal pain in the neck not to have the menubar up there.
With Gnome trying to implement it — it’s hardly a case of “shininess”. There are a lot of people for whom that bar is the natural way to operate their computers. This is a good enough reason for implementing such a feature.
——-
Slightly uninteresting mentions.
The other reason behind that menubar is having to do with the idea of “closing” windows — and the best example for me to show this is Gimp.
In many systems, including many X11 environments, the idea of one big window having all documents inside (i.e. Windows’ MDI) is evil. Indeed, there are cases when you want to have several windows open — in my case, for instance, it’s having a look over a Python tutorial in Firefox while typing <something> in IDLE and having a window chat open just in case someone asks for me. On a 21″ screen, it’s no big problem for me, and I don’t want one big window to force me to click on the taskbar when I want another one.
The application-window-and-menubar has one fundamental flaw with which a lot of new users are confronted (and which is why the MDI concept appeared in the first place). If the present application has many windows open on the screen, each with its own close button and menubar, which window should you close if you want to exit the application?. This is easy for each of us to figure, but for someone touching a computer for the first time, it’s not. Furthermore, if there are a lot of windows on the screen and the one which, once closed, will quit the program, is hidden, one may have the surprise of exiting the application alltogether. The idea of “minimize” works fine — but with Gimp’s many-many-many windows, the whole things get so cluttered you can hardly find it once it’s down.
In addition to this, if a window merely shows information, there is no logical reason for the application to exit completely just because a window is closed. What if I want it to continue running, but I want no window on the screen OR in the taskbar?
On OS X, every application is represented by its menubar. This is counter-intuitive for anyone coming from a Windows environment (i.e. how can an application run without any windows??) but it actually makes a lot more sense to a novice user.
How do you distinguish which window is currently “active” when there are more? It’s subtle, I know, but OS X employs an easy way to do that: the shadow under the active window is more pregnant. It sounds as a little thing, but actually I’ve found it very easy for people who haven’t used computers before to recognize it. The only obvious failure for this is that it won’t work very well on a dark background, where the shadow is not visible. On a Gnome without beryl, compiz, xcompmgr or anything else that draws shadows it will be, indeed, confusing.
—-
The bottom line is, however, that there are a lot of people who find a top-screen menubar easier. It’s all about accessibility and usability. I know that Linux is a geek’s toy (it’s been my toy for years), but some tolerance for the modestly few who consider the top-screen menubar the better way would be cool to have. I am one of those, actually, even though I’ve used OS X seriously less than I’ve used Linux and NetBSD.
I apologize for the lengthy reply.
P.S. Lengthy as it is, I’ll need to make a quick entry.
Fitt’s and Hick’s laws are both excellent theoretical models, in the way that they represent the easiest method of operation for someone who sees an environment for the first time. Basically, considering Fitt’s laws, if you place an user in front of a screen he’s never seen before, there are five places he will be able to reach without any kind of effort: the four corners of the screen and the pixel just underneath his cursor.
This is why a) the corners are used for things like Start Menus, Apple Menus, Hot Corners and system trays, while the pixel underneath is used for context menus.
However, if the user is already familiar with the screen, there are other places he can reach with very little efforts. These are mechanical automatisms, and the best example is the NeXTStep dock (note: not Apple’s horrible dock). If a user has clicked a fairly large icon/button a lot of times, and the button has always been in the same particular place, clicking it again is effortless. The user no longer needs to have a deep look, find the relevant button and then click on it — it takes him sensibly less time to find it.
In general, a badly designed GUI with which the user is, nevertheless, used, will seem much more efficient than one which is perfectly designed according to GUI design principles, but which is unfamiliar to him. Virtually all seasoned Windows users will seem lost when using OS X’s interface (OK, their dock IS bad) or, even better, NeXTStep’s (if they find any around), without actually realizing that, by any meaningful GUI design principles, the Windows desktop is a disaster.
Edited 2007-05-17 23:13
Quick example: try to move all the functions OpenOffice has on the toolbar rather than in the menubar. It will fill up half of the damn screen.
That’s why Office 2007 uses a ribbon.
Maybe that’s the direction Gnome should take for apps with many functions.
Microsoft got it right more or less (yes, yes, you may shoot me now
http://en.wikipedia.org/wiki/Image:Office07homestu.png
In Office 2007 you can more or less create your own toolbar with the stuff you really need in the titlebar (+the file menu).
Those buttons are
a) easy to reach if the window is fullscreen, thx to fitt’s law
b) but avoid the problem where you have to first move your mouse to a window, activate it, then move back to the top of the screen for the menu bar.
This behaviour is optimized for apps you generally use maximized and reduce in size only when you switch windows often, which more or less is exactly how most people use office apps.
Of course MS snatched defeat from the claws of victory on the UI front with Vista. There the toolbars are all over the place, and the menus, lists and sidebars, panels, buttons at the bottom, top and on the backside of your monitor. When MS started to copy OSX someone should have told them that iTunes isn’t the best place to start…
Oh, and KDE’s and XP’s control panels are a triumph of usability compared to Vista’s.
I’d be really interested in a DE where the office UI was used consistently for all apps. I suspect it might not work quite as well for some kinds of apps, but overall it’s the best alternative to the old menus+toolbars paradigm that I know. (well, apart from the the elegance and simplicity of the CLI of course =)
I haven’t used Office 2007, but the screenshot seems familiar to me in terms of UI elements. Is that toolbar any different from a tabbed toolbar?
If so, these things already exist, and while they are useful (i.e. they can accommodate more options with less screen space), they fail to solve another problem. The reason why toolbars with many items are of limited efficiency is that there are only so many items a user can remember visually. Basically, if the user has to hover the mouse over the toolbar to get a tooltip, the whole point of the toolbar is lost — it becomes just as efficient as a menu, only with more sugar.
Huh?
In Office 2007 you can more or less create your own toolbar with the stuff you really need in the titlebar (+the file menu).
Admittedly in the last paragraph I *did* mean both the toolbar in the window title bar and the ribbon but the rest clearly wasn’t about the ribbon.
If so, these things already exist,
Where? AIS I’d really be interested in a DE like that at least to have tried it once.
Basically, if the user has to hover the mouse over the toolbar to get a tooltip, the whole point of the toolbar is lost — it becomes just as efficient as a menu, only with more sugar.
The idea is that you have a menu but with more screen real estate so you can have icons for all entries and text for the most important ones plus titles for different grouped icons.
http://upload.wikimedia.org/wikipedia/en/4/4c/Office2007ribbon.png
It makes for easier access to functions, especially instead of large menus (that’s the reason MS switched to the ribbon).
Imho the tabbed nature could be more of a problem in progs where you need only one entry of a menu and after that don’t need the menu at all for a long time. In that case instead of menu->entry you’d have to click menu-tab->entry->home-tab to get back to the normal toolbar.
The reason I’d be interested in such a DE anyway is that I think there are possible work-arounds to that problem.
I haven’t used Office 2007, but the screenshot seems familiar to me in terms of UI elements. Is that toolbar any different from a tabbed toolbar?
Huh?
In Office 2007 you can more or less create your own toolbar with the stuff you really need in the titlebar (+the file menu).
Well… I was referring only to the ribbon.
A tabbed toolbar is, well, a combination between a toolbar and a tabbed view. You have one toolbar with several tabs — and, as you click each of the tabs, a different set of buttons is displayed. Much like, ugh, this one: http://www.library.uq.edu.au/iad/databases/images/bsp_tabbar.gif .
I’m not sure what you meant by the office UI used consistently for all apps. If you refer to using a widget similar to the Office Ribbon for every application, I don’t know of any; afaik, all past experiments with something similar haven’t been too successful (in fact, a couple of 3rd party apps to patch the Office Ribbon and give MS Office its old look are already around). If you refer to all applications having a consistent, similar interface, that’s NeXTStep, and if it wasn’t for Steve Jobs’ stupid ideas it might have got much further than being chopped into OS X.
The Ribbon was invented as a response to feature creep and too many menu options.
It basically only works for applications with many menu options.
I agree with your comments about Fitts law, but global menubars break basic UI design. The application menus belong to the application and not to the screen/desktop.
It’s not my place to say which set of laws should win, but there is a conflict between them here.
It should be noted that in the Mac paradigm, windows belong to applications, which exist independently of windows. The menubar is the central representative of the application as a whole, so it makes sense to put application-global functionality in a place separate from any window. Most other UIs conflate applications and windows in a way that the Mac UI does not.
And that made beautiful sense when we had a single-tasking Finder. I liked it, anyway.
That is true. If you had a system with a large number of multi-window applications, that system would do well with the Mac-style menu bar. Windows and Ubuntu are not such systems, however
but then you dont have the funny experience of closing every window and still have programs running.
i would love to toss the whole idea of programs. rather make them into plugins or extensions tied to file types.
if i have a file type open, said plugin is loaded by the system. when no such file type is active in any window, toss said plugin away for now.
today one have to all to often link file types with programs to get anything done…
but then you dont have the funny experience of closing every window and still have programs running. but then you dont have the funny experience of closing every window and still have programs running.
Correct — but, like I said, there are a lot of users to whom this experience doesn’t sound “funny”, but perfectly logical.
(More uninteresting historical rambling, skip if you’re in a hurry or simply don’t care about why today’s interfaces are like they are:)
I read once (but I can’t claim it’s true) that this app-runs-but-no-window-open comes from the desktop analogy. The earliest more complex Mac programs took a rather lengthy time to load, and it was sometimes more convenient not to exit a program completely if you knew that, while you don’t need your computer in the meantime, you will need that program later. By analogy, if you write notes in a notebook, and then you put it away for a short time, it’s reasonable to expect that, while it’s not in your attention (i.e. there is no “window” for it), you don’t want to close it and put it in a cabinet — but just open it later. Remember, cluttered taskbars can be even more painful than single-tasking systems (which was, indeed, the original reason behind this whole thing).
sounds a bit like the experience i have read about with symbian. there programs dont close when closed, but stay in memory until something else comes around that needs the memory…
some people love it, some people hate it, and there are special programs created to enable the user to take better control of it all.
I’ve been a Mac user since 1987 and I used to quote Fitt’s law and all the other standard reasons for having a top menubar. Then I actually tried timing my response and others to a request to find and click on a menu item under Mac OS X and Windows. My experiment found that having the menubar at the top of the screen made no measurable difference. My observation was that most of the time isn’t spent positioning the mouse (the part Fitt’s Law applies to), but recalling which menu to select and finding a menu item. Menus are not as efficient UI elements as buttons in terms of time to action, Fitt’s Law proves this, and so you gain nothing by putting menus that change per-application at the top of the screen. My theory is that the top menubar is a hold-over from the original design before the Mac could run more than one application at a time, then it made a lot more sense and Desk Accessories had no menubar probably for this very reason. I don’t think Apple revisited the menubar when they were forced to implement the MultiFinder to stay competitive.
GNOME uses mostly static buttons (with the exception of three static menus) in locations positively effected by Fitt’s Law. GNOME has correctly applied Fitt’s Law and Apple hasn’t in this case.
“””
Then I actually tried timing my response and others to a request to find and click on a menu item under Mac OS X and Windows. My experiment found
“””
Your empirical approach is refreshing. 🙂
Uh, the word your looking for is “anecdotal”.
Anecdote is what you use when you don’t have a good empirical rule. Empirical rules are, in turn, what you use when you don’t have a good theory.
Since we have a good empirical rule in this case, excuse me if I’m not readily willing to abandon it in favor of anecdote…
It sounds like you missed my point. I am not disputing that putting the menubar at the top of the screen makes it a faster target to acquire than a window menubar. This is, as you said, a well studied and an established rule.
I am arguing that when you take it a step further and ask a user to perform a full action, which requires them to recall the location of a menu item or search for it, that the time saved by having the menubar at the top becomes so small it is meaningless. At the time I was interested in this, I couldn’t find any studies of the top menubar that went beyond target acquisition and focused on the user’s time to perform tasks in actual applications, which is why I did it myself and was surprised by the results.
Not to completely derail the thread, but why not offer circular menus? How about a patch to bisect the display of contextual menus at the mouse cursor so menu items are closer to the cursor?
(credit to Victor Zambrano for this idea)
http://www.asktog.com/images/fittsCascadingMenus.gif
These features can be enabled by default and potentially help more users so they arguably make more sense than an off-by-default top menubar.
>Anecdote is what you use when you don’t have a good empirical rule. Empirical rules are, in turn, what you use when you don’t have a good theory.
And a good theory is what you have before reality gets in the way!
I think it is great that someone actually bothered to measure something real, rather than relying on a theory that tells just part of the story.
It has been proven by real world testing time and again that what you’re saying is infact true. The gain from using Fitt’s law is lost by having more then one application on the screen and having to refocus the mouse to the application after you got it so far away from the application. The fact that you’re saying its the same time alone is a bit inaccurate.
to prevent Microsoft form saying that GNOME violates there patents for the look of menus
Edited 2007-05-18 01:37
Fitt’s law doesn’t seem appropriate for 2 reasons:
1) If an action is frequent enough that efficient access is needed, it would be placed in the toolbar of the application window.
2) Menubars require 2 clicks to activate an item. Any speed gains from opening the menu is lost in finding the menuitem, after the menu has opened.
When people apply Fitt’s Law to mouse distnace, they often forget that distance on the screen is not one-to-one with distance of the mouse.
There is a region around your pointer that does not require you to move your wrist, and is thus very easy to mouse to. Mouse acceleration makes this region larger, but usually not large enough to cover the entire screen. There is a region surrounding that for which you need to move your wrist. And there’s a region surrounding that for which you need to pick up your mouse, move it, set it back down, and move it some more on the mouse pad.
Obviously, where each of these regions lay depends on your screen size, mouse acceleration settings, mouse skills, mouse pad size, and other factors. Nonetheless, most people can’t hit their entire screen without at least moving their wrist. I can hit a little over a quarter of my screen without moving my wrist.
What’s more, other types of input devices (track balls, touch pads, stupid little nipply things) have different ways in which the input device motion does not map one-to-one to screen motion. And touchpads, at least, are fairly common devices, since most laptops are equipped with them.
None of this is to say that the spirit of Fitt’s Law is bad. It’s just that with modern screens and input devices, the screen corners aren’t quite as magically easy to hit as the too-simplistic Shannon formulation might suggest.
Im currently on a laptop trackpad, at 1440×900 resolution, and i can go from the very bottom to the very top of the screen with two full swipes accross the trackpad.
The idea behind the global application menubar streaches fittes law a bit, it is that you only have to aim in two directions, instead of four. That means you can “throw” your mouse up to the top of the screen with reckless abandon, secure in the knowledge you will alwas hit your target. Then it is a matter of left or right. Menus in applications require you to slow down your mouse movement as you approach the (roughly) 20×30 pixel target. While you could argue that because of modern resolutions, application level menubars are equivilent in speed to the global menubar, due to the aiming in only one direction, and the consistant fixed location of the widget, the global bar will alwas take less effort to use, which leads to a more pleasent experience.
Fitts law is a bunch of bollocks quoted by usability experts to try to make what they do sound scientific. Any change that requires quoting Fitts law to justify is generally a bad change.
People don’t spend most of their time hunting for the menubar so shaving a fraction of a second off the time to find it is pointless. Doubly so if the change forces people to work in a new way that they are uncomfortable with.
For applications with large windows, where the top of the window is close to the top of the screen, on a single monitor under 1280×1024 in size, I can see this being true.
For applications with small windows (like IM programs), or on computers with multiple monitors, or large monitors (1600×1200 for example), separating the menu from the active window makes things harder. Especially if the menu always starts on the left monitor, and you are working on windows in the right monitor.
As with everything, there are times when one way is better than the other. Making it a togglable option is good. Forcing it on users is not.
Anyone using multiple monitors on MacOS X care to comment on it?
Because menu-bar usage is common. Instead of carefully aligning a cursor where it goes, you can just flick it upward.
thats to hit the bar in general…
but then you have to find the specific menu you want, and the entry in said menu.
keyboard shortcuts for the win
How would that work if you have an app open on monitor 2, and the global menubar starts on monitor 1? Going straight up doesn’t hit anything but empty space.
i literally hate the top menubar concept. it’s counter-intuitive. something that belongs to an application must be part of the application window.
and anyway, it “cant” work on X because it would require all toolkits to support it. it would be a major usability problem to have have applications supporting it and applications not supporting it at the same time.
2 words: bad idea. and like the first guy said, people are requesting it because osx has it. show me usability studies first…
The usability studies for this particular concept were done decades ago. The Wikipedia article I referenced shows that Fitt’s Law has been shown to have a correlation of 95% in hundreds of studies conducted since the mid 1950s when the law was introduced. The menubar application is one of the fairly rare instances in psychology when the result falls very neatly out of a very simple and well-supported equation.
2 words: bad idea. and like the first guy said, people are requesting it because osx has it. show me usability studies first…
I can come up right now with Fitt’s law http://en.wikipedia.org/wiki/Fitts_law . While it may not be a usability study per se, I agree with the conclusion that a menubar on the top of the screen is easier to reach than a menubar in a window. The only thing I have to do to reach the menubar is kick the mouse to the top of the screen. That requires less coordination than reaching a menu item in the middle of the screen.
but you still have to find the part of the menu that you want…
look before you jump, grasshopper
and anyway, it “cant” work on X because it would require all toolkits to support it. it would be a major usability problem to have have applications supporting it and applications not supporting it at the same time.
KDE manages fairly fine with it. GNOME+this patch as well, especially taking into account this patch is done and maintained by one single guy.
True, but even in KDE it only works for other KDE (do plain QT apps work?) apps. Having GNOME and KDE interoperate in single menu bar mode would be good, but the other random toolkits will still not support it, making the UI more inconsistent across toolkits than it already is. 🙁
Yes, it works very nicely indeed with both KDE and Gnome applications.
http://img519.imageshack.us/img519/6160/gnomeob8.png
http://img374.imageshack.us/img374/1056/kdeoi6.png
Yeah great if you only have a single screen i suppose. But this would be a nightmare for multi screen users!
Why? If the patch is extended for multi-screen purposes, GNOME has a chance to do something better than Mac OS X: One menu bar per screen, that changes depending on the last selected app on that screen.
But the reason the single menu bar approach works so well on the Mac, is that you almost never need to access the menu. Which is how applications should work. Menus should provide the full palette of functions that a program performs, but frequently-used functions should have both buttons and shortcut keys, so the user only needs to go to the menu in case she wants to do something out of the ordinary.
Menus are extremely bad usability-wise. They are, in fact, the worst invention since software patents. They require immense mouse precision, are hard to find your way through, are very unintuitive, and worst of all they treat all actions as if they were equal. They’re not; some are performed more often, others almost never.
Mac OS (X) has relied on shortcut keys for many years, and has achieved great consistency in this regard, thanks to the Apple HIG (and similar projects). I am unsure whether GNOME applications have reached a similar level of consistency, as to enable this kind of UI-enhancement. It is only a good idea to get the menus out of the way if you only need them rarely.
– Simon
I agree with you on that regard, but that’s not what the articles talking about. And knowing Gnome, this would be another featureless balls up like their spatial implementation, half backed and useless. Thankfully it’s only being looked on as a secondary feature if it all
I love the KDE Global App Menubar and use it. If I were able to use my GTK apps with the menu at the top of the screen, I would certainly use more Gnome/Gtk apps. In fact, for awhile now, the ONLY reason I haven’t been using Gnome is because of the lack of a Global Application Menubar. I always felt that it was odd that they didn’t have one, since the Gnome team seems to pride itself on being the more “Mac-like” of the linux DE’s.
I agree, having had to use macs at uni, I think the one menu bar approach sucks. If I have several windows open and I want a particular option, I can go straight to it because I can see it even though the window is not the active one. With macos you must first select the app and then wait for the menu and then select the option.
Maybe if you running everything full screen it could be automatically enabled, otherwise it is automatically disabled.
A better approach would be RISC OS’s pop up menu, no window ever had menus, you could reach what you need without moving the mouse: just pressing a button.
Edited 2007-05-17 19:53
God no, RISC OS was a usability nightmare… well I could never use it although they always claimed children could!
This should be done in a way that you can mix and match Gnome and KDE applications. That way there will be enough applications to chose from not to create usabilty problems.
There will allways be some application that doesn’t conform to HIG standards but over time users either find other solutions that do, or learn to live with it.
If both Gnome and KDE worked this way there would be a large pressure for other toolkits to follow.
However, I think just making KDE and Gnome apps using a MacOS like menu by adding some patch to Gnome is not the way to do it. Instead I would like to see a standardized protocol for a menu manager. We allready have window managers, desktop managers and session managers in X11, why can’t we have a menu manager.
One such menu manager implementation could implement the MacOS like top of the screen menu behavior. Menu managers like this could also make it easier for people
to create accessability and scripting solutions.
This is something that should be added to X11, and not specifically to Gnome.
This is something that should be added to X11, and not specifically to Gnome.
God lets hope not. X should have nothing to do with menu behavior. It is not the domain of X11.
[i]it’s counter-intuitive. something that belongs to an application must be part of the application window. [i]
“It’s [counter-]intuitive” is just a fancy way of winning an argument by making a supposedly irrefutable point that “I’m [not] used to it” = “that’s [not] the way it should be done”.
I learnt GUI’s on the Amiga, which had a menu bar at the top of the screen accessed by pressing a menu button. So coming to Windows/Linux was weird, because menus are (usually) at the top of the window. Not only is that “counter-intuitive” afaiac, but it also wastes space.
it’s counter-intuitive. something that belongs to an application must be part of the application window.
No, it’s not counter-intuitive, it’s just that you are not used to it.
Ignoring the technical, UI, human issues entirely, the flak they’d get from the community would not be worth it alone.
“””
Ignoring the technical, UI, human issues entirely, the flak they’d get from the community would not be worth it alone.
“””
Indeed. To the the people invoking Fitt’s law from high in their ivory towers, I’ll mention that “New Coke” won the taste tests back in the mid 80’s, but the people demanded what they were used to, and the old Coke formula had to be reinstated.
Most of my users end up asking me how to make Nautilus “not open up a window for each folder” despite all the academic arguments in favor of spatial mode’s superiority.
Indeed. To the the people invoking Fitt’s law from high in their ivory towers, I’ll mention that “New Coke” won the taste tests back in the mid 80’s, but the people demanded what they were used to, and the old Coke formula had to be reinstated.
There is no “Coca Cola Classic,” because the whole “New Coke” fiasco was a publicity stunt set up to allow the company to switch from sugar to corn syrup. Check the ingredients listing the next time you buy a bottle and compare it with a bottle of Pepsi–notice the difference? Pepsi still says and or corn syrup, whereas Coke in most places simply states corn syrup…
–bornagainpenguin (who hated the new coke as a kid, but has come to enjoy it over the years as Coke II…)
is that if this god-awful feature come to Gnome that there be a simple, obvious way to turn it off. I hated snooping around to turn off the spatial navigation _feature_. I remember when “delete” left the context menu and I had to figure out how to put it back.
OK, I admit it, I’m old. Leave my desktop alone!!
is that if this god-awful feature come to Gnome that there be a simple, obvious way to turn it off.
Can you read? I quote:
“as an option, *turned off by default*?”
Emphasis added.
Oops!
[EDIT: I tried to mod my previous comment down, but I couldn’t. Oh well.]
Edited 2007-05-17 19:55
How can you mod your own comments up or down?
You can’t. I thought maybe you could mod it down if you wanted, but that is also not possible.
I modded you down, sir. I never expected gratitude for that before, and it’s refreshing.
Having a single menu for multiple programs, while it might make a slight saving of screen space is essentially flawed because it requires the user to switch windows before they can access the other menus.
Think about it this way: two programs open, select some text, use the menu of program A to copy, and the menu of program B to paste.
And on a Mac: two programs open, select some text, use the menu of program A to copy, select program B, use menu of program B to paste.
Yes, this is a very simplified way of looking at it, and sure for some the difference would be unnoticeable (ALT+TAB is the best), but it still doesn’t have any obvious advantage other than you always know where the menubar is.
Edit: Not that I think the feature shouldn’t be added if people want it, just as people got used to Windows I guess some got used to MacOS.
Edited 2007-05-17 19:49
Think about it this way: two programs open, select some text, use the menu of program A to copy, and the menu of program B to paste.
And on a Mac: two programs open, select some text, use the menu of program A to copy, select program B, use menu of program B to paste.
Or you could just drag and drop the text, but that would likely be too simple.
Or you could just drag and drop the text,
Or, use control+c and control+v.
Or, use control+c and control+v.
That’s the exactly the thing though, people who get used to the global menubar find themselves using various shortcuts that don’t rely on the menubar at all and if you happen to need to find some obscure option you go to the menu. For the majority of the time though the gloabal menubar stays out of your way, which in my mind makes it superior.
However, rather than a global menu bar I would prefer an interface that allows the left click to select an object and then the right click to give you the available ways to manipulate it used throughout the operating system.
tryed that on windows lately?
add some programs and see how big that menu can get…
Yes they way right click is somewhat how i’d like it to work but not completely i don’t want just a menu i almost want some kind of manipulator mini app to come up and let you make live changes, play around and then commit the change to the document or application or whatever. I’m not entirely sure yet I’d have to flush it out more.
while the concept sounds good at first, if said mini-app is supposed to be expandable somehow i cant see how it will be a improvement…
but then your right, it needs to be fleshed out more…
actually, drag and dropping text does not work in safari.
but you should use the short keys anyway. most of the time i have my applications maximised. so having the menu bar always at thesame location is a good idea.
but the real question is should it be an application or a window menubar.
“actually, drag and dropping text does not work in safari”
Eh, what? Works fine here.
actually, drag and dropping text does not work in safari.
Huh? Care to elaborate?
Dragging and dropping text does work in safari… Even in comment windows, etc…
I was going to say thats why the Mac supports drag and drop, but the other guy but me to it.
To me, people are obsessed with there desktop looking like OS X and no we shouldn’t have this feature in GNOME. Ubuntu seem to be on a crusade to change GNOME at a fast rate, this is why Ubuntu/kubuntu becomes more buggy.
Why do I say this?, well Ubuntu people complain about GNOME being buggy when it’s not GNOME, I have compiled it on slamd64 and it has no bugs like they have.
The menu bar is a direct copy off OS X, I just dont like that since already GNOME has a similar feel to OS X anyway.
Edited 2007-05-17 19:56
I can agree with the rest you said, but this doesn’t make much sense 😉
I can see why you wouldn’t use it (I tried it in KDE for some time, didn’t like it at all) but then, others might. And some argue for usability reasons. So if they keep it off by default, or at least configurable, what’s the problem of allowing a potential usable feature in?
“The menu bar is a direct copy off OS X, I just dont like that since already GNOME has a similar feel to OS X anyway.”
Same argument I used as a “for”
Actually, I don’t think this should be on, but I would like to see it as an option. They’ve simplified the interface so much, what can be wrong with one frill?
(ducks head)
It’s interesting to put some numbers to Fitt’s law:
T = a + b log2(D/W + 1)
We consider two cases: menubar at the top, and menubar in the window, both on my MacBook (1280×800 screen). In both cases, we’ll assume we’re trying to hit the menubar from a resting position in the center of the screen. We’ll simplify the math by considering vertical motion only.
Consider the first case, with the menubar at the top. In this case, D = ~400 pixels. W is not infinity, but a number bounded by the maximal overshoot that would occur using the quick mouse movement used to reach the menubar. In my experiments, if I move the mouse with the same motion I use to hit the menubar, I can get within about 50 pixels on either side of the target. This means that W for this case = ~100 pixels.
Now, consider the second case, with the menubar in the window. Of the several dozen Windows I have open right now, all of them are within about 200 pixels of the top of the screen. Thus, D = ~200 pixels. W is the height of the menu bar itself, which is 20 pixels (OS X uses particularly large menubar text — the number for GNOME would be even smaller).
Now, for the first case, we have:
D / W = ~4
And in the second case, we have:
D / W = ~10
So, even though the distance to the target doubled, the overall ratio is still better because the effective width of the menubar increased by a factor of five.
There are some arguments on the other side, but none are particularly convincing. Yes, if you’re trying to activate a menu entry on a window that doesn’t have focus, there is some extra motion involved with the toplevel menubar. However, that argument is mitigated by two factors: first, IIRC, GNOME discards the focusing click, so you can’t click directly on the menubar of an unfocused window anyway. Second, the toplevel menubar is usually designed to be a per-application menubar, not a per-window menubar. While it may be fairly common to want to click on the menubar of an unfocused window in the same app, it’s probably much less common to want to click on the menubar of an unfocused window in an entirely different application.
Also, while larger monitors might increase the D term in the above equation, it doesn’t increase by much. My 20″ monitor on my desk has a height of only 1050 pixels, and the 24″ one I had before that only had a height of 1200 pixels. If you run the numbers, you can see that the change in D still doesn’t offset the change in W. Moreover, the popularity of laptops (and the attendant poor pointing devices therein) further works against that particular argument.
Hey Math majors, take two Eigenvalues and call me in the morning!
Seriously, I don’t think the main problem is in the Linear Algebra world. The main reason this _might_ help is for newbies. They would have only one place to look for “drop-down thingies”. Menus are very confusing to new computer users. I think that is a more important question than Partial Derivatives in N-Space.
However, if it is off by default, go for it! I’ll never see it.
[Edit: spelling]
Edited 2007-05-17 20:16
I’m a certified non-newbie and I find the feature useful every day. The menubar is one less thing I have to carefully aim at every day using the blunt instrument that is my MacBook’s trackpad (which is quite good as laptop pointing devices go…)
I have to agree with that, trackpads can be quite a bummer. I cover mine with a credit card and tape, since it has no off switch!
> “I have to agree with that, trackpads can be quite a bummer. I cover mine with a credit card and tape, since it has no off switch!”
That’s great, that way you can sell your laptop a lot less cheap on the second hand market, since the trackpad will be looking brand new!
Yes, touchpad can be quite difficult to work with. Personally I prefer to use the pointing stick (called TrackPoint) on my ThinkPad. I find it more accurate and pleasant to use than a touchpad… I don’t have to move my hands away from the keyboard to use the mouse. I would like to have this pointing stick feature on desktop computers as well…
> IIRC, GNOME discards the focusing click,
No it doesn’t.
> so you can’t click directly on the menubar of an unfocused window anyway.
Yes you can.
(edit: funny stuff in html in osnews beta)
Edited 2007-05-17 20:29 UTC
Assuming we concede this part of the argument based on distances, then (as a previous post mentioned) it still ignores the time issue of switching between app focuses before the menu becomes available instead of being able to go directly to an inactive window’s menu. This may be partially mitigated by, for example, the dock’s context menu, but those are incomplete, anyway.
This is completely anecdotal, but it seems I’m more sensitive to timing than to distances. I can cross the screen and hit visible things or perform a gesture in a screen subset in less than a second, since I have the benefit of knowing everything is going to be at the same place. Though that might just implying that “searching” the changing menu bar is an issue, and that’s not what I intend.
> Yes, if you’re trying to activate a menu entry on a
> window that doesn’t have focus, there is some extra
> motion involved with the toplevel menubar.
From experience, I can tell that much worse than the extra motion is the confusion when you are trying to access some program’s menu, but have another one focused. You keep looking for a menu item that isn’t there, until you finally realize that you’re dealing with the menu of another program.
If you have multiple heads, and you happen to be on the head without the menu, what then? Now you flick your mouse up only to realize that the menu’s clear over on the other side. Simply extending the bar to span both displays won’t work; however, I suppose you could duplicate the menus on each side.
One of the advantages of having the the menu bar in the window is that the window becomes its own orthogonal environment that doesn’t depend on UI elements located elsewhere.
I think the fundamental problem is the WIMP paradigm and its emphasis on the mouse. Stop worrying about marginally reducing the time to access the menu bar, and eliminate the need to access it altogether. Make the keyboard the emphasis.
Add it in! It’s off by default. And some people like it, especially those coming from the Mac platform.
Plus, if applications are designed to handle having their menu bars in both locations, then GTK2 apps ported to the Mac should fit in better.
This seems like a very sensible solution.
In order to use a global menubar, it must be universal; it would be a sore spot to watch there be some apps continue to put the toolbar in the window instead of using the global toolbar. Will KDE apps know to use the menu bar? If gnome did this, it would have to be incredibly consistant against all the apps that run on it. Nothing will look more unpolished and unprofessional than seeing two menubars on the screen. The only reason I don’t use the menubar in kde is because the gnome apps I use(I prefer gaim/pidgin) don’t use the global toolbar(last I checked), and they look ugly.
Assuming that problem isn’t an issue, you’d have to do usability testing to make sure that that style of menubar is more efficient. It may be more efficient for a mac, but is it for a gnome desktop? Will it help people get work done faster; is it worth the cost in desktop space?
The only problem I see really with it is consistency, and simplicity. It has to “just work” without tweaking to really have any magic behind the idea. I don’t wanna watch amarok not honor the global menu bar, for example.
I guess what I’m saying is, I’d honestly like to try it; but I don’t want to “fool with it”. It has to show a good deal of polish before it’d be something I would consider using it daily. If you can’t imagine learning to work with it as “default” why use it at all?
When building applications and a coherent system, Mac-style is is more problematic because not everyone uses the same interface standards. An application may not even have the component that the Mac-style menu bar is displaying.
When maximized, the Mac-style menu bar works the same as Windows-style.
When sized to a fraction of the screen with other windows present, the Mac-style menu bar:
1) conserves the vertical space of n-1 menu bars, where n is the total number of windows being displayed.
2) shows less information because only one application menu bar can be shown at once.
3) forces the user to click an inactive window once before they can access the menu bar for it.
4) is farther away from where the mouse is (the currently active window), forcing the user to move their mouse longer distances for menu bar actions.
Conserving screen resolution was important when we were using 640×480 screens. Today, families have 1280×1024 resolution screens. Artists have 2560×1600 resolution screens. It doesn’t take a rigorous study to look at the users of these interfaces and see that they don’t need to save the n-1 vertical space when multiple windows are tiled.
The Windows-style menu bar keeps all application functions grouped into one window element, which is analogous to the physical world where the handle of a hammer is attached to the head, and the power button for the blender is on the base of it. Detaching a control menu from the tool it affects is a purely virtual construct, and presents an intuitive leap for new users.
By my count it is hard to justify providing the Mac-style menu bar in an optimally designed user interface. Legacy users might want it, and that is fine. But I wouldn’t present that interface to new computer users.
Edited 2007-05-17 20:23 UTC
No it doesn’t.
Maximised windows on Windows have their menus offset from the top of the screen. The effect of this is that it is harder to hit a Windows menu than a Mac menu. On a Mac you throw your pointer to the top of the screen and then you’re there where the menus are. On Windows with a maximised window you throw your pointer to the top of the screen and then have to go down a bit before you can hit a menu.
The Mac’s menu bar is not about conserving screen space, it’s about ease of use.
Yes, we have much larger screen resolutions these days, but our windowing software also includes mouse acceleration, which makes it easy to reach the top of the screen.
The best solution that I have seen however was RISC-OS, which used the middle mouse button (on a three button mouse) to pop up application menus.
“4) is farther away from where the mouse is (the currently active window), forcing the user to move their mouse longer distances for menu bar actions.”
Which is a view which is opposed by Fitt’s law because nobody is pixel perfect in their mouse movement. Having the menu bar in the application window almost always requires a second mouse movement to reach it because the first one overshoots. Or it requires you to slow the mouse down before clicking, meaning it takes longer time.
The exception might be FPS-gamers.
It would be interesting to see any studies about the effect on RSI on these two different types of menu bar placements.
there is some fundamental error in the “it’s off by default, who cares, put it in” argument that I strongly need to point out. features, even off by default (which are the worst ones) are a maintainership burden. they introduce bugs, code changes and different code paths that affect how the applications and libraries behave. this is even worse if the feature must be turned on: it means it won’t get proper and widespread testing upon release and that changes in the code might silently break it without the maintainers noticing.
a “off-by-default” feature *never* comes for free; so don’t ask for an “off-by-default” feature: either ask for GNOME to have a desktop menu bar or not.
Edited 2007-05-17 20:23
Options = good
If i’m a mac user used to the MAC way, I got the option to do it more like a mac.
I would most likely never use this as when I had a mac, this is one of the few things that drove me nuts.
However, I also find people that make their DE a Mac UI clone very humorous. If you like mac that muc, just get a mac and let linux work/feel like linux….
But Linux != GUI.
One can like the desktop of Apple, but prefer the kernel and userland of GNU/Linux.
That’s why there are plenty of desktops for X, to each one his own.
Seems like this would break the focus follows mouse option which most older X users like best. MacOS doesn’t have that option. That alone would be reason enough to just say no.
Certainly this is one of the strongest points against system wide menubars (either the Mac or NeXT style) – they completely, absolutely kills focus follows mouse.
Since I was brought up on Macintosh System 6/7, however, I’m very much used to this menubar flavor, and I feel it’s more elegant than having menus in windows. One reason is that it makes it feasible to have applets in the menubar, another is that it doesn’t take up space in every window, and finally there’s the inevitable Fitts’ law.
Even more elegant, though, is to get rid of the menubar all together by only using right-click menus. This is one of the distinguishing aspects of RiscOS. To get a taste of this concept, you needn’t look any further than ROX-Filer (Risc On X).
Wouldn’t it be better to introduce this as an applet that could be added to the existing gnome menu bars? It could simply build off the existing GNOME infrastructure and perhaps, use some standard KDE-GNOME “free-desktop” standard for menu-bars at the top of the screen…
Wouldn’t it be better to introduce this as an applet that could be added to the existing gnome menu bars?
This patch IS a menu applet.
It works on Mac because the menu is independent of the application windows. You can invoke application functions, even without an application window open – for example Mail.app can check for new mail without having the interface open. In other operating systems, this is handled through a seperate background process or tray icon.
Trying to tack global menus onto a system where the applications are fundamentally designed around a menu-per-window basis is a flawed approach.
I agree, the keeping background apps open is an important aspect of OS X. This would bring usability concerns into GNOME’s use of the system tray vs. Apple’s use of background apps and a dock.
However, I really feel a global menu is a good step forward, and it’s only an applet anyways. It’s very hard to patch GTK out of main, and still keep apps normally updated in a main repository, so perhaps an off/on could be implemented for the GTK patch in upstream, and of course one could install the mac menu .deb for themselves.
That’s an excellent point though. The advantages of a global menubar must be considered in light of the fact that a global menubar isn’t a drop-in replacement for a per-window one. If this feature were included in GNOME, it would have to be a non-optional feature, with wording in the HIG to ensure that people design their menus appropriately.
There’s something else that’s important.
In Mac OS X, there’s no underlined letter in the names of menus in the menu bar. Gnome does have that, and I prefer to use the keyboard (alt + [letter]) to bring up a menu.
If you don’t have to use the mouse to actually go to the menubar and look around in it, the universal menu bar (position) is unimportant. Especially on laptops, I prefer not to have to use the mousepad thing at all.
Long live alt, tab, shift, and the rest.
Keyboard navigation of menus is possible in OS X, but like all OS X shortcuts, they’re longer winded than on Windows. Press Ctrl+F1 to enable full keyboard access if it’s not already (this is a once only thing). Use Ctrl+F2 to select the menu and you can navigate with arrows, or by pressing letters – but the letters do not auto expand/select though.
I would love that! Title bar, menu bar, tool bar, status bar — all these bars in every single application just distract you from the main task. And I would prefer the solution which can work around all this noise: one menu bar in known place, one status, one toolbar — and move all of them somewhere, where it does not distract you.
One other crazy idea I’ve had is to put a single global scrollbar on the right of the screen, so that Fitt’s law is used in scrolling.
I always end up moving my windows so the scrollbar overlaps and I can throw my mouse to the right side of the screen to scroll. Much easier than picking out a thin scrollbar that doesn’t hit the edge of a screen.
I like scrolling idea, implemented in bbnote (notepad for black box). Scrollbar is not a bar, it is small rectangle in the client area over the text. It does not need to take entire column. It could be even transparent.
I think that’s why trackpads are so successful these days, they have their own mini-scrollbar that follow Fitt’s law (throw finger to the right-most or bottom-most edge)
Why? If it can be done and someone wants to do it, then it should be done. Why not? Zealous defenders of the status quo object. Who cares? Apparently a lot of people who apparently desire to deny their fellow GNOME users a choice. Choice is good. Choices for UI options are good. If GNOME ever denies me the option of having my menu bars attached to the windows with which they are associated, well, there are a lot of other quite usable DEs out there. Until that time, I’m just going to sit back and watch the flamewar.
I’ve been using the ubuntuforums patch for a while now.
Things look *so* much better with a global menubar, windows less cluttered; in terms of usability, Fitt’s law is put to use, and finally the two-panel split that GNOME has actually makes sense, and you can make use of a lot of that empty space at the top (or where-ever you so choose to put the Mac Menu applet).
In short, I would be thrilled to see it in GNOME as an option and have commented as such on the bugzilla bug previously (not spam, of course).
BTW don’t kill me, but I would like to see the taskbar go away too…too 80s for me
I’m not talking about copying Apple here, as of course WindowMaker, NEXTSTeP, etc all had docks before OS X.
Some problems with this patch: same with KDE’s– you can’t make it transparent or semi-transparent with the panel bar color, since it seems to just take the app’s menu instead of *really* integrating it into the panel.
Edited 2007-05-17 21:29
Surely someone can do PhD on this. I’m Ok with that. But I do not like when someone decides what is good for me. It is my choice. All people are asking now is just a possibility of a choice. I know, it is always good for me to bye a huge monitor, new processor, video card and a lot of memory to run something like Vista. But I’m working on a small old notebook with OS OS, because I like it. If some of us like something, it is enough to be respected. No research is required to explain that it is bad, that you are fool, if you like it.
…I’d still want the menus accessible on the panel. That way the menus would always be in a fixed place, and they’d clutter the applications windows a lot less. Besides, since it would be optional and not even enabled by default, what harm would it do to anyone? Generally I don’t even need menus in any of the apps I use: I customize the toolbars to suit me, and as such, the menus are more or less just a waste of space.
build it, but let users decide at their own wether they want to use it or not…
In addition to Fitt’s Law I would like to introduce the laws of visual relationships.
http://en.wikipedia.org/wiki/Gestalt_psychology
Putting the menubar outside its application window is actually bad HCI. I know studies have been conducted before, but I doubt they assumed the high number of windows and the huge screen resolutions we have today.
What really annoys me about Mac is that I can’t tell which program the active menubar belongs to if I have many windows open – at least I have to first decide visually which window is active and only then can I tell what the menubar at the top is for.
Also I would like to add that the menubar isn’t so important anymore. The coefficient from Fitt’s law should be multiplied by some factor of importance. If something of low importance is placed somewhere with a high Fitt number, it should count in a negative way. Having a high Fitt number and a low importance is counter-intuitive.
(disclaimer: I’m not participating in the overall discussion, I’m just making a point)
Exactly, menus are more effected by Hick’s Law than Fitt’s Law.
http://en.wikipedia.org/wiki/Hick%27s_law
That argument is completely orthogonal to this one, though.
I suppose that the application menu next to the apple in the top right hand corner of the screen is too difficult to read… You know, the menu that is the name of the application.
Do people compute with blinders or something?
Well, it takes some time getting used to it — it’s simply that the active window has a more obvious shadow. It’s easy enough for me, I never had that problem and I’m working with two 21″ screens, meaning about 8 or 9 windows open at any time.
(Later edit)
And finally, my favorite ranting topic: people are not eternally newbies! Just as in real life – the more you drive a car, the more you feel accustomed to it. There is no reason to replace the steering wheel with a joystick-type-thingy just because it would feel “more logical” to a fresh driver, even more so because if you have just learnt to drive a car, your preferences in what concerns the interior and controls of a motor vehicle are likely to develop as you yourself develop as the driver.
A couple of years ago there was a pretty heatened debate regarding this. There were several new approaches in GUIs, from 3D desktops to alternative input methods (like mouse gestures) or paradigms. Googling a bit will reveal what seems like hundreds of new ideas about what seemed like the “desktop of the future” in the early 90s — yet all we have now are the desktops of the 1980s with more colors.
The reason for this is that when the first GUIs were conceived, the master idea was that of the desktop analogy, even to the point where, in order to ease the transition, there were horrible programs which actually simulated a desktop (i.e. the word processor would look, on the screen, like a typewriter — with real keys etc.).
Of course, a lot of these changed — but the essences remained, like the ideas of “files” and “folders” and “drawers” etc.
The new desktop paradigms tried to change this. It was like, screw the desktop analogy, it should be more efficient than that etc.. Did any of them succeed? As you well know — none of them did. Why?
…the answer is in the user inertia. Once somebody is used to working in a certain manner, there is no way to convince him that another one is “logical” or “more logical”, even if it actually is. I am dependent to emacs keybindings myself — I was never comfortable (I’m still not comfortable) with using the arrow keys to move the cursor, as stupid as this may seem.
The same goes for OS X users switching to Gnome: after only as little as a few months of working with OS X, finding the application’s menubar just… sucks.
Basically, it would be a completely stupid idea to enable the global menubar by default — 90% of the users are NOT used to it. But accepting the patch and making it possible for users to turn it on or off would be reasonable enough. Nobody who is not used to it would be harmed — and in this case, why the long debate?
Edited 2007-05-18 12:13
The article links to an ubuntu forum thread. Unfortunately, I can’t find debs in that thread for feisty which I’m using now. Does anyone has instructions (without compiling plz) on how to install it on feisty? Thnx!!
i use this feature in kde since it became more or less stable
at first its a little weird , but then you cant live without it
first , it saves screen space
then it makes app windows more simple ( you know , the gnomies that are always zealoting that kde is too complicated and gnome is so simple … )
third , you then know where every menu bar is … you want to access the file menu , you know it is in the top left corner ( for example )
of course , there are other advantages ( like for example if you have a very long menu , because the menu is on the top of the screen , you can the full list ) and not every app needs the menu at all ( i almost dont use it on day to day usage )
Everyone invoking Fitt’s Law to argue for this feature have apparently not been paying attention to the rapidly increasing DPI and size of computer displays. The top menu makes less sense now than it did in 1980 (and before that), and will make vastly less sense as we move ahead.
Also, this is not an issue related to “options in GNOME” and “developer fascism” or anything like that. It makes no sense to trivialise major interaction issues like this by pushing for “choice” over self-consistency and DESIGN. Those who do, compromise their ability to deliver appropriate user experiences to real users.
Software Freedom is NOT JUST FOR GEEKS.
1) Where, praytell, are the terms for DPI and screen size in Fitt’s Law? Also, note that a lot of the HCI research in the 1980s was conducted on displays that would be considered “high resolution” even today. I believe the Xerox workstations eventually had 1024×1024 displays. A lot of the research dribbled down into 512×384 resolution Macs, but it wasn’t invented there.
2) Displays have increased in size only marginally over the last two decades. High-end computer monitors were ~20″ a couple of decades ago, and are only up to 24″-27″ now. Indeed, a modern widescreen 24″ display has approximately the same height as a 20″ monitor did all those years ago. And screen size has nothing to do with Fitt’s Law! It changes D in the equation, but that’s far outstripped by the change in effective W.
3) If you work the numbers, you can see that the size of the display itself is fairly irrelevant. What matters is D2/D1, where D1 is the distance traversed in the in-window menubar case, and D2 is the distance traversed in the top-menubar case. A larger screen only causes D2/D1 to increase if people tend to keep windows the same size, in the middle of the screen. However, people don’t do that. People with larger monitors just resize the window to show more of the document (vertically). Either way, the tops of windows (where the menubar would be) are still pretty close to the top of the screen.
I think this is spot on. I know plenty of people with large monitors, and on my main workstation PC I use a 26″ display with a 22″ secondary display. At work quite a few people working on CAD or database design have dual 24″ displays, while other staff have one or two 19″ or 20″ displays.
Observing the way they fill those screens, I can see that the location of windows (and crucially the menubar at the top of them) hasn’t changed that much since the days when 800×600 was an impressive resolution.
Whatever application is being used, I never see windows resized into the bottom corner of the screen, where the menubar would be a long distance from the top edge. Probably 95% of the time people still have a single maximised application window on screen, with only a titlebar’s width separating the menu location from that of a single menubar (of course that’s plenty to destroy the Fitts’ law advantage).
A larger monitor means that people view full A4 pages in a word processor or a DTP app, maybe two pages side by side on a widescreen. It means they keep a much larger section of spreadsheet on screen. Or view a whole photo without zooming out so much. In my experience it doesn’t mean that they’re ever likely to tile windows vertically on the screen, placing the menubar in the middle. Even if they did, I doubt the increased distance would outweigh the accuracy and speed offered by a control on the screen edge.
I certainly still maximise windows a lot of the time, especially when using MDI apps that make life difficult if used any other way.
If anything I think a single menubar might have more of an advantage on a larger screen. Quickly hitting a small target is even more difficult when the distance is larger, especially when using faster mouse acceleration to compensate for that distance. With the pointer stopping when it hits the menu, you can throw the pointer to the top of the screen as fast as you like and you can’t overshoot it.
Overall I think the argument that larger screen sizes invalidate the benefits of a single menubar is totally spurious, it just doesn’t hold up to real world interface usage.
Sure go ahead and add your Macintosh rip off. As long as I don’t have to add
if global_menu_bar: my_retarded_hack()
all over my source code. If I do, I won’t hesitate to curse the Fitts worshipers.
And how about going menu-less? 99% of applications on my desktop don’t need menus. And the 1% that do only do so because the developers are too lazy to make their GUIs context sensitive and interactive. Menus just give developers an excuse to add new features with reckless abandon.
I have an ibook, and the global menubar is the most retarded thing about OSX. That and poor support for mnemonics and keyboard navigation.
It’s all about choice. I would love this feature.
I wonder why anybody did not mentioned Firefox problem with GTK2 Mac style menubar.
There is a “conflict” here.
Firefox does noy use PURE GTK2 to draw its interface. It uses XUL which uses GTK2 look, this makes Firefox unusable with Mac style GTK2 menubar [While menu disappears from GTK2 apps and shows as the Mac menu, Firefox menu is still there untouched and Mac menu is empty], I wonder how do they resolve this.
.. and yes, add that functionality to Gnome, by default off of course, great feature not only for Mac OS X incomers but also for everybody that wants to try something new.
Because it breaks tons of apps. Any app that was designed without this in mind, such as the GIMP, becomes very difficult to use with this patch.
Firefox and OOo don’t support it.
On a bigger monitor, it’s more of a pain to use. The eye and mouse both have to travel further to get to the menu bar.
Except that it still won’t work right. First, KDE and GNOME use different method of pulling this off. You won’t be able to mix-n-match KDE and GTK apps using this patch seemlessly like you would expect. And it still doesn’t help Firefox, OOo, and any other non-GTK/non-QT app out there.
The patch doesn’t even work flawlessly, nor will it ever given its approach. It is based on reparenting the menubar, which is about as hacky as you can get, and the author notes that a number of a pure GTK apps don’t work correctly with this.
Which is irrelevant, really. You could very well be a small minority (and I do NOT take the number of posts on a forum to be a sign of majority – 50 people posting on forums doesn’t mean crap when there are 1,000s of people silently reading the forums and 100,000s more who don’t use the forums at all). Despite the average user’s ego, your opinion is really quite meaningless, unless you represent a large enough user base – adding features, code, and complexity (especially in terms of how hacky this patch is) for a handful of users is just bad, bad product management, Open Source or not.
Ding.
People, read the actual bug report thread. This is brought up. It’s not just a matter of tossing menus to the top. The whole desktop needs to be redesigned with this in mind, or it just won’t work. It’ll be a neat novelty at best, really useful only to a handful of people who only ever use the GTK apps that actually work with this patch.
Just like on KDE, how only KDE apps can use the top menubar, and every other app is left not only looking different, but completely breaking the desktop design the user wants to use. That renders the feature almost useless.
Sure. Doesn’t mean that the project should be required to maintain a bunch of hackish code to add an obviously contested feature merely for the sake of “some people like it.” Especially not when there are so many things broken with the patch in question.
Different Approach
A different approach is mentione din the bug report for this patch, and I think it’s clear that, if such a feature is to be added, it is the only way to get it done – this patch IS NOT satisfactory, at all.
The way this patch works is by reparenting the GTK menubar. In laymans terms, it kind of cut-n-pastes the menubar from the window to the top of the screen. This has a number of problems:
(a) It only works for GTK+
(b) It only works for _some_ GTK+ apps, because some use slightly different window layouts that makes the patch fail
(c) It can’t alter the content of the menu in ways that make sense in this case, such as making the menu follow the panel’s background settings.
The alternate approach mentione din the bug report is to make the applet for this feature a DBUS service. Then, GTK+ can attempt to create the menu using the DBUS service (as an implementation detail of GTKUIManager), and create the menu locally if this fails. As GTK would then have explicit knowledge over which type of menu is in use, it can also alter the menu contents in appropriate ways for the different styles.
Second, this approach makes it possible for any non-GTK app to perfectly fit in. The apps would still require modification, but it would make it possible to be compatible with the GNOME applet (or possible for a different service to be used, like KDE’s top menubar). KDE could add the DBUS support to their menu system, as could XFCE, ROX, GNUStep, etc. Then – and only then – could all toolkits that support this feature actually work together seemlessly. Firefox and OOo would (eventually) get support and fit it, too, and they wouldn’t need a different implementation for each desktop.
This patch is a hack, and one that doesn’t even work that well by the author’s own words (though he doesn’t phrase it quite that way – he just lists all the pure GTK apps that the patch fails to work on). The alternative approach is more solid, more interoperable, and more likely to actually be accepted.
As a closing remark, I think the poll on this article is silly. I’d vote NO because, while I’m not against the feature, I’m against having it as an option. It makes no sense as an option. To get the OS X experience out of this, you have to actually design the desktop and your apps to fit in with it. Either do it and do it 100%, or don’t do it at all. Adding an option to switch between two different half-working designs is entirely pointless.
“As a closing remark, I think the poll on this article is silly. I’d vote NO because, while I’m not against the feature, I’m against having it as an option. It makes no sense as an option. To get the OS X experience out of this, you have to actually design the desktop and your apps to fit in with it. Either do it and do it 100%, or don’t do it at all. Adding an option to switch between two different half-working designs is entirely pointless.”
Bravo. This is one of the few comments in this discussion that makes any sense. I personally much prefer the global menu bar approach, but it really is pointless trying to incorporate it until we have something that
1) Is universal (works with all the important apps).
2) Is a solid design and solid implementation
Even then, I can never see this being incorporated as an option. It just adds lots of Q&A and lots of hassle. And changing the behaviour without an option would just piss off too many users.
I think we have to realise, that BOTH approaches are probably soon going to be replaced and we’d better look into the next thing rather than argue about which one of these legacy approaches is better.
I’m primarily a Windows user these days, but I have to admit that I much prefer the Mac style single menubar, and miss it when using other operating systems.
It saves screen space, significantly speeds up access to menu items (Fitts’ law), and provides a consistent location for menus, increasing muscle memory. It has a few disadvantages, but in my opinion they’re very minor compared with the clear benefits.
Overall I think it would be a great addition to GNOME, much more valuable than any number of cosmetic tweaks and eye-candy effects.
I tried the option of a single menubar in KDE, but there were too many non-KDE apps that I needed to run. Having a menubar at the top of the screen, and another in many application windows, just made it a cluttered usability disaster.
Maybe if GNOME supported a single menubar, GNOME apps could be made compatible with the option in KDE. With the single menubar option turned on in either DE, all KDE/GNOME apps would use it. That’s the kind of consistency needed to make it a really useful option.
First of all, I’m not saying that this law is wrong – I’m just saying that it’s not as complete as some believe it to be.
For example, it’s not supposed to describe the time you need to figure out where exactly you want to click, as some people already mentioned.
This time is probably shorter if the menubar is closer to the app you’re using unless you have used the top menubar a whole lot.
In addition, it’s just plain wrong (at least for me) if height and width of the target differ significantly. When I’m moving the mouse fast I’m incapable of moving it very precisely in one direction. This means that moving the cursor up fast shifts it to the left or right by about one inch – smaller than menu items like File, Edit, View, just listing the first few from Firefox’ menubar.
Last but not least, I think GUI-design should be optimized for intuitiveness and not speed. Speed is what keyboard shortcuts buy you if you really need it.
All in all it’s probably overrated anyway, because the time you spend entering commands is probably not long, compared to the time you think about what to do first.
Anyway, options that a lot of people demand should be added. Go for it!
I can definitely support both sides of this giant design debate, but I just wanted to point out some thing that I liked about that patch:
you can “profit” from the very, very large top panel defaulted in GNOME. That panel only has the menu-bar on the left and the notification area on the right. Putting this menu in-between makes me feel good. As if I “maximized the top panel investment 😉
That is all.
Well, I wouldn’t care if it were an option. To each their own.
But I don’t see how this would work without breaking focus-follows-mouse. Another window will often get focus as you move the mouse up to the top menu bar and now it will be the window that the menu bar is for and not the one you intended.
Does OSX have focus follows mouse? I remember someone complaining once about not having it. Maybe this is why.
You can turn it on for terminal, I’ve never tried to make it OS-wide though
A lot of the beauty of Linux is the power of choice. You can pick to run Linux how you want – full blown GUI, CLI only, to build from source, to apt-get your way through the entire lifecycle of a machine. Why not have the choice to have a global menu bar?
The mac interface made great sense when the OS could only really run one thing
and people
tended to open one application and sit in it.
Now desktop environments have far greater
ability to run multiple processes and usage patterns have changed, I’m sure we all “flit” back and forth
between some combination of several browser windows, email, spreadsheets, editors e.t.c.
The second major issue I have with it, is I believe that the future of the desktop environment is multiple monitors or more screen real estate. Only a few years ago dual
screens was a rare and expensive option, now in many offices it is the norm, I also remember when 14 inch screens where common,
The power users who used to work with 2 now have as many as 4 or 5 screens
attached making up their desktop –
Where exactly would/should the menu bar go in this case? In the typical wrap around configuration, having things way up in the upper left or right, means its a long way from easy to access.
A wrap around or large “screen” desktop area is a natural progression of the
desktop metaphor, Its far easier to just turn your head to a 2nd or 3rd screen to scan for important email than to do the Alt-tab dance and
get lost in the 30-40 open activities.
Having this kind of functionality could be quite beneficial, especially when talking about using gtk applications on MacOS X, or on small devices like a handheld.
If it is optional and SOMEONE wants it, I see no reason whatsoever for it not to be there. Why restrict it’s not hurting you whatsoever?
It’s odd to see this when just yesterday I was reaching to the top of the screen in Ubuntu for the global menu bar that wasn’t there. It certainly would be nice to see this as an option.
I find related aspects of window management on OSX distracting. Here are two things that I think should be fixed. It’s really easy to click on the background and end up in the “finder’s” menu and not realize it. I see long-time Mac users make this mistake. It would be great to have some indication of what the menu’s owner is on the toolbar (other than the list of menu items). My memory is fuzzy, but I seem to remember an application icon on the finder toolbar in MacOS classic. That might be enough.
The other thing, which isn’t so easy to fix by the very nature of a global nav bar is the extensive amount of distance you have to move the mouse to reach the global menu when your application window isn’t maximized. Using accelerator keys could mitigate this some. How crazy is it to suggest the option of a global navigation bar for the focused window and a menu bar at the top of each window?
On a semi-related note, I’m now enamoured of xmonad, and would like to eschew manual window management altogether. I think a global menu bar would work really well in that situation, for myself anyway.
It would be great to have some indication of what the menu’s owner is on the toolbar (other than the list of menu items).
In OS X, each menubar has (in bold) the name of the application as the first menu entry (it serves to collect generic application-related menu items).
I was mistaken.
I’d like I suggest an application icon anyway. It might nudge the less observant (e.g. myself in this situation) into noticing that they’ve accidentally clicked the desktop or another window.
The main reason I bring this up is that when the application toolbar is at the top of the window exclusively, you end up giving focus to the window when clicking the menu. I think the lack of this functionality is a real shortcoming of global navigation in general, and I’d like to see a much more well-thought-out solution than my idea of adding an indicator icon and an application name to the global menu.
Edited 2007-05-18 03:55
You fully have that choice – go apply the patch. The GNOME developers have even more power of choice, however, since it is they who would end up maintaining this patch, putting up with the disgruntled complaints of users who constantly run into all the apps it doesn’t work for, etc.
“Linux is about choice” is a horrible phrase. It is NOT about choice. It’s about Freedom, as defined by the FSF, and good development practices. The choices you mentioned all relate to getting to decide which software to use – not which features the developers are required to stick in their software to appease you. You have the full power of choice to either apply or not apply the patch for the menubar.
That is as far as your power of choice goes, though. To imply otherwise – to say that developers are required to add features and put up with support nightmares so that you can have an extra toggle box somewhere to switch between two different half-supported menu systems, or else you insult and ridicule them for “taking away” your choice – is the complete antithesis of choice to the developers themselves.
PS I know you weren’t being as rude as I’m implying. Most people with your view are a lot less polite about telling developers how to spend their free time, unfortunately.
I love it, and would like to see that being the status quo for GNOME; being an old Amiga/MacOS X user, I see it as a step in the right direction.
With that being said, we all know how trademark and patent happy Apple is – and this might be a signal to Apple to cause problems; sure, it might be possible to point to prior art, AmigaOS being an example, but even so, it might cause a headache.
With that being said, I don’t want to see shiny interfaces; I like the boring colours that come standard with GNOME – its business like professional and understated, just like GUI should be – provide me with an interface so I can get access to my application, then leave me alone.
I just had a look at those screenshots that hornett posted somewhere up there. I can’t remember now exactly how the OSX menu works, but anyway…
Does, with this patch on, the global GNOME menu get hidden by the application menu? I mean the typical “Applications, Places, System” menus.
Why gnome users can’t have it while KDE has it optionally?
I think users should have choices.
One of the reasons I love Linux is the ability to fine tune every nut and bolt in my system. From lowest to highest level.
No, kick off the Global Application Bar… this is th most thing i hate in OSX,
The way I see it, the menu bar tied to the window approach is much more like stuff happens in the real world, therefore more logical. For example, think of a hand drill. All the functions are represented as buttons or dials (the equivalent of a menubar or menus in my example) on the drill itself, not as a separate little box near the other end of the power cord. As computer programs are just tools (means of doing something) for most of the people using computers, the logic of manipulating the way the tool behaves should be connected with the tool itself, not the power outlet the electric drill draws power from.
About this UI cleanliness thing many people seem to focus a lot on: The CLEANEST UI is the blank screen. Nothing to “distract” you, just the perfect thing for meditation. </irony>
The funniest thing I read in this thread was that the menu bar “DISTRACTS” you from doing your tasks with the application. I personally cannot think of a person that fires up a word processor to write a PhD thesis and then gets “distracted” by the menu bar, and, instead of writing the thesis, starts to examine and investigate the menu bar. But maybe such people exist, dunno. But I do feel that to the majority of us who DO understand that the menu bar is there for a reason and is nothing we should feel intimidated by, the efforts to remove the menu bar altogether (like the new Office) seem like doing something just to show that we do SOMETHING.
And finally, my favorite ranting topic: people are not eternally newbies! Just as in real life – the more you drive a car, the more you feel accustomed to it. There is no reason to replace the steering wheel with a joystick-type-thingy just because it would feel “more logical” to a fresh driver, even more so because if you have just learnt to drive a car, your preferences in what concerns the interior and controls of a motor vehicle are likely to develop as you yourself develop as the driver.
My point is that we should not ditch well-established behaviours in favour of some obscure way of doing things just because some of us have driven cars with joysticks. THAT would be intimidating for the vast majority of people that have grown used to the way they do things only to find out that the next update of my favourite word processor ditches that way of doing things.
And for the “cluttered UI” problem, I personally (not to be understood that I think I’m some kind of majority on my own) think that a well-designed way to customize the workspace (like in Opera where I can remove the intimidating “print” button with the appropriate selection from the menu that jumped up when I right-clicked the bastard) may be a solution of sorts.
Then again, as Gnome tends to focus more and more to approaching OS X’s behaviour, the more I feel that this DE is not for me, so go ahead, have a blast – make the desktop turn itself 90 degrees so that we have to place our heads horizontally to work – it’s more logical in some illogical way. I’m happy with my stagnant non-OSX DE.
Unfortunately, I currently don´t have any mod points left now to give you a +1. Your post describes precisely my feelings towards this “lets make it easier for the stupid crowd” trend that started a couple of years ago and has been crippling some applications for quite some time.
I agree with everything that you say but your remark about the cleanest possible UI is bloody brilliant and I think that you hit the nail on the head with that one: Only when you present a blank screen, the “simplicity people” will finally settle down for something that does not distract the user!
Also, your statement about how the user cannot possibly be a newbie forever was right on the mark. One thing that these changes for usability sake never seem to address is what happens when the user outgrows the basic UI that is presented and needs to use the full extent of the software.
Nobody has ever succeeded convincing me how this usability thing fits into certain types of application, such as 3D modelling, raster and/or vectorial images editing and other specialized apps that actually REQUIRE the user to know a thing or two about what he/she is doing.
Please note that I have nothing against usability efforts per se and do appreciate when they are used properly.
As for the global menu thing, I can´t say that I have any argument against nor towards it other than it definitely breaks the focus following the mouse, which I personally don´t use but know a bunch of fellas that would cry “Bloody murder!” if you take it away from them. KDE has had it for ages, I tried it for a couple of minutes and while it didn´t affected my productivity not even a little bit, it also didn´t make it any better. I´ll join the crowd that feels that the menu bar belongs to its application window.
Edited 2007-05-18 14:57
What we REALLY need is a patch to get rid of the file menu altogether and have its useful links moved to more prominent places. Not only is trying to look and act like Mac OS a really stupid and unoriginal idea, the file menu itself should be obsoleted. It’s the last remnant of the 16-bit world that won’t go away.
it’s all about choice people. The FLOSS movement has always been about choice. If I feel like having persistent menus why can’t I just flip a setting and activate them.
…they’d better fix the annoying ancient bug with constantly resizing taskbar buttons. It is easy, and patches were submitted for that. Yes this is kinda offtopic, but still fixing the existing behavior should be a priority.
…but I have to say that this is so Gnome-ish. If I could imagine a place where an optional new feature would cause such a large discussion and such votes, well it’s Gnome. You know what ? Stick to the Gnome way: drop the whole menubar concept altogether so the many choices won’t confuse the users… [yes, sarcastic, to an extent]