The menu bank: A replacement for the traditional menubar and toolbar.

This is the finale to the menu and toolbar series. In previous posts, I’ve argued that the menubar and toolbar, once the hallmark of a usable application, have developed into a barrier to usability. The standard menu names are vague to users, the toolbars are cryptic, and the redundancy hurts more than it helps. While Microsoft’s new Ribbon has addressed some of the problems, it has perpetuated others, and in any case, the modey tabs make the Ribbon ultimately suited only for a minority of very complex apps with over 1000 commands. For apps of typical complexity, I believe that performance close to the Ribbon can be achieved with an easier learning curve through proper menubar and toolbar design to ameliorate their problems. These ameliorations include:

• Avoiding meaningless menu names like “Tools.”
• Organizing menus by related commands rather than implementation.
• Better documentation with more sensible terminology
• A toolbar diet
• Use of detail panes

The Menu Bank

However such amelioration still leaves many usability problems with the menubar and toolbar. Which brings us to the “menu bank,” my shot at solving all the problems I’ve described of the menubar and toolbar. Here’s how it would look for a basic word processor (click for full view).

The menu bank is the menu along the left side of the window in the picture above (at the top and bottom of the window are a detail pane and view attributes just so you can see how it can all fit together).

What’s Up with the Vertical Orientation?

I’ll explain that later.

Characteristics and Behavior

What makes a menu bank a menu bank is that for each menu the most commonly used menu items are “exposed,” that is, visible and available for selection. For example, on the File menu, New, Open, and Save are exposed. Uncommonly used menu items, like Save As and Exit, are unexposed, lying on a cascade menu accessed by selecting the right-pointing disclosure arrow at the bottom of the menu. Some menus have no commonly used menu items, such as Customize. For these, clicking the menu displays all the menu’s items on a cascade like a conventional pulldown menu, only “pulls sideways.” Some menus may have all menu items exposed (not the case in the above illustration). This is indicated by the lack of a disclosure arrow at the bottom of the menu. Commonly used commands are determined by the application designer based on user research -the menu bank is not an adaptable menu that automatically changes with use.

Side-centered Cascades

One problem with separating commonly used commands from uncommonly used commands is showing related commands together when the uncommonly used commands are accessed. For example one might expect Redo to be near Undo on the menu. However, if unexposed menu items appear in an ordinary dropdown or cascade below the exposed menu items, Redo would appear separated from Undo by at least four menu items. Preferably, you want to keep related commands proximal without either disturbing the layout of the commonly used commands or repeating the commonly used commands. The former disrupts the ability to reacquire commonly used commands and the latter adds clutter (on some menus, the commonly used commands will out number the uncommonly used commands). The solution I favor is to present the unexposed menu items to the side the parent menu, with unexposed menu items appearing both above and below the level of the disclosure arrow, as determined by the designer (click for full view).

This gives the designer the ability to put unexposed menu items beside related exposed menu items. It also has the following additional advantages:

• It avoids obscuring other menus or menu items which the user may still be looking at when searching the menus (as would happen with a dropdown menu, or with replacing the parent menu like done with Vista’s Start Menu).
• It makes it easier to fit the cascade menu consistently within the window. If the cascade menu appeared completely below the disclosure arrow then the cascade menus at the bottom of the bank could extend beneath the bottom edge of the window, leading to problems if the window edge is near the bottom of the screen, such as when it is maximized.
• It keeps the average slewing distance to all menu items in the cascade shorter for (I think) faster selection with a mouse (see Byrne MD, Anderson JR, Douglass S, & Matess M, 1999. Eye tracking the visual search of click-down menus, CHI 99, p402–409). Ideally, the number of menu items above the disclosure arrow should equal the number of items below the disclosure arrow, which would cut the average slew distance almost in half. This makes the cascade menu essentially a one-dimensional pie menu.

Abbreviated Display

The menu bank has the potential consume a lot of  real estate. While a toolbar control consumes as little as 700 pixels, each exposed menu item takes about 2000 pixels. All things considered, I think that’s pixels well spent. However such real estate could be used for better purposes under certain circumstances. For such circumstances, the menu bank includes an Abbreviated display, set by the user by deselecting the Full toggle button at the top of the bank (click for full view).

This decreases the width of the menu to about 30 pixels, and changes the menu captions to two to five letter abbreviations. Supplementary elements of the caption, such as the accelerator hints, are removed. Menu labels are also removed decreasing the menu bank height as well as width, which may be important in some circumstances. In this configuration, the menu bank consumes less real estate than a menu bar for windows of typical aspect ratios. Even when adding the view attributes at the top of the window (which not all apps will have), the total real estate used is less than a menu bar with a single toolbar. It’s so compact, I wonder if dialog boxes for non-Mac apps should include an Abbreviated Undo-Cut-Copy-Paste menu bank so users don’t have to rely on memorized accelerators. The full caption of the menu item in Abbreviated display appears on mouseover, much like a tooltip, to provide a quick cue of the menu item’s function before the user actually makes a selection.

The setting of the Full toggle button is user-preserved, retaining its state between executions of the app for a given user (login credentials). Thus, once a user is sufficiently familiar with an app to switch the menu bank to abbreviated display, it may never need to be done again. For simple apps with little other than the standard File and Edit commands (with standard abbreviations), I expect experienced users will switch the menu bank to Abbreviated within the first few executions and leave them that way.

Checkboxes As checkboxes, Option Buttons as Option Buttons

Like a toolbar, menu items in a menu bank may be any control as desired by the designer: conventional command menu items, attribute menu items, such as the checkbox Spell Check menu item, even text boxes, such as the Help search/index box (see first illustration). Unlike a toolbar, alternative controls have different appearances consistent with the usual normal workspace controls, at least when in Full display. For example, checkboxes are square while option buttons are round. In Abbreviated display, the distinct features for each control are shown on mouseover and focus. For example, the Help search text box expands out to full size for text entry when the user clicks on it.

Consistency with Menubars and Toolbars

Look closely at the menu bank and you can see how remarkably conventional it is. Commands are still organized into hierarchical menus, and those menus can be the usual File, Edit, View, and Help. If user testing suggests that there are better ways to divide your menu commands, there’s no reason you can’t do that on a menu bank, but Microsoft’s experience with the Ribbon suggests that these basic categories are actually pretty good. If you insist, you can even have the god-awful Tools menu, if that’s really essential for your users. Unlike the Ribbon, however, you can transfer the exact same menu names, menu captions, accelerators, and mnemonics from a conventional menu bar to the menu bank. Users used to Alt-F,X to exit will not have to learn something new. Making the transition from a menubar to a menu bank should be pretty easy for users. They just have to look sideways.

To maintain familiarity with legacy apps, you could include icons in the menu item captions when under Full display, but I would recommend against that except for commands for visual representations (e.g., color setting). With no toolbar for the user to transition to with growing expertise, the need for icons on menu items is eliminated. Icons add width and clutter, distract the user from the content of the app (e.g., the document being written), and, contrary to intuition, do not necessarily help the user find a menu item better than a text label alone (see Wiedenbeck S 1999. The use of icons and labels in an end user application program: an empirical study of learning and retention, Behaviour & Information Technology, 18(2), p68-82). It’s not worth it. Besides, I’d personally like to see icons return to be used for indicating objects not actions in order to provide a consistent cue to users on what requires double-clicking to activate.

Another thing to notice is that the good design practices and techniques that I’ve recommended before for the traditional menubar and toolbar still apply to the menu bank. You can choose clear specific menu names, organize menu items by related function rather than implementation, and use detail panes where appropriate (as shown in this post’s illustrations). You can use improved terminology in your documentation (I don’t recommend you call it a “menu bank” to your users; rather consider “sidebar menus” or even just “the menus”).

Well, the Vertical Orientation isn’t Consistent with Menubars and Toolbars

I’m getting to that.

Exposed Menu Item Diet?

When using the menu bank, the need to limit exposed menu items is not as important as the need to limit controls on a toolbar. Where a toolbar can have only about eight controls before it starts getting cluttered and confusing for novices, the menu bank can have 20 or 30 exposed menu items without much problem, thanks to the superior grouping and labeling. In fact, I recommend your app have about 20 exposed menu items, even if that means all your menu items end up being exposed. Yes, that may mean relatively uncommonly used commands are exposed, but even uncommonly used commands are easier to find and get used faster when they’re exposed. I just don’t anticipate much benefit to having less than twenty exposed menu items for most situations. The only issue I can think of is that it may also be a good idea for certain standard but uncommonly used menu items to always be unexposed for consistency across apps.

Nonetheless, for complex apps with many commands, you may need to limit the number of exposed menu items on the menu bank, and for this you can apply the same “toolbar diet” rules I’ve given for the toolbar, except for one thing: unlike having a toolbar control when there is an accelerator, I don’t see a problem with an exposed menu item that also has an accelerator. I still think users are generally better off using accelerators than toolbar controls (or exposed menu items), but, in contrast to a toolbar control, an exposed menu item encourages the transition to accelerators: With Full display, the user can see the correct accelerator for an exposed menu item without the fingers leaving the keyboard, making the execution of accelerators easy while still learning them. With repeated executions, they should eventually be memorized in time for the user to switch the menu bank to Abbreviated display. In contrast to my recommendations with a toolbar and menubar, if a command is common enough to have an exposed menu item on the menu bank, then it probably should have an accelerator too.

There are exceptions, however. A command that is only common for expert users may be unexposed but have an accelerator. I think Paste Text and Paste Format fall in that category -a novice may have trouble even understanding what they mean, but they’re very useful for an expert (well, me anyway). Likewise, a command important for novices, but not necessarily used often by experts, may be selected with an exposed menu item without a accelerator. Spell Check may fall in that category, where it’s important for users to see it and know when it’s turned on or off, but no one actually uses it too often -generally one turns it on and leaves it on. Also, common but dangerous commands may have exposed menu items, but should not have accelerators in order to prevent accidental activation when the user is typing hurriedly. A command that is dangerous and rarely used should be unexposed and have no accelerator to provide additional insulation.

The Menu Bank Takes the Ring

So the menu bank can do whatever the menubar and toolbar can do. Big improvement. What really matters is how it tackles the problems of the menubar and toolbar that can’t be ameliorated away. Listed below are the problems more or less inherent to a menubar and toolbar combination, and how the menu bank fairs against each.

Vague Menu Names

The menu bank is not going make better menu names appear. You’ve still got “File” and “Edit,” and, indeed, I recommend you keep these labels for consistency with other apps, unless you’ve got usability test data showing you got something better. The menu bank, however, has something the menubar doesn’t have: exposed menu items. It turns out one of the best ways to provide information scent for a menu is with example items in that menu (see for example, Snowberry K, Parkinson S, & Sisson N, 1985. Effects of Help fields on navigating through hierarchical menu structures. International Journal of Man-Machine Studies, 22, p479-491). The exposed menu items not only provide easy access to common commands but also indicate at a glance what kind of menu they’re on -what “File” and “Edit” are supposed to mean. Exposed menu items like New, Open and Save indicate that within the disclosure arrow lie commands like New, Open, and Save. With the menu bank, it doesn’t matter much that File and Edit are vague menu names. I don’t even think the menu names are always necessary, which is why they disappear with Abbreviated display. The main reason I have them at all is for documentation and tech support (e.g., to be able to tell users to “look on the File menu”).

Menu Overwhelmed by Toolbars

While toolbars tend to obscure the menubar, making it more difficult for novices to find it, exposed menu items make the menu standout even more. The more exposed menu items, the larger the menu appears and the more likely the user will look at it for the sought-after menu item, whether exposed or not. For this to work, the graphic boundaries of each menu need to be clear (as I’ve attempted in the above illustrations with a colored outline). If each menu does not hold together visually, then the menu bank becomes a jumble of individual exposed menu items, little better than a toolbar in that regard. This one reason I recommend against icons on the menu bank even icons redundant with the text captions: their high graphic variability (e.g., multiple colors) will tend to hide the menu boundaries.

Reliance on Tiny Pictures to Convey Actions.

The other reason the menu bank doesn’t have icons is because they’re just not very good a conveying actions, a major problem with the toolbar. For Abbreviated display, the menu bank uses text abbreviations rather than icons because I believe the abbreviations are easier to learn. Using vowel deletion to create abbreviations, as I’ve done in the above illustrations, preserves the most distinguishing information in the menu caption, making for abbreviations that are relatively easy to decipher. It is also most likely to give each menu caption a unique word shape that makes it easiest to discriminate from its neighbors when scanning for a command.

Behavior Unpredictable from Appearance

Toolbar controls tend to all look the same -like a small command button, but may in fact act like check boxes, option buttons, dropdown lists, and more, in addition to command buttons. Menu bank items in Full display look like ordinary GUI controls, taking out the guesswork of what control will do what. For Abbreviated display, it is expected that users will use it only after they’ve learned the menu items well enough to know how each behaves, so such visual cues are mostly suppress in the interest of conserving real estate. However, if a user does forget how a particular menu item behaves in an Abbreviated display, a quick mouseover clarifies it by showing the menu item popped out to full size (something difficult to accomplish with a toolbar in conventional horizontal attitude).

Difficult to Transition from Novice to Expert

For the menubar and toolbar, the transition to expert use requires that novice start with the menubar, learn the icons for each command from the menu item captions, find the corresponding icons on the toolbar, then start using the toolbar. Learning accelerators requires a similar process, except at least users know where the keys are on the keyboard, unlike the icons in a toolbar. Putting it that way, it’s little surprise that the transition from the menubar to the toolbar rarely goes smoothly. For the menu bank, however, that transition from novice to expert use is easier, and also nonexistent. By “nonexistent,” I mean that experts and novices alike use the exposed menu items. Common commands as exposed menu items are easier to find than menu items on a pulldown menu, and easier to read than icons on a toolbar. Unlike a menubar and toolbar, the most important controls for the novice to see are also the most salient and have the clearest labeling. Selection of common commands as exposed menu items is also as fast or faster than selection of a toolbar control, so they are used by experts as well. There is no requirement for experts to use a different form of command selection than novices.

By the menu bank being “easier,” I mean that other transitions to expert use are easier with the menu bank than with the menu bar. I already covered how the transition to using accelerators is easier for exposed menu items on a menu bank than for commands in a menubar and toolbar. The only other transition to experthood a user can make with the menu bank is to Abbreviated display. However switching to Abbreviated display is easier than switching from using the menubar to using the toolbar, thanks to two characteristics:

• The use of abbreviated text labels rather than icons. Users used to Full display at least know the menu item’s full name since they look at it each time they select the command. Finding the matching abbreviation in Abbreviated display is pretty easy even though the users had never seen the abbreviation before. In contrast, for the menubar and toolbar, users have to find an icon on a toolbar that was shown in a pulldown menu (assuming the app thought to do that). The problem with that is there’s nothing to make the user really look at and learn the icon in the pulldown. My impression is that they more often learn the text label but not the icon.
• For the menu bank in Abbreviated display, each menu item remains in the same position in the window as in Full display. Users actually rely on the positions of menu items to help identify them. By keeping the “expert” menu items for a menu bank in the same place as the “novice” menu items, users can find them even if they don’t immediately recognize the abbreviation. In contrast, a toolbar is separate from the pulldown menu, so users cannot rely on such spatial memory.

Duplicate Commands Add Complexity

With the menubar and toolbar, the toolbar should have the same commands as can be found in the menubar. This is necessary to support both novices and experts, but such redundancy results in a cluttered and complicated UI that hurts both. The menu bank has true one-stop shopping -a menu item is either exposed or unexposed, not both -simplifying the UI. The menu bank also lacks the Ribbon’s Minibar bar and Quick Access Toolbar that likewise add complication and confusion. With the menu bank, if the command is not there, then it’s not there. Like a toolbar, users only using the common commands (which is most of the time) won’t find uncommon commands getting in the way. Unlike a toolbar-and-menubar combination, users searching for uncommon commands don’t have to wade through the clutter of common commands -when the user opens a cascade menu of unexposed menu items, only uncommon menu items are there.

One advantage that toolbars have is to provide fast access not only to commands otherwise found on the menu bar but to commands otherwise buried in dialog boxes. In general, redundancy should be minimized, but with the menu bank the designer has the option of including exposed or unexposed menu items that provide fast access to commonly used functionality also in dialog boxes. For example Paste Text and Paste Format may also be executed through the Paste Special dialog box (see second illustration), but having these as menu items (optionally with accelerators) make them easier to use. Whether such redundancy is worth the added complexity is a design decision (I’ve included it in the above illustration based on personal use, not because of any real data). But in any case, the overall amount of redundancy with a menu bank is less than a menu bar and tool bar.

User Must Select the Appropriate UI

With the menubar and toolbar, the user has to decide when to use the pulldown menu and when to use the toolbar, adding to the mental workload a task that the user may not have the background to handle. The one-stop shopping of the menu bank eliminates most of this workload. However, I admit there is one place where the user does need to decide on the UI for the menu bank: Full or Abbreviated display. To be honest, I don’t know how well that will work out. Will users know to switch to abbreviated once they’ve learned the menus and reap the benefits of increased useful real estate? This decision, however, has one advantage over deciding between menubar and toolbar use: users only have to make it once for each entire app, in contrast to making it for each command.

You Still Haven’t Explained the Sideways Orientation

Okay, okay. When I first started kicking around the menu bank back in 2005, I gave it a  horizontal orientation across the top of the window, like a conventional menubar and toolbar (or like the later arriving Ribbon). Exposed menu items appeared left to right for a given menu, and menus abutted end to end. However, I soon switched to vertical for the following reasons:

• A vertical orientation fits more exposed menu items than a horizontal orientation for typical window sizes, assuming a single dimensional array of menu items. Where an 800 pixel wide window can only fit at most about 18 menu items in Full display (if you limit yourself to short single-word captions), a 600 pixel tall window can fit up to 26 menu items, and they can have longer captions. In other words, for the smallest window you’re likely to have for a major application, you can fit about the average exposed menu items you should have.
• A vertical orientation means one caption per line, making it easier to delineate mulit-word menus items and menu labels from each other. A horizontal orientation can make multi-word captions appear like two separate menu items or menus, perhaps forcing you to use only single-word captions, as is the standard for menus on a menubar. There’s some evidence that multi-word captions improve command findability, so it’s good to have this option available to the designer (see Huang S-C, Chou I-F, & Bias RG 2006. Empirical evaluation of a popular cellular phone’s menu system: Theory meets practice. Journal of Usability Studies, 1(2), p 91-108).
• Generally the vertical dimension is more valuable than the horizontal dimension. You need as much vertical space as possible to show an entire page in a document-based application or a long form in a database application. Screens tend to be wider than high, so for graphic applications like GIS you want to consume as little of the vertical dimension as possible to get a square display. With cinematic aspect ratios becoming the norm for monitors in order to support media viewing, side real estate is even more abundant now than before.
• The vertical orientation is consistent with that used for context menus (which should be present along with the menu bank in applications) promoting internal consistency. The vertical orientation is also used for pulldown menus on a menubar, so this promotes external consistency with other apps too.
• Scanning down a list of labels in a menu for a target menu item  is easier than scanning across (see Parkinson SR, Sisson N, & Snowberry K, 1985. Organization of broad computer menu displays. International Journal of Man-Machine Studies, 23, p689-697). This is especially effective if the caption of each exposed menu item starts with a unique key word.
• With a horizontal orientation, longer menu item captions take more space, suggesting that they are more important, when that is not necessarily the case. With a vertical orientation each menu item is the same size, although if you wanted to make more important (or more commonly used) menu items bigger, you make them extra tall (so far, I haven’t see much need for this, but maybe it’s a good idea with very complex apps).
• The vertical orientation allows for a more effective Abbreviated displays by removing letters from the menu item captions. This wouldn’t work for a horizontal orientation unless you also re-arranged the menu items, which would break the spatial stability important for users to make the transition from Full to Abbreviated. Other means of abbreviating the display for a horizontal orientation (e.g., decreasing the bank height by using flatter font) are not attractive to me.
• While top or bottom mounting of the menu means the mouse tends to slew mostly vertically from the workspace area of the window, side mounting the menu means the mouse tends to slews mostly horizontally to reach the menu. Menu items are almost always wider than they are high, so this side mounting tends to align the largest dimension of each menu item with the direction of the slew, making selection fastest as predicted by Fitt’s Law. You can complain about the real estate consumed by Full display, but its consumption that makes the user faster at selecting menu items.
• Speaking of Fitt’s law, with the menu mounted on the side of the window, clever users can position the left edge of the window past the edge of the screen, which allows them to slew-and-smack the mouse pointer against the menu items for faster selection. The same benefits exist for any user that maximizes the window: the edge of the menu items are right on the edge of the screen. If the menu were on the top, there wouldn’t be this benefit on Windows or Linux platforms because the title bar separates the menu from the top edge of the screen.

There. Satisfied?

To be fair, there are some disadvantages with the vertical orientation. I’ve already mentioned the possibility of the cascade menu extending beyond the bottom of the screen, which would at least make for unpredictable behavior. However, the side-centered cascading makes that a pretty rare edge case.

Given the number of exposed menu items varies with each application, the relative position of standard menus like Copy and Paste can shift between applications, which can interfere with the users developing habits or muscle memory for these menu items. I think this is another reason to have graphically clear boundaries for each menu so users can easily see differences across apps. In any case, it shouldn’t be much different from what can already happen with pulldown menus or toolbars, which may also have application-specific items inserted between standard items.

Overall, I see more advantages with a vertical orientation. Besides, these days it’s hardly an alien design -side bar menus are the norm for the web.

One Size Fits All?

The menu bank is intended to be scalable, working well with everything from simple utilities to full-featured office productivity software, and thus providing a single interface principle that users can learn and use across a wide range of apps. This is something a multi-tabbed Ribbon is ill suited for, working best only with very complex apps. It’s also something the classic menubar has difficulty with, especially at the small end of the scale. When I see a simple app with a menubar holding just File and Edit (and File includes one menu item: Exit), I think “what a waste.” What a waste of space to take up the top 24 pixels of the window just to show two words. What a waste of time to have to make two clicks to get at so pathetically few menu items. I want the menu bank to avoid that kind of waste.

For the simplest apps, such as a something to set the parameters of a service, the menu bank may be little more than a few exposed menu items for basic editing (undo, cut, copy, and paste). As an app gets more complex, more exposed menu items are added until you get to about 20, and then you add unexposed menu items on cascade menus accessed by the disclosure arrows. If you figure each disclosure arrow on the menu bank accesses the same number of menu items as a pulldown menu on a menubar, the menu bank can easily support an app with 100s of commands. A 600 pixel high window has room for about 20 exposed menu items plus 8 disclosure arrows. Even very complex apps rarely have more than 8 pulldown menus when a menubar is used.

For extremely complex apps, those with over 1000 commands, I’m thinking you can borrow the tab idea as seen with the Ribbon (click for full view).

In this variation, the menu bank includes several alternative tabs at the bottom that each display an entire alternative menu bank providing access to an additional set of hundreds of commands per tab. Like any tab and unlike a cascade menu, each menu bank tab remains opened until explicitly closed or replaced by another tab. Thus, as with the Ribbon, each tab should represent a major activity, like an application within the application, so that once a user selects a tab, one doesn’t need to switch to another one for a while. While the Ribbon replaces the “home” tab with the alternative tabs, I recommend each tab appear beside the main parent menu bank so that users alway have access to basic commands needed across multiple major activities without the designer resorting to additional complexity like a Minibar or Quick Access Toolbar.

A more conventional alternative for extremely complex apps is to display additional menu banks on floating utility windows, like is commonly done with tool palettes. This has the advantage that displaying an additional bank won’t change the size of the workspace area of the parent window. Also, users can then display more than one additional menu bank at a time, which reduces the need to make each menu bank a self-contained activity, although organizing by activity isn’t a bad way to divide up menus.

Another alternative is to display the additional menu banks as a quasi mode, such as by holding down a key (maybe the Esc key?). By pressing the key with a finger of the non-mousing hand, the user can access the additional menu banks almost as fast as the parent bank, so the additional banks can disappear after each menu item selection (see more in Kurtenbach G, Fitzmaurice GW, Owen RN, & Baudel T (1999) The Hotbox: Efficient access to a large number of menu-items. CHI ‘99, p231-237).

More Extensions

There are other variations to the menu bank you can try. I don’t think it’s a good idea to automatically determine what menu items are exposed or not, but it may be a good idea to give some expert-level users some control over the matter. You could provide a menu bank customization feature to allow users to explicit select what is and is not exposed. You could also provide a mechanism to easily expose all menu items for a menu in case a specific but unusual task requires repeated executions of one or more menu items within. You could make it possible to “pin” the cascade menu open, by the user clicking an icon on the cascade or through some form of expert activation like double-clicking or control-clicking the disclosure arrow. When pinned open, the unexposed menu items appear on the menu bank below the normally exposed menu items, pushing menu underneath down the side of the window for room. Another approach that doesn’t interfere with the appearance of the menu bank is to employ a nearly forgotten but very useful design element: the tear-off menu. By providing users a handle at the top of each cascade menu, users can drag it off to become a floating utility window with all its menu items exposed.

With each exposed menu item in Full display being as long as the longest menu item, many will have appreciable space that can be put use. One use is for status indicators, allowing feedback proximal to the associated command for such indicators. For example, the Save menu item can show an icon to indicate if there are unsaved changes, Print can show the status of the printer, Spell Check could show if there are any detected spelling errors, and Word Count can give a running total of the number of words (as shown in the top illustration). Personally, I don’t see a problem with the menu bank including non-interactive items that are just status indicators, as long as the graphic design accurately signals its non-interactive (non-menu-item) class. By placing status indicators on the menu bank you not only provide intuitive proximity between action and feedback, you may also be able to eliminate the status bar from your app, allowing the menu bank to trade horizontal real estate for the more valuable vertical real estate.

Summary Checklist

Problem: Creating an alternative menu control that eliminates the problems with the traditional menubar and toolbar, and the Ribbon.

Potential Solution: The menu bank, which has:

• A vertically oriented array of menus.
• Exposed menu items for commonly used commands.
• Side-centered cascade menus for non-commonly used commands.
• Distinct appearances for different kinds of menu items.
• Inclusion of status indicators within relevant menu items.
• Abbreviated display, using abbreviated menu captions rather than icons.
• Consistency with conventional menubars on standard menu content, captions, and keyboard control.
• A capacity to scale from very simple to very complex applications.

This entry was posted on Sunday, February 1st, 2009 at 9:06 pm and is filed under Menus and Toolbars. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.