Toolbar lkz windows7

Some toolbars are customizable, allowing users to add or remove toolbars, change their size and location, and even change their contents. Some types of toolbars can be undocked, resulting in a palette window. For more information about toolbar varieties, see Usage patterns in this article. Guidelines related to menus , command buttons , and icons are presented in separate articles. If your program has a toolbar without a menu bar, and most of the commands are accessible indirectly through menu buttons and split buttons , this toolbar is essentially a menu bar.

Apply the toolbar menus pattern in the Menus guidelines instead. A good menu bar is a comprehensive catalog of all the available top-level commands, whereas a good toolbar gives quick, convenient access to frequently used commands. A toolbar doesn't attempt to train users just make them productive. Once users learn how to access a command on a toolbar, they rarely continue to access the command from the menu bar.

For these reasons, a program's menu bar and its toolbar don't need to correspond directly. Toolbars present only the most frequently used commands, whereas menu bars catalog all the available top-level commands within a program. Clicking a toolbar command takes effect immediately, whereas a menu command might require additional input. For example, a Print command in a menu bar first displays the Print dialog, whereas a Print toolbar button immediately prints a single copy of a document to the default printer.

In this example, clicking the Print toolbar button immediately prints a single copy of a document to the default printer. Toolbar commands are invoked with a single click, whereas menu bar commands require navigating through the menu.

Number and density. The screen space required by a toolbar is proportional to the number of its commands and that space is always used, even if the commands are not. Consequently, toolbars must use their space efficiently.

By contrast, menu bar commands are normally hidden from view and their hierarchical structure allows for any number of commands. Size and presentation. To pack many commands in a small space, toolbars usually use icon-based commands with tooltip-based labels , whereas menu bars use text-based commands with optional icons. While toolbar buttons can have standard text labels, these do use significantly more space.

Well-designed toolbars need icons that are mostly self-explanatory because users can't find commands efficiently just using tooltips. However, toolbars still work well if a few less frequently used commands aren't self-explanatory. Recognizable and distinguishable. For frequently used commands, users remember toolbar button attributes like location, shape, and color.

With well-designed toolbars, users can find the commands quickly even if they don't remember the exact icon symbol. By contrast, users remember frequently used menu bar command locations, but rely on the command labels for making selections. For toolbar commands, distinctive location, shape, and color help make icons recognizable and distinguishable. Given their characteristics, toolbars must be designed primarily for efficiency.

An inefficient toolbar just doesn't make any sense. Make sure your toolbars are designed primarily for efficiency. Focus toolbars on commands that are frequently used, immediate, direct, and quickly recognizable. Generally, toolbars work great together with menu bars: good toolbars provide efficiency and good menu bars provide comprehensiveness.

Having both menu bars and toolbars allows each to focus on its strengths without compromise. Surprisingly, this model breaks down with simple programs. For programs with only a few commands, having both a menu bar and a toolbar doesn't make sense because the menu bar ends up being a redundant, inefficient version of the toolbar. To eliminate this redundancy, many simple programs in Windows Vista focus on providing commands solely through the toolbar, and hiding the menu bar by default. This is no small change.

Removing the menu bar fundamentally changes the nature of toolbars because such toolbars need to be comprehensive and change in the following ways:.

Removing the menu bar means that all commands not available directly from a window or its context menus must be accessible from the toolbar, regardless of their frequency of use. Removing the menu bar makes the toolbar the only visible access point for commands, requiring the toolbar to have the fully functional versions.

For example, if there is no menu bar, a Print command on a toolbar must display the Print dialog box instead of printing immediately.

Although using a split button is an excellent compromise in this case. See Standard menu and split buttons for the standard Print split button. In this example, the Print toolbar button in Windows Photo Gallery has a Print command that displays the Print dialog box. To save space and prevent clutter, less frequently used commands may be moved to menu buttons, making them less direct. Toolbars used to supplement a menu bar are designed differently than toolbars designed for use with a removed or hidden menu bar.

And because you can't assume that users will display a hidden menu bar to perform a single command, hiding a menu bar should be treated the same as removing it completely when making design decisions.

If you hide the menu bar by default, don't assume that users will think of displaying the menu bar to find a command or even figure out how to display it. Designing a toolbar to work without a menu bar often involves some compromises.

But for efficiency, don't compromise too much. If hiding the menu bar results in an inefficient toolbar, don't hide the menu bar! From the keyboard, accessing toolbars is quite different from accessing menu bars. Menu bars receive input focus when users press the Alt key and they lose input focus with the Esc key. Once a menu bar has input focus, it is navigated independently of the remainder of the window, handling all arrow keys, Home, End, and Tab keys.

By contrast, toolbars receive input focus when users press the Tab key through the entire contents of the window. Accessibility presents a dilemma here: while toolbars are easier for mouse users, they are less accessible for keyboard users. This isn't a problem if there is both a menu bar and a toolbar, but it is if the menu bar is removed or hidden. For accessibility reasons, then, prefer to retain the menu bar rather than remove it completely in favor of a toolbar.

If you must choose between removing the menu bar and simply hiding it, prefer to hide it. Choose a suitable toolbar style based on the number of commands and their usage. See the previous toolbar style table for guidance on how to choose.

Avoid using a toolbar configuration that takes too much space from the program work area. Place toolbars just above the content area, below the menu bar and address bar, if present. The Windows Internet Explorer toolbar saves space by omitting labels of well-known icons, using a partial toolbar, and using an overflow chevron for less frequently used commands. For the unlabeled icons toolbar pattern, use a default configuration with no more than two rows of toolbars.

If more than two rows might be useful, make the toolbars customizable. Starting with more than two rows can overwhelm users and take too much space from the program work area. Disable individual toolbar buttons that don't apply to the current context, instead of removing them. Doing so makes toolbar contents stable and easier to find. Disable individual toolbar buttons if clicking on them would directly result in an error.

Doing so is necessary to maintain a direct feel. For the unlabeled icons toolbar pattern, remove entire toolbars if they don't apply to the current context. Display them only in the applicable modes. Display toolbar buttons left aligned. The Help icon, if present, is right aligned. Exception: Windows 7-style toolbars left align program specific commands, but right align standard, well-known commands such as Options, View, and Help. Don't change toolbar button labels dynamically.

Doing so is confusing and unexpected. However, you can change the icon to reflect the current state. Prefer direct controls. Use toolbar buttons in the following order of preference:. Prefer immediate commands. For commands that can either be immediate or have additional input for flexibility:.

Provide labels for frequently used commands, especially if their icons aren't well-known icons. The Windows Fax and Scan toolbar has few commands, so the better version labels the most important ones. Place the most frequently used groups first. Within a group, put the commands in their logical order. Overall, the commands should have a logical flow to make them easy to find, while still having the most frequently used commands appear first.

Doing so is most efficient, especially if there is overflow. Use group dividers only if the commands across groups are weakly coupled. Doing so makes the groupings obvious and the commands easier to find. Avoid placing destructive commands next to frequently used commands. Use either order or grouping to get separation. Also, consider not placing destructive commands in the toolbar, but only in the menu bar or context menus instead.

Use the overflow chevron to indicate that not all commands can be displayed. But use overflow only if there isn't sufficient room to display all the commands. The overflow chevron indicates that not all commands are displayed, but more of them could be with a better layout. Make sure that the most frequently used commands are directly accessible from the toolbar that is, not in overflow in small window sizes. If necessary, reorder the commands, move less frequently used commands to menu buttons or split buttons, or even remove them completely from the toolbar.

If this remains a problem, reconsider your choice of toolbar style. Generally, toolbars work great together with menu bars because having both allows each to focus on their strengths without compromise.

On hover, display the button affordance to indicate that the icon is clickable. After the tooltip timeout, display the tooltip or infotip. For mode buttons, display the control to reflect the currently selected mode. If the mode affects the behavior of mouse interaction, also change the pointer.

More details here. Aug 12th, - General release 4. Jul 30th, - General release 4. May 22nd, - Beta version 4. May 21st, - Beta version 4. Classic Start Menu See all features. Classic Explorer See all features. Choose between 3 different styles: Classic Two columns Windows 7. Many usability improvements to Explorer every feature can be turned on or off :. Read the F.

Ask a question in the forum Report a bug or submit a feature request Learn how to make your own skin Learn how to make your own start button. Very well made with lots of options. Makes Windows 7 worth using. Saves me from daily frustration. Thank you so much!

No more frustration, I can work just like I used to! Thank you!