Linked by Thom Holwerda on Thu 17th May 2007 18:54 UTC
Gnome 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.
Permalink for comment 241338
To read all comments associated with this story, please click here.
RE[3]: Why?
by alexandru_lz on Thu 17th May 2007 23:05 UTC in reply to "RE[2]: Why?"
alexandru_lz
Member since:
2007-02-11

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 512x384 screen, having 12 16x16 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

Reply Parent Score: 5