This is the ninth article in a series on common usability and graphical user interface related terms [part I | part II | part III | part IV | part V | part VI | part VII | part VIII]. On the internet, and especially in forum discussions like we all have here on OSNews, it is almost certain that in any given discussion, someone will most likely bring up usability and GUI related terms – things like spatial memory, widgets, consistency, Fitts’ Law, and more. The aim of this series is to explain these terms, learn something about their origins, and finally rate their importance in the field of usability and (graphical) user interface design. In part IX, we are going to talk about the menu.
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…