When the trend to add more buttons to devices was popping up almost 20 years ago, I suggested the 55 button mouse. Partly it was a joke at the expense of the common trend, but with laser mouse technology we could turn the keyboard into a mouse. This would provide mouse pointer capability without removing a hand from the keyboard. Downsides = needs a little real estate on the desk, some users couldn’t adjust, no good for laptops.

Better still, divide the keyboard in two between 5TGB and 6YHN and make the right piece into a mouse. Slightly dish the key surface and all of the keys move a little closer to the hand for ease of typing. Yes, a little wacky, but maybe useful.

In theory it really wouldn’t matter much, so long as a new application followed the previous applications rules in the menu arena. However, because Apple forced the main menu bar on every app, and Microsoft made it application specific, an odd thing happened. Mac developers tended to stick the HIG and ensure that menus and their keyboard command equivalents remained constant. Apple-S saves, Apple-P prints, Apple-W closes Windows, and so on. Microsoft, on the other hand, lets each app decide which menu arrangement and keyboard shortcuts it uses.

So if a Windows developer wants to assign Ctrl-P to Preferences, they are more than welcome to. And many (not all, but a good number) would do something as dumb as that. Case in point – Microsoft themselves break “Ctrl-W” usage for closing a Window in Outlook.

So which is better. Well, if I can rest assured that the menus/keyboard commands of open, save, print, cut, copy, paste, preferences, close window, select all, find, find again, and so on are going to be consistent from app to app, I know that out of the box I can learn 60% of an application just by knowing the base keyboard commands. On Windows, you can’t say that.

As to the people that say a changing menu bar throws people when they change from app to app when they first use it… Well, that is true, but only of users who come with a Windows experience. People who have never used a computer before (or haven’t been numbed by the use of Windows day in and out) appreciate the consistentcy in the menubar alway being in the same exact spot for each app, and always have the same commands for the applications core functions.

“”"
The most efficient menu position is the one where you *do not need to move the mouse at all.*

Secondly, this removes one of the Mac’s nasty little niggles, which OS X preserves: that of the menu bar that randomly changes on the user depending on which window they clicked on last. This always throws beginners and can fox experts too; we all make mistakes.
“”"

That’s what i always thought.

Let me ask a question:
Hasn’t Apple changed some details in the interface of Mac OS X? Or has it remained totally stable (i don’t think so)?

I have several reservations, though.

[1] How come you talk of the Lisa interface but illustrate it – and mainly seem to discuss – the Mac interface? They’re not the same. They’re not even that similar. The Mac is application-based and driven.

[2] I disagree that the Mac is MDI of any kind. It is SDI, pretty much, with a unified menu bar.

[3] Fitt’s law is very widely taken as some kind of axiom or biblical pronouncement; you are not the first. It’s not; it merely reflects a certain type of bias. For instance, there is a simple, obvious menu placement method which is more efficient than Fitt’s edge-of-the-screen-as-biggest-target rule. That is, the context menu. Look at old Unix systems – back in the days of OpenLook and so on. More saliently, before commenting on such things, I feel that you really need to play with one of the first mass-market WIMP GUIs that was truly multitasking: Acorn’s RISC OS. It’s still being developed and sold. It refines the Unix-style 3-button mouse paradigm into near perfection; there are no fixed menu bars anywhere, and no need for clumsy kludges like mice with scroll wheels, “OK” and “Apply” buttons and so on. It has problems, sure, but it is, in its way, considerably more elegant than either Classic MacOS or Mac OS X. Anyone criticizing WIMPs *needs* to get to know RISC OS. (I would count Atari GEM and Amiga Intuition, but I don’t think either of them brought anything genuinely new to the table. The Amiga’s top-of-the-screen global menu /that you must summon with the right mouse button/ is, to my mind, a particular ergonomic horror.)

The most efficient menu position is the one where you *do not need to move the mouse at all.*

Secondly, this removes one of the Mac’s nasty little niggles, which OS X preserves: that of the menu bar that randomly changes on the user depending on which window they clicked on last. This always throws beginners and can fox experts too; we all make mistakes.

Thirdly, by having no menu displayed at all unless you ask for it, no screen space is wasted. You only get a menu when you need a menu, and because you asked for it, by clicking the menu button over a window, you know what menu you’re going to get.

It’s far simpler and more elegant than the Apple way. Yes, a 3 button mouse takes more learning, but not much. The ideal GUI, I think, is perhaps one which has a simple one-button model for beginners which gradually shifts to a more powerful multi-button one as the user grows more proficient, banishing fixed menu bars on the way. The only tricky bit – and it’s a doozy – is working out how to manage the transition.

Why? I use two monitors. When the active window is on one, I have to mouse way over to the other. That’s just dumb.

I’m not saying one way is better than the other. That’s a generalization. I’m saying choice is better than no choice. We’ll that’s a generalization, too, but I think one that’s easier to defend.

“I think the application menu is an application thing and should be inside the
application window. This mac-style approach is just wrong and illogical imho.
Moreover it looks unsuitable if there aren’t maximized windows, if the
application doesn’t have a menu bar or if it has a complex structure with
multiple bars.”

I agree on the disadvantages of the current MDI approach, but the “LisaBar” one isn’t much better imho: as I’ve already said, the application bar should be inside the application window because with the “LisaBar” I’ve “always on top” useless and wasted space when there aren’t maximized windows or when the application doesn’t have a menu bar. This is really wasted space, worse than the filled menu bar (*if any!*) of a SDI application. Applications bars have sense inside the application window and context. Moreover, if I have an application with a complex structure and multiple bars, the “LisaBar” creates a fragmented environment with things inside the application window and things outside the application window.

I think a good approach would be to have a “WM-wrapper”, where I can have a sigle form with its bars (if any) or more windows (MDI-style I could say) but managed by the WM.

My two cents (and excuse me for my bad English).