Navigation through Toolbars and Menus
I’ve said this many times before, but I’ll say it one more time here: When you build your toolbars and menus, remember that you are providing access to the underlying commands in your system. Here’s a tip to get you started:
| SUGGESTION | Do not put extra code behind the toolbar buttons and menus beyond simply calling the command functions. |
The reason for this is you don’t want to tie functionality directly to a button or menu item; doing so will force you to go outside a generic data structure or class for a particular button, perhaps by subclassing. That will make things messy, and soon you’ll have button-specific or menu-specific code throughout your program. And with such additional complexities comes the likelihood of more bugs. Remember, simplicity is the key!
But beyond the coding difficulties, one fundamental reason is that if you provide a macro language for your product, you want the people to have complete access to the commands through macro programming, separate from the toolbar buttons and menu items. If you have extra code outside the commands, then users won’t have access to that code through the macro language. (Unless, again, you start hacking things and making a mess!)
In the sections that follow, I provide you with tips on creating your toolbars and menus in the light of the programming issues I’ve just described. But before I get started, remember one final important rule:
| RULE | Save the user’s customizations! If the user modifies the menus or toolbars, save the changes and reload them when the program restarts. You can save them in a file or in the Registry. If you use a file, put it in the user’s own directory space. If you use the Registry, use the HKEY_CURRENT_USER key. |
Laying Out a Meaningful Toolbar
Different usability experts have different feelings on the most effective use of the toolbars. Some people say they should completely mimic the menus. Other people say they should have only minimal functionality. To understand how best to use toolbars in your application, consider this fact: Toolbars are, by and large, used mostly by intermediate-level users.
There are, of course, exceptions to this, but the usability experts tell us this is true, and I’ve personally witnessed it to be true. However, this doesn’t mean you should pack borderline-power-user features into your toolbar. Remember, unlike the menu items, the toolbar buttons are all sitting right out there on display for the users. You don’t want to intimidate your beginning users by offering a huge pile of toolbar buttons.
The best way to handle this is twofold:
-
First, as I’ve harped over and over, make your toolbars and menus configurable.
-
Second, provide multiple toolbars. At startup, the “standard” toolbar opens, which includes such basic items as New, Open, Save, and so on (as long as these are appropriate to your application). In addition, you can have toolbars that are organized by general functionality. But don’t make these other toolbars automatically visible; this will overwhelm beginning users. Let the users choose which toolbars to display, and consider making certain toolbars turn on when they are needed. (For example, an imaging toolbar would come on only during graphics operations, as in Microsoft Word.)
As a case in point, I recently downloaded a shareware program that started up with no less than 10 toolbars, each with roughly 20 buttons. That’s 200 buttons! I was incredibly overwhelmed by just the sight of the program, and I wasn’t sure I would be able to figure out how to use the program. And even when I learned how to use the basic features, I was still intimidated (and I’m a software engineer!), because I knew there were all these other features staring at me in the form of toolbar buttons, features that were seemingly telling me, “I’m here, and you haven’t used me yet, so you’re not doing it right.” So massive amounts of toolbar buttons can be intimidating to first-time users of your program regardless of how advanced those users are.
What to Put on a Toolbar
This might seem obvious at first, but you put buttons for accessing commands on your toolbars. However, some of your commands might require parameters. That’s when you can use items other than buttons. For example, suppose you have a SetFont command, which takes a font name as a parameter. On a toolbar, you could have a drop-down combo box listing all the installed fonts. When the user selects the font, the SetFont command will get called, and the code will pass the name of the font to the command. Easy!
You can also get fancy by creating your own owner-draw drop-down combo boxes. For example, you might include a color box, like this one from Microsoft Word:
Again, when the user selects an item in this drop-down box, the toolbar code would call a command, passing as a parameter the selection (which will likely be a number representing the color or perhaps an enumerated data type).
Also:
| RULE | Include a ScreenTip for each of the controls on your toolbars, since the controls usually don’t have any other text associated with them. |
Constructing Sensible Menus
A few years ago, Microsoft came up with a novel approach to the problem of their menus getting longer and longer with each release of the Microsoft Office products. The menus would contain only the most recently used items, and at the bottom would be a double down arrow that you could click to expand the menu to include all its items. The following image shows this:
My personal feeling is that I can’t stand this dynamic menu capability. I always turn it off.
The reason I don’t like the dynamic menus is that the menu items change. When I’m trying to quickly find my way around, the last thing I need is for my old standard menus to be changing on me. While the order of the menu items doesn’t change, the position on the screen does change since some items aren’t showing. And worse, if I use somebody else’s computer, the menu items look completely foreign to me. Further, the two stacked down arrows at the bottom of the dynamic menu represent a new idiom for beginners to learn.
Microsoft recognized an actual problem, that the menus are long and unwieldy. Personally, I think the menu customization is a much better alternative (which you can still do through the Customize menu) because it lets me pick which menu item I want displayed and where.
Add to this an easily navigable menu system, and you have two excellent menu features:
-
Your menus are customizable.
-
In their natural, uncustomized state, they are easily navigable.
How do you make menus navigable? Here are some pointers:
-
Use the standard, agreed-upon names for the menus and the standard ordering.
-
Avoid cascading menus as much as possible.
-
Include keyboard shortcuts to the menus.
Now I just said to use the standard, agreed-upon names for the menus, yet a lot of usability experts suggest a better name for the File menu. That’s fine. If you want to call the File menu something a bit more descriptive, then go for it. That’s one case where users seem to be fine, and a better name is definitely in order.
As for keyboard shortcuts, remember that menus typically have two keyboard shortcuts. However, one of them is just a keyboard way of accessing the menu (and not really a keyboard shortcut by our definition), and the other really is a keyboard shortcut. For example, in the sample menu shown earlier in this section, you can press the keyboard shortcut Ctrl+N to activate the New menu item, or you can press Alt+F to open the File menu (since the F is underlined in the menu name) and then N to activate the New menu item (since N is underlined in the new item). Pressing Alt+F and then N is not a keyboard shortcut; it’s just using the keyboard to activate the menu item.
| Tip | Technically speaking, when you press Ctrl+N, you are not activating the File |
Here are some rules, now, that you can follow in building your own menus:
-
Don’t modify the menus by adding and removing menu items. Instead, gray out items when they’re not needed and reenable them when they are needed. (The various APIs provide functions or methods for graying out and reenabling menu items.)
-
If you have a check mark on a menu item, running the command behind the menu should toggle the check mark.
-
Avoid cascading menus as much as possible.
-
Put an ellipsis (you know, three dots) after the menu text if that menu opens a dialog box. Doing so is customary.
The item about the check mark needs a bit of further clarification. For example, if you have a word processing program, and the ruler is visible, you might have a Ruler item under the View menu, and this Ruler item might have a check mark beside it. When you choose the Ruler menu item, the ruler will go away, and so will the check mark on the menu. When you again choose the Ruler menu item, the ruler will return and so will the check mark.
You might also have a toolbar button for showing and hiding the ruler. A common mistake is to forget to toggle the check mark on the menu item when you click the toolbar’s Ruler button. But an easy way to avoid this mistake is by putting the code to toggle the menu item right in the command.
| Note | However, some of the purists out there might disagree, saying the command itself shouldn’t be mucking with the user interface. They would argue that the command and the GUI should be separate. But my own experience is that such separations are good in theory but don’t really work in practice. Personally, I’m fine putting the check mark–toggling code right in the command code, because otherwise you have to put the same code in multiple places, and further, you have to have check box–toggling code that runs in response to the toolbar button press in addition to the command code running. And that, frankly, is messy. |
As for cascading menus, here’s an example of what I mean by that term:
Although the idea behind a cascading menu is sound (the hierarchy adds a nice level of organization), in practice, cascading menus are simply difficult to use. I personally use a Logitech Marble Mouse trackball to help alleviate repetitive elbow motions, and although the trackball works great for almost everything, cascading menus are extremely difficult to maneuver with the trackball. And I find they’re even harder to use with the touchpad that comes on most notebook computers. So please, avoid cascading menus if possible.
But all this is fine and dandy for a sunshiny day, but what about the original topic of this section, laying out meaningful menus? While I certainly can’t tell you exactly how to lay out your menus since everybody’s program will have different menus, I can give you the following tips:
-
Try to stick to the standard menus. You’ve seen these; in Windows these are File, Edit, View, Tools, and so on, plus Window and Help.
-
Use a standard ordering of the menus. Don’t put your File menu to the right of the Edit menu. Again, that’s common sense, and you know it already anyway.
-
Since menus are typically used by beginners, place the commands beginners are likely to use more often at the top of the menu.
-
Try not to have more than 15 or so items on a single menu. In fact, lean more toward shorter menus, such as seven or eight items. But when you do have several menu items, use a horizontal divider bar to separate similar items.
Be careful when coming up with your own menus besides the standards such as File, Edit, and View. You may have a very good reason for adding a menu, such as an entire category of commands specific to your product, and that’s fine; go ahead and add it. But first see if the menu makes sense in a standard menu such as Tools.
However, be careful with the Tools menu. If you have lots of functionality, and you start piling it all under the Tools menu, you may quickly end up with a menu that’s just too big and unwieldy. Generally speaking, the Tools menu has higher-level tools beyond simple use cases. For example, in a word processor, you wouldn’t put Toggle Italics, Toggle Bold, and other smaller use cases under the Tools menu. (Microsoft Word, for example, doesn’t even have menu items for these, although by using the Customize dialog box you can add such menu items. Instead, Microsoft Word has Track Changes and other large-scale features under the Tools menu.)
When to Use Images in Your Menus
In general, I don’t care much for images in the menus, primarily because the images people choose are often rather meaningless. The words in the menu serve more purpose than the images. However, that doesn’t stop people from using symbols in the menus.
Microsoft has come up with a set of symbols that have basically become standard, and they use these symbols on their menus. I hesitate to suggest that you should use these same symbols, because like most people, I usually don’t like the idea that Microsoft makes all the rules and we must all follow them. However, if you’re writing software for Windows, the users usually do recognize the symbols. Here’s a sample menu from Microsoft Word showing some of the Microsoft standard images:
As you can see, these are the same images that Microsoft typically uses in the toolbars. Therefore, here’s a rule to consider:
| RULE | If you’re using images in your menus, use the same images as in the corresponding toolbar buttons. |
Creating Reasonable Pop-up Menus
One particularly useful idiom is the pop-up menu, sometimes called a context menu by some programming tools. A pop-up menu is a menu that appears when you right-click an item or when you press the little Pop-up Menu key on the keyboard. Here’s an example of a pop-up menu:
Interestingly, a lot of people I’ve spoken with (even several power users) don’t know what that key does. That should be a hint to all of us: People don’t always use pop-up menus. Bear that in mind as you read this section.
| RULE | First and foremost, a pop-up menu should be short. Don’t have more than seven or eight items on the pop-up menu. |
One exception to this rule is in programming tools. Programmers seem perfectly fine having lots of items on a pop-up menu for a code editor, for example. However, be careful because if the pop-up menu is too long, it won’t fit within the screen’s height, and you’ll end up with little arrows for scrolling at the top and bottom. That can be really annoying because the scrolling tends to be rather slow, even on fast computers.
What do you use a pop-up menu for? First, remember that another name for pop-up menu is context menu. In other words, you’ll probably have different pop-up menus for different right-click situations. If the user right-clicks a toolbar, a pop-up menu with a Customize item might appear. If the user right-clicks some text, a pop-up menu allowing cut and paste (or whatever) might appear. Generally, however, you’ll put pop-up menus only in places where the user spends time working. For example, in a word processing program, a pop-up menu is good in the main editor area. In addition, you can include a pop-up menu on toolbars that can be configured; the users can access the configuration from this pop-up menu. However:
| RULE | Don’t put functionality on a pop-up menu and nowhere else. Sometimes people don’t think of right-clicking the mouse! Always include access to the functionality elsewhere, such as in the main menu bar. |
The pop-up menu really is obscure. When you’re looking at a screen, you have no indication whatsoever that a pop-up menu is available. And for that reason, users really do often miss them. Although I can’t remember which program, recently I was using a program I’ve been using for well over a year, and by chance I right-clicked the mouse and was quite pleased to discover a pop-up menu that I didn’t know existed. So don’t expect that your users will find the pop-up menus.
Further:
| RULE | Don’t put cascading menus on a pop-up menu. |
Cascading menus are bad enough and you should use them sparingly. But putting them on a pop-up menu is a really bad idea.
How do you create a pop-up menu? The various GUI toolkits people use have classes and functions for creating pop-up menus. The worst way in Windows is when you’re directly using the Windows API (something I discourage people from doing, because the functions are straight C calls). The API includes a function called TrackPopupMenu, which takes an HMENU as a parameter. Yes, you can do this if you wish. But I prefer the simplicity of tools such as Borland’s C++ Builder, which lets me create a pop-up menu object and then attach it to a control. Why spend hours programming something when you can do it quickly?
| Note | Nevertheless, many programmers I’ve met over the years still insist on being masochists, although I suspect it’s an ego issue: If they find their work difficult, then they feel proud when they’ve finished, knowing that other people couldn’t do what they do. Not to get too far off on a tangent, but this is an issue I have with programmers because it has a direct result on the usability of the code. I talk about this in “Dealing with Egos” in Chapter 15, “Book in a Book: A Guide for Programming Bosses.” |
REAL WORLD SCENARIO: E-books in a Web Browser—The Next Button Dilemma
 |
A few years ago I was involved with a dot-com startup that was doing e-book software. When we first started talking about the software, we brainstormed though dozens of pretty good ideas. One of the ideas was to simply display the information in a web browser.
But there was a problem, and this problem affects a lot of online documentation software, such as the help system in Windows. The problem is that the forward and back buttons on the browser are not analogous to turning a page forward and backward.
If you’re flipping through this book, and you’re on, say, page 90, and then you flip ahead to page 100, the analogy of the back button is returning to page 90, not turning one page back. And once you’re back on page 90, the analogy to the forward button is to return again to page 100.
In a book, however, a forward button would make more sense to represent moving forward one page. A back button would be more sensible for moving backward one page. This is very different from the meanings of the buttons in a web browser.
One person suggested somehow rigging the back and forward buttons to navigate backward and forward though the pages. But I argued against that, because that would change the fundamental behavior of the web browser buttons (not to mention that it would be extremely difficult to reprogram those buttons without writing some serious hacks). Instead, I proposed that we code our own separate buttons right in the HTML. We finally agreed on this, in conjunction with a tree control on the left that would list the chapters as a table of contents.
But to make matters worse, we still had a problem with our e-books, and that was with the individual pages. When you’re looking at a single page in a book, you can see the whole thing at once, and all the pages in the book are the same size. In a web browser, however, a single page can span well beyond the bottom margin of the screen, and you must scroll to see the rest of the page. Further, each page can be a different length. So our question was this: Do we map one page per web page, or do we put all the pages within a single chapter on a single web page?
Other people have been faced with these questions. For example, when you download online documentation for the various free programming tools (such as PHP and MySQL), you can often download all the docs as one giant HTML file or you can download the docs as multiple HTML files along with a single table of contents file. The reason is that different people have different preferences. As software developers, then, we can do everybody a favor by supporting the different preferences, thereby accommodating everybody.
|
EAN: 2147483647
Pages: 114