Menus Are Evil

Firstly, because pull-down menus are application-oriented. Pull-down menus are strongly associated with the frame, the window, of the "application". It doesn't help that beyond the simple visual association with applications, there is always a semantic association with applications; there is always a pull-down menu to access application-oriented "options" (eg, allowing multiple instances of the application) which are completely meaningless to actual business objects.

Secondly, pull-down menus are semantically inconsistent. As already stated, there is always an application-oriented pull-down menu. But there are also always object-oriented menus (traditionally named "file"), selection-oriented menus ("edit") and content-oriented menus ("search", "view", "modify"). There is no semantic consistency between them, menus associated with radically different things are simply lumped together arbitrarily in an application-oriented location; the top of the window frame.

Thirdly, pull-down menus are visually dissociated from the things they operate on! Pull-down menus are visually at the top of the window frame, but content selections are typically in the middle of the window frame, the object contents aren't even all visible on screen, and the object in its native environment (where it resides among other objects) isn't visible at all. The only pull-down menu that's visibly associated with the thing it operates on is the application-oriented menu. And as already pointed out, applications are evil.

Note that these points don't apply to ContextMenus.

Context Menus

Context menus are linear, despite the well-documented fact that human beings perceive and remember angles better than linear distances. But there are more basic problems.

Menu commands aren't transparent actions. The command triggered by a menu item is pure black box magic. What it actually does and how it does it are completely inaccessible to the user. In contrast, a transparent action is a "command" where the Smalltalk source code is visible if the user hovers their hand over the menu item. (After ten minutes of learning, there really is no excuse to use the mouse to pick items from WheelMenus).

Menu commands aren't associated with MouseGestures, and such associations aren't visible even when they exist (eg, OperaBrowser).

Context menus aren't pinnable / reflexive. You can't rebind the keys associated with particular menu items.

Menu commands are only sometimes associated with keybindings, but never in a consistent way, never in an easy to learn way, and absolutely never in a useful way. Why is this? Because the associations are ostensibly "semantic". The programmer picks some letter on the keyboard which is supposed to act as a mnemonic device for the name of the operation. Setting aside the fact that this is utterly retarded and obviously doesn't work, there remain obvious difficulties:

you can't always find a useful mnemonic device
there can easily be a lot more than 2*26 commands operating on an object
you'll get collisions long before you use 26 keys
3/4ths of the keyboard are inaccessible from the left hand when the right hand is on the mouse
related menu items should be bound to proximal keys

-- RichardKulisz

There are some interesting ideas here, but why on earth would you want to show a typical user the source code associated with a menu item? What is it about a well-chosen menu item name that is so terribly undescriptive, compared to something that will almost certainly be gibberish to most users? Or are you only talking about UIs for programmer tools? -- DanMuller

The menus should be responsive in the sense that a menu item that's been chosen only a few times will be highlighted, one that's been chosen often will become more and more transparent and its associated mouse gesture more and more highlighted until a certain point when its associated mouse gesture also becomes more and more transparent. Eventually the menu item simply displays source code. So beginning users aren't exposed to source code.

Why is it deemed a GoodThing for users to become programmers?

Isn't there another wiki page on this topic? UserInterfacesDesignPrinciples? DontCallPeopleUsers? ExpertUsersAreDevelopers? ProgrammersAreUsersToo? UsersAreSmarterThanProgrammers?

Remember: just because something should be allowed, it doesn't follow that it should be required. Just because something is possible doesn't mean it's necessary. Just because something's permitted doesn't mean it's compulsory (except in physics).

We agree that menus are evil (add your signature): [RichardKulisz obviously], JonGrover

We do not agree that menus are evil (add your signature): HelmutLeitner

I was about to add my vote to "menus are evil" (for some values of "menu"), but after a moment's thought: it's not merely a matter of subjective preference, and therefore voting is irrelevant. If you want to break out the part that is purely a matter of whim, you've got your work cut out for you. -- DougMerritt

This is not meant as a voting. It may be irrelevant but it is still interesting. I think that the majority doesn't find this page interesting enough to add to the discussion, but still has an opinion about it. For me it doesn't matter whether I'm in the majority or the minority. It seems difficult for everybody at WardsWiki to sit in a boat with anybody, even if it's only for a minute. It would be nice to see Richard not sit alone. -- HelmutLeitner

Yes, MenusAreEvil, menus are even SimplyWeird?! I mean of course the original idea must have been simply SelfDocumenting? a set of commands, but obviously it all leads to MenuDigging?! A step in the right direction would be making SearchableMenus? (ie with '/'), some kindOf Menus/CommandLine hybrid. Of course it's just that WimpIsBroken, we need searchable option-tabs and thus forth.

I find it interesting that the comment directly above which suggests a Menu/CommandLine hybrid, and one higher up that suggests exposing source code to end users, are ideas that were deployed with massive success in 1982! The Lotus 1-2-3 spreadsheet program employed a Menu/CommandLine hybrid, and the macro language source code used in a given spreadsheet was accessible to (and often modified by) end users.

The Lotus 1-2-3 menus also allowed regular accountants to learn to program their own stuff using their existing knowledge. I've never seen anything like it before or since. It was an amazing phenomenon. (See ComputerProgrammingForEverybody)

Fourthly, menus hide the navigation the user used. This means that the menus disappear after use and anyone trying to memorize a long and complex series of menu navigations and pull downs has nothing to go on. Menus hide the memory of their use. and so they make terrible teachers, because a person trying to learn while watching a teacher navigate has no notes.

Fifthly, menus hide the user's objective. In a complex menu construction, the user will start by seeing the main menu but the path to get to where they want to go is hidden. At each level of the multilevel menu, the user will have to guess which menu item to select within the context of that particular level in order to make the right decision. Often the context they need is only clear in the last menu of the menu level stack and intermediate level contexts don't have much to do with their objective. What often happens is that users simply give up and start pulling down every menu and sub menu and sub-sub menu combination looking at every 'leaf' selection in order to find the selection they want to find.

I was just wondering could one implement a CommandLine/Menu hybrid thing. I think it should aim to solve these:

Not requiring memorization of arbitrary names (menus do, command lines don't).
Direct or quick access to options, meaning no deep nesting (command lines do, menus don't, KeyboardShortcut's are similar to memorizing commands).
Be as clear as possible on the context it's working (a menu is usually better at this than a command line, both have issues).
Allow for complex commands. Maybe taking parameters, maybe composable, don't really know, but more flexible that just "do-this". (Obviously command line does, menu doesn't).
Allow for exploration of features. Menus allow for this better than command lines.

Some possible solutions include:

Memorization of names: Searching+Autocompletion on the whole menu tree. But should provide a clear way to disambiguate menu items with the same name in different hierarchies.
Quick access: same as above.
Clear context: I think this is a more general design issue.
ToolTips? are nice. They could be better, or something else. Maybe link from tooltips to documentation. Or overhauled tooltips.
Exploration: A smart autocompletion should provide for an alternative to digging under layers of menus.

I was mainly thinking about ContextMenus, but should probably apply to PullDownMenu?s.

Tool-oriented metaphors seem to have many of these properties. Instead of a plain-old mouse, we equip a tool that can be applied to different objects, or composed/modified with other tools. For rapid access, tools can be associated (modally or otherwise) with keypresses. A set of tools can be explored and learned, starting with beginner tools and moving towards more specialized ones with the user. Created tools can be shared with other users.

CategoryUserInterface CategoryInteractionDesign