History
Let’s start with a history lesson. Like we did in the article on the icon, we need to take a look at Ivan Sutherland’s Sketchpad, the world’s first computer program that, while lacking a graphical user interface, was the first program to actually create a need for a graphical user interface in the first place. Up until that time, 1963, computers were massive mainframes run in batch mode, with punch cards – these were operated by highly trained scientists and computer experts, and had virtually no form of abstraction. Abstraction wasn’t needed, since the people operating these computers were fully educated in how these machines worked.
Sketchpad changed this. Sketchpad was a drawing program (some even call it the father of all CAD programs) that didn’t require extensive knowledge on how to write code or how to feed CLI commands into the computer. It used a light pen and a keyboard with 40 commands like “DRAW”, “MOVE”, and “DELETE”. While Sketchpad had no GUI, it did create, for the first time, the need for a GUI. It implies a graphical user interface, but it doesn’t actually have it yet.
The need was there, now all we needed was something to fill this newly created void. The first steps were taken by Doug Engelbart and his On-line System (NLS), which incorporated windows and the very first mouse. A number of people who had worked on the NLS later started working at Xerox’ famous Palo Alto Research Center, where they would develop the first, actual, really-really graphical user interface that we still more or less use today (we do have transparency and wobbliness now, though): the Xerox Alto, an experimental computer that never made its way to the market. The commercial successor to the Alto, the Star, would eventually set many of the conventions we take for granted today: the desktop metaphor, and that odd acronym ‘WIMP’ – window, icon, menu, pointing device.
The Star introduced the first menus, but the original Macintosh expanded the concept greatly, delivering the prototypical menu: the pull-down menu (the one seen in menu bars). The menu would become one of the mainstays of the graphical user interface, surviving all the way up until today as one of the major elements of the GUI. The menu did change over the years, though, and different types of menus would arise as well. We’ll take a look at various types of menus, some characteristics, and we’ll end with some of the recent developments concerning the menu.
Types
An important, but rather confusing distinction is that between a pop-up and a pull-down menu, as the definitions for the two differ per graphical environment. In the Mac OS and Mac OS X, a pop-up menu is actually a drop-down list, while in most other graphical environments, pop-up is synonymous with the context sensitive menu. Both meanings are technically wrong, since there is no law that states that a context menu must always be a pop-up menu. Interestingly enough though, the context menu was invented at PARC, and first implemented on the Xerox Alto. Showing that even the mighty people at PARC can be wrong, they called their context menu – by lack of a better term at the time, probably – pop-up menu.
Simply put, a pop-up menu appears out of nowhere, whereas a pull-down menu unfolds out of a button on a menu bar or toolbar. This is merely a distinction based on method of appearance, and doesn’t really say anything about what the menu should or shouldn’t do. A context menu can easily be a pull-down menu – it’s just that it’s quite rare.
The second distinction is that between a static menu and the context sensitive menu. Invented at PARC for the Alto, context menus appeared in all graphical operating environments soon afterwards (with key pioneers being NEXTSTEP and RISC OS). The key difference between a context menu and a static menu is that the former changes its contents depending on the state of the system, while the latter remains the same regardless of the state of the system (save for greying out inactive items). In almost all modern environments, the context sensitive menu is invoked by right-clicking, and usually contains easy access to a set of often-used commands. The unofficial rule is that a context menu may never be the only way to access a certain feature, since that would seriously hinder discoverability. A context menu is a group of commands also accessible via other means such as the menu or toolbars; it’s not a replacement for either.
A far less common type of menu is the pie menu, a type of (context sensitive) pop-up menu which presents its options in a radial layout around the cursor, which is supposed to be better since it takes Fitts’ Law into account. Despite its advocated advantages over linear menus, pie menus remain a curiosity, mostly reserved for some game interfaces.
Pity that you didn’t mention the menu behaviour.
The classic Windows-like behaviour is for menu to expand when a menu item is hovered by a cursor. It lets you access submenus faster but it often makes you lose your menu path when you get into deep submenu and accidentally hover the cursor above some higher level menu. This is annoying as it requires you to select all your menu/submenu/submenu2 path again.
Another type of menu behaviour is the requirement to click on a menu item to access a submenu (available in new KDE Kickoff menu and in Windows Vista). It won’t make you lose your menu selection path, but it will require you to click on every submenu you want to dive in.
I guess you could explain this topic in more detail.
It seems like a failure of design to have more than /Menu/Submenu as the depth of your menu hierarchy. There has gotta be a way to flatten it out because no user wants to search that deep for an item (especially if it’s something that’s used regularly).
thats the reason why office 2007 has the ribbon instead of a menubar
especially annoying if the submenu is so large that it covers the main one, and your still not at the right target…
I love this series. It makes me think more about usage patterns, which helps me with my video/mograph/graphic design work. Good job, Thom!
I agree. None of them are completely comprehensive, but there’s often some good insight in them.
Hey Thom, I have a request. Why not write a Human Interface Guideline for a Thom Concept OS? You could use ideas from the GROW project, and we could all hone in on an ideal interface.
Wouldn’t it be prudent to make up a dedicated landing page that holds the links to these stories so you could post that, rather than 8 links you have now?
I dread the posting for part XXX.
You mean like this?
http://www.osnews.com/tag/Common+Usability+Terms
Just retroactively tagged all the articles, looks good, huh?
Yes, excellent. Thank you.
>> Sometimes, menu items are disabled (indicated by
>> greying them out) because the command cannot
>>currently be executed. This common practice
>>(endorsed by many HIGs, including those of GNOME, OS
>> X, and Aero) is the subject of some controversy, as
>> some people claim that disabling menu items without
>> offering an explanation leads to user frustration.
>> “Don’t do this,” Joel Spolsky urges, “Users see the
>> disabled menu item that they want to click on, and
>> are left entirely without a clue of what they are
>> supposed to do to get the menu item to work.”
>> Spolsky suggests leaving the menu item enabled,
>> showing a dialog of some sort when clicked
>> explaining to the user what he needs to do in order
>> to get the item to work.
This is just plainly wrong from my experience. There are three ways of dealing with menu commands that are not accessible in the current context:
1) Hide them
2) Disable them (gray them out)
3) Leave them “on” and display a message
1) If you hide menu items that are currently not available, users are confused that some command that was there previously is now gone and they get frustrated searching all the menus. That is why the Office XP style menu that hides infrequent used menu items confused the hell out of people, because the menus look different each time they are opened and you can not as easily memorise where a command lives. The cost of hiding any menu items are usually greater then disabling it.
2) Graying an item out shows that the command that you are seeking is unavailable in the current context. While not explaining how to make them available this is a good, fast and non-intrusive way of showing the user: Stop, you can’t do that at the moment!
3) Leaving the item “on” and display a message is really evil in my opinion (except for some rare corner cases). Messages are almost always displayed using a modal dialog box which takes a lot of “effort” to read and close and then to return to the work you are doing. A reaaaally bad example of this are the selection tools of Photoshop (if you use it regularly you know what I am talking of and how much it gets in your way!!!).
Of course every rule has an exception and all solutions have a case where they can be used adequatly 😉
——————————–
>> While the menu will most likely not go away any
>> time soon, there have been a number of developments
>> – mostly on the Windows platform – that shift the
>> focus away from traditional, static menus. First
>> introduced in Internet Explorer 7, and later
>> adopted by many Windows Vista applications, are
>> hidden menu bars. Many Vista applications lack a
>> menu bar, instead preferring ‘toolbar menus’, or
>> worse yet, ‘tab menus’ (see Windows Media Player).
>> This isn’t actually implemented at random, but
>> instead follows a set of guidelines put forth in
>> the Aero guidelines.
I can only speak for myself here but I prefer the Vista and Office 2007 way of hiding and removing the menus altogether. Take the Windows Explorer in Vista as an example: The menu was removed there because with the new breadcrumb navigation you would get sort of two menu bars one living under the other with could get in the way when navigating through the directories using the breadcrumb menus (which I like a lot by the way because it makes navigating with the mouse very fast). The toolbar-menus in explorer (and Windows Media Player, that thing on the top is a toolbar not a tabbar!*) as you call them are actually so called button-menus because if you click on the name of the button (and not the space and arrow around beneath/next to it) it performs the default action of that button and the menu that belongs to that button provides “similar” actions as the default one. Vista and Office achieve by this that you just need one or two mouseclicks at most to reach a command via a toolbar/ribbon. Hiding the menubar saves precious screen space (you can have never have enough of it!), and toolbars need usually fewer clicks.
* Media Player toolbar not tabbar:
Look with Spy++ in the Windows Media Player Window.
The Top window beneath the title bar is of the runtime class ReBarWindow32 which is a host for a reziable toolbarwindow on Windows, in the case of WMP11 it hosts a single old boring ToolbarWindow32. (WMP hosts a whole lot of other ToolbarWindow32s all over the place.) Clicking or selecting one of the toolbar buttons sometimes changes the view state of the media player (DocumentView model) which could arguably be interpreted as some kind of tab view… I think not though…