GUI Control and Navigation

From Mac vs. Windows

One way to measure the user-friendliness of an operating system is by exploring how users navigate its environment and interact with running applications. Poor decisions in design and usability can lead to a poor user experience.

Application Menus

Every application comes with its own menu bar containing various commands and tasks available to the user. Mac OS X and Windows Vista take radically different approaches for the layout of these menus bars. Both have their advantages and disadvantages.

Mac OS X Leopard

Mac OS X uses a single, unified menu bar at the top of the screen. The contents of the menu bar change depending on which application is currently active. Launching or switching to another application replaces the previous application's menus with those of the now active application.

Because the Finder is the active application, its menus appear in the Mac OS X menu bar.

The first menu on any Mac OS X application menu bar is the application menu. It has the same name as the application and holds commands that control the application overall settings and functionality. Such commands include preferences, hiding/showing windows, and quitting. It also serves as a feedback mechanism to let the user know what menu application's menus they have loaded in the menu bar.

Safari's application menu holds commands that controls the functionality of the application itself such as blocking pop-ups and enabling private browsing.

All application Help menus include search boxes. Users can search the application's help documentation along with its menu commands. This can be very useful in situations where a user is looking for a particular command, but can't remember which menu it's located under. Type the command name into the Help menu and select it from the search results. The appropriate menu will open in the menu bar with a large animated arrow next to the item.

The Help menu's search box makes locating documentation and menu commands for a Mac OS X application simple.

Using a unified menu bar has a number of benefits:

• Easy to locate. The menu bar is always located in the same place, regardless of where an application's window might appear on the screen.
• Reduces screen clutter. Users can only access one menu bar at any given time, so showing the menu bar for each open application is unnecessary.
• Impossible to overshoot. Since the menu bar is fixed at the absolute top of the screen, there's no way to move past it with the mouse pointer.
• Reduces the need to relaunch applications. This design The majority of Mac OS X applications (with the exception of a few such as iPhoto) continue running even after all of its windows have been closed. Since the menu bar appears outside the windows, commands can still accessed.

Another benefit with this design is that it reduces the need to relaunch applications. Mac OS X doesn't treat windows as separate running instances of the application. Even when all of an application's windows have been closed, it can remain running with its menus still accessible from the menu bar.

However, the Mac OS X menu bar isn't without its flaws.

There are no keyboard mnemonics to access and open specific menus directly. You need to focus the menu bar (ctrl-f2 by defaut, editable in the keyboard and mouse system preferences panel), and then navigate though the menus using the arrows.

Application menus share their space on the menu bar with menu extras the user has loaded. With widescreen and high resolution displays, there is plenty of space for both. But if an application has too many menus and the user's screen is small, the menus can overlap the menu extras.

In such a situation, the only way to access the hidden menu extras is to switch to another application with a smaller set of menus.

Application menus in the Mac OS X menu bar can overlap menu extras if there are too many menus.

Another annoyance results from Mac OS X applications being able to remain running once all windows are closed. It's menus will continue to appear in the menu bar as long as it's the active application. One may accidentally assume the menus belong to the frontmost window (which is inactive).

For example, let's say a user has an open Finder window with a Safari window behind it. Closing the Finder window doesn't cause Safari to become the active application. Unless the user switches to Safari, the Finder remains active with it's menus in the menu bar.

Because you haven't actually switched to Safari, the Finder is still the active application, even though it has no visible windows.

Typically, however, a user becomes accustomed to actually checking the menu bar before blindly clicking it. The application menu in the menu bar always lists the application name that is active. Another visual clue Mac OS X provides to help users identify active vs. inactive application windows is the color of their toolbars and its shadows. Windows belonging to active applications have dark grey toolbars and prominent shadows while inactive ones have a light grey appearance and virtually no shadows.

Another disadvantage of the decoupled menu design is exposed when the user needs to invoke menu actions from different applications: for example, a typical Cut/Copy&Paste workflow between apps could force the user to travel back and forth the mouse pointer to the menu and the app window, neglecting the ”Impossible to overshoot” advantage, depending on how far the application windows are from the menu bar. This effect can be especially counterproductive under multi-monitor scenarios, when the menu bar resides on a different monitor as the applications windows do.

Windows Vista

There is no central location for application menu bars on Windows. They all appear at the top of each window. Even when the same application has several windows open, each one will display the same menu bar. This is due to Windows treating each window as a separate running instance of an application.

One advantage to this design is that it's very clear to which menu bar belong to which application. There's no possible way to accidentally associate the menu bar in one window with that in another window.

There's also no need to switch to an application first before accessing it menus. Unless the application window is not visible on the screen, the act of clicking on another window's menu bar will bring that application to the front.

Since Windows treats the menu bars as any other optional window control, developers can make the choice of dismissing them all together from their apps, if they think they are not required. This not only saves screen real state, but also presents an opportunity to innovate with more user friendly options for controlling the applications. In fact, Vista seems to set a trend of getting rid of this type of controls, or at least, hiding them from users by default.

But like everything, there are disadvantages.

• There's no fixed place for an application's menu bar. This does slow down the user to some extent when looking for a menu item.
• Because menu bars are attached to their parent windows, their width is always dependent upon the width of the window and not the screen.

Windows Vista introduces a new layout for application menus. This results in two different types of menu bars being used throughout the operating system.

The first menu bar type is the most common and uses the traditional "File", "Edit", etc. menus that have existed in previous versions of Windows. The second type, new to Vista, is the command bar. It's items change based on what the user is currently doing inside the application. Some applications that use this new layout include Explorer and Windows Photo Gallery.

The command bar will change its contents to be specific to the file or folder that is currently selected. For example, select a picture file and the command bar will display commands such as Preview, Slideshow, and Print.

Those applications using the new command bar often hide the traditional menu bar. One issue that results from this decision is that some commands in an application can only be accessed from the hidden menu bar. While the menu bar can still be enabled temporarily by pressing the Alt key, it adds an extra step to what the user must do.

It's important to note that menus in all Windows applications can be accessed using the Alt key in combination with keyboard mnemonics. When you press the Alt key, you'll see each main menu item has an underlined letter. Typing the underlined letter of the menu you want to open will open that menu. Then you'll see each menu command also has an underlined letter. Again, typing that underlined letter on the keyboard will activate that command. The advantage to this method of accessing menus and commands is that you do not need to reach for or move the mouse pointer at all. You can keep both hands on the keyboard and access all commands within the application.

You can also use a combination of keyboard mnemonics and mouse movement to improve efficiency. For example, you can use the left hand to type Alt+F (which opens the File menu) while at the same time, moving your mouse pointer to that menu in order to activate a command.

Keyboard Support

Mac OS X

Mac OS X supports any standard Mac/Windows USB and Bluetooth keyboards. However, some extra functionality on Windows keyboards may not work unless the manufacturer has created drivers for Mac OS X. If Mac OS X fails to recognize one's keyboard, it will ask the user to press specific keys on the keyboard to help it determine the type of keyboard being used.

Under System Preferences > Keyboard & Mouse > Keyboard > Modifier Keys, users can swap the keys that are used for modifiers such as CMD, OPT, and CTRL. For example, one can configure Mac OS X to see the OPT when the CMD key is pressed and vice versa. Modifier keys can also be disabled such as the "caps lock" key for those who always find themselves accidentally engaging it.

Being able to change which keys on a keyboard are mapped to which particular Mac OS X modifer is very useful for those using Windows keyboards and are used to Mac versions where the modifier keys are in a different order.

The Keyboard Shortcuts tab controls the default shortcut assignments for the Mac OS X system as well as installed applications. From this dialog, users can edit existing shortcuts or create completely new ones for any application's menu item if it does not already have one.

The "Full keyboard access" setting determines whether the tab key moves between text boxes and list or between all controls.

Windows Vista

Windows Vista supports keyboards over PS/2, USB, and Bluetooth connections, though, as with OS X, may require manufacturer-provided software to access more advanced functionality of those keyboards, such as media control keys.

Vista supports the use of the keyboard for GUI navigation, supporting Alt-Tab or Win-Tab window-switching shortcuts, the use of the tab key and arrow keys for navigation of application windows, etc. Applications on Vista will, unless the developer sees fit to choose otherwise, conform to standard CTRL and ALT key combinations, such as Ctrl-C for copy and Ctrl-V for paste.

Additionally, Vista has a selection of system-wide shortcuts involving the Windows Key. Examples include WinKey-M to minimize all windows (Winkey-Shift-M restores them,) WinKey-T to focus the taskbar, and the WinKey on its own for toggling the spacebar. None of these shortcuts are modified by the user.

Mouse Support

Mac OS X

Mac OS X supports most USB mice as well as many bluetooth mice. OS X includes a "keyboard & Mouse" preference pane in "System Preferences" that can configure basic mouse preferences though many OS X supported mice come with configuration software to configure advanced features of the mice.

Under the "keyboard & Mouse" pane are tabs for "Trackpad"(for MacBook) and "Mouse" and "Bluetooth". Within the Trackpad and Mouse tabs you can set whether to enable right click supports via the mouse (If you have a two button mouse) as well as whether holding the control key and using the mouse's scroll (if present) zooms the screen image in or out.

Windows Vista

Windows Vista also supports PS/2, USB, and Bluetooth mice. As with keyboards, basic functions standard to all mice, such as the scroll wheel, are accessible without additional software, but mice with additional buttons may require special software to access those functions.

The Mouse Properties control panel contains options for button assignments, click speed, pointer motion speed and acceleration, wheel speed, and pointer look. It also includes usability options such as displaying a trail after the mouse or moving the mouse pointer to the default button in dialogs.

Voice Control

Mac OS X

Voice control is managed by the Speech preference in System Preferences. Click on speakable items to turn on speech recognition. No training is required. Dictation is not supported. Third party applications like Dictate and ViaVoice are required for dictation.

Windows Vista

Windows Vista supports microphones connected through Line In, USB, or Bluetooth. Microphones may be used to control the user interface with an application called Speech Recognition. Upon being launched for the first time, Speech Recognition offers to walk the user through a tutorial session, while it simultaneously begins adapting to the user's voice.

The Speech Recognition is manifested on the desktop with a dockable applet that displays the status of the speech recognition engine (off, sleep, or listening,) and feedback if necessary. The GUI can be navigated with several different strategies. Speech Recognition can be told to "Click target"(if more than one target matches the spoken command, numbers will appear by each target so the correct one can be chosen,) told to "Show Numbers," which displays the aformentioned numbers next to all GUI elements, or to "Show Mouse Grid," which overlays a nine-cell grid on screen that narrows as grid regions are selected (this allows clicking on regions not identified by Speech Recognition as clickable.)

An Explorer window with numbers overlayed.

The mouse grid overlayed on the screen. When a number is specified, a nine-cell grid appears the size and location of the cell picked. This continues until the user has centered a cell on the chosen target, at which point saying "click" is used to choose the target.

Speech Recognition also supports dictation. Commands such as "Delete text", "Select text", or "Correct text" can be executed on any block of editable text. Using the word "that" with those commands allows executing them on the last sentence or word dictated.

Discuss | Show All Comparisons