Guidelines for app bars

A sample of what a standard navigation bar control looks like

A sample of what a standard app bar control looks like


App bars provide users with easy access to commands when they need them. Users can swipe the top or bottom edge of the screen to make app bars appear and can interact with their content to make app bars disappear. App bars can also be used to show commands or options that are specific to the user's context, such as photo selection or drawing mode. They can also be used for navigation among pages or sections of the app.

Explore navigation functionality in more depth as part of our App features, start to finish series:  Flat navigation, start to finish (HTML and XAML) and Hierarchical navigation, start to finish (HTML and XAML)

If you have commands that are necessary for a user to complete a workflow (such as buying a product), place those commands on the canvas instead of in app bars.

Top app bar

The navigation bar, or top app bar, is the recommended place to put navigation controls that let the user access other areas of the app. By using the top app bar for navigation, you provide a consistent and predictable user experience for navigating Windows Store apps. Consistency gives users the confidence to move around the system and helps them transfer their knowledge of app navigation from app to app.

Users should be able to complete core scenarios just by using the canvas. The navigation bar is a secondary location for navigation controls. The navigation bar can help orient the user to all parts of an app, can provide quick access to the home page, or can encourage users to explore by jumping to different parts of the app.

You can also choose to include other functionality within the top app bar, such as adding a '+' button to create something new or integrating a search box. When you add other functionality, we recommend that you place these on the right side of the app bar.

While you can style items in the nav bar, the default appearance is a simple button. However, another typical visual treatment is the use of button and thumbnail, as shown in the previous image.

You can also divide the nav bar into multiple areas, as the Store app does. Here you can see that the top section is for global navigation and the bottom section is for app categories.

Image of nav bar of the Store app

Bottom app bar

The bottom app bar is the recommended place to put commands. By moving commands from the app canvas to the app bar, you deliver the most immersive experience possible to the user.

The standard app bar control is intended for the developer who is interested in implementing an app bar with little to no custom work. While it is easy to create an app bar, it is not easy to ensure that it behaves in accordance with Windows guidance and patterns. The CommandBar class and WinJS.UI.AppBar object are made to align with the intended design and behaviors so the developer doesn't have to think about every little detail, and will be less likely to diverge on the common commanding pattern.

If you want to depart from the standard experience and customize your app bars, use the AppBar control instead of the CommandBar control in XAML.

You can use the built-in icons for commands or you can create your own. For the list of icons that are available, see:


Top app bar

A screenshot that illustrates the standard navigation bar control


Bottom app bar

A screenshot illustrating the standard app bar control

Dos and don'ts

  • Separate navigation and commands. Ideally, put commands in the bottom app bar and navigation in the top app bar. Consider providing help the first time that an app runs to let users know the important commands that are in the app bar.

  • If you have distinct sets of commands (such as a set for creating new content, and a set for filtering your view), place one set on the right side and one on the left side of the app bar. If you have more than two sets, separate the sets with a separator.

  • Place commands in a consistent location throughout the app. While each page should only contain the commands that are relevant to that page, if any commands are shared between them, they should be as close to the same location as possible, so that users can predict where the commands will be.

  • Follow placement conventions:

    • Place the New/Add/Create button (+ icon) on the far right.
    • Group view switching buttons together and place them on the far left.
    • Place Accept, Yes, OK commands to the left of Reject, No, Cancel commands.
  • Show commands contextually on an app bar when an item is selected, and show the app bar automatically. Most people are right-handed, so when people select an item on the app page, show whatever commands are relevant to that item on the left side of the app bar. That way, their arms or hands won't block their view of the commands.

  • If you have contextual commands on an app bar, set the mode to sticky while that context exists so that the bar doesn't automatically hide when the user interacts with the app. Turn off sticky mode when the context is no longer present. For example, you might want to show contextual commands for photo manipulation when a user selects an image, but you want to let the user keep working with the image, like rotating or cropping the image. In this case, the bar stays visible until the user deselects the image or dismisses the app bar with an edge swipe.

  • If you are unable to fit all of your commands in an app bar as separate buttons, group like commands together and place them in menus that people can access from app bar buttons. Use logical groupings for the commands, such as placing Reply, Reply All, and Forward in a Respond menu.

    Image of a flyout and a menu

  • Design your app bar for resized and portrait views. If you have ten commands or fewer, Windows automatically hides labels and adjusts padding for you when people resize your app or rotate to portrait view, so provide tooltips for all your commands. If you want a more custom view, you can either group commands together into menus or provide a more focused experience that requires fewer commands in resized or portrait view.

    In JavaScript apps, it's a good idea to place global commands before contextual commands in the DOM in order to get the best layout when people resize your app. For more info, see Adding an app bar with commands and Styling app bars.

    In C#/C++/VB apps, resizing is handled for you if you use the CommandBar control. For more info, see How to use an app bar at different sizes.

  • If your app has a horizontal scrolling area at the bottom of the app page, reduce the height of the scrolling area when the app bar appears in sticky mode. Otherwise, the app bar can cover up your scrollbar and people might need to go out of their way to dismiss the app bar in order to keep scrolling. You should try to keep the bottom edge of scollbar flush against the top edge of the app bar.

  • Don't put critical commands on the app bar. For example, in a camera app, place the "Take a picture" command on the app page rather than in an app bar. You could either add a button to the app page or simply let people tap the preview to take the picture.

  • Don’t put login, logout, or other account management commands in the app bar. All account management commands, like login, logout, account settings, or create an account should go in a Settings flyout. If it's critical that people log in on a particular page, provide the login button on the app page. For more info, see Guidelines for login.

  • Don't put app settings in the app bar. All app settings commands, like defaults and preferences, should go in a Settings flyout. The Settings flyout is also the best place for seldom used management commands, like those for clearing history.

Additional usage guidance

Scaling for different window sizes

When people resize a window with an app bar, the system resizes the commands and might drop labels. When reduced-sized commands no longer fit on a single row in the screen, the system wraps them to a second row.

  • Design at least two views of the app bar, one full size and one reduced size (either at 500px or 320px minimum). Most people only use common window sizes, either fullscreen or 50/50 with another app.
  • Group commands when designing smaller views. If you can't meaningfully group commands, place them in a "more" group using the ellipses icon.
Common window resolutions (in pixels)Number of reduced-sized buttons with no labels in a single rowNumber of full-sized buttons with labels in a single row


Handling the right mouse button

To keep your app's UI consistent with other Windows Store apps, users must click the right mouse button to trigger the app bar that you provide. If you have an app that must use the right mouse button for another purpose, like secondary fire in a game or a virtual trackball in a 3-D viewer, the app can ignore the events that raise the app bar. But you should still consider the role of the app bar, or a similar context menu, in your game's control model, because it's an important part of the Windows Store apps experience.

Follow these guidelines when designing the controls for your app:

  • If your app needs to use the right mouse button for an important function, use it for that function directly. Don't activate any contextual UI or the app bar if it isn't important to workflow.
  • Show the app bar when the user right-clicks regions of your app that don't need contextual right-click actions, such as border menus.
  • If right mouse button support is needed everywhere, consider showing the app bar when the user right-clicks the top-most horizontal row of pixels, the bottom-most horizontal row of pixels, or both.
  • If none of these solutions suffice, use custom user interaction controls to open the app bar with the mouse.
  • Use the MouseDevice class events, like MouseMoved, to implement your own context menu behaviors.
  • Remember that the press-and-hold touch gesture is the same as a right button click. Handle both events in a similar way. To handle this event and define a custom behavior for it, register for the Holding event. To enable holding, set Hold (for touch and pen input) and HoldWithMouse in the GestureSettings property.
  • Don't change the behavior of the Win+Z key combination. Your app should display the app bar or a context menu. Register for the KeyDown and AcceleratorKeyActivated events to determine when these two keys have been pressed.

Details on sizing, padding, scaling, and transparency for Windows Phone Store apps:  

Provide the scale-240 asset at a minimum for a Windows Phone Store app; preferably scale-140 and scale-100 also.

Assets used in a bitmap icon (see BitmapIcon for XAML apps) in an app bar button should have a transparent background; they essentially function as opacity masks and they work with both dark and light theme.

Asset to be used in a bitmap icon<assetname>.scale-100.png<assetname>.scale-140.png<assetname>.scale-240.png

asset 32x32px

padding 7,7px

icon 18x18px

asset 45x45px

padding 10,10px

logo 25x25px

asset 77x77px

padding 18,18px

logo 41x41px


Related topics

For designers
Command patterns
Navigation patterns
Making the app bar accessible
For developers (HTML)
WinJS.UI.AppBar object
WinJS.UI.NavBar object
HTML AppBar control sample
HTML NavBar control sample
Navigation and navigation history sample
Your first app - Part 3: PageControl objects and navigation
Adding app bars
Adding nav bars
Navigating between pages (HTML)
For developers (XAML)
Windows.UI.Xaml.Controls AppBar class
Windows.UI.Xaml.Controls CommandBar class
XAML AppBar control sample
XAML Navigation sample
Your first app - Part 3: Navigation, layout, and views
Your first app - Add navigation and views in a C++ Windows Store app (tutorial 3 of 4)
Adding app bars (XAML)
Navigating between pages (XAML)
For developers (Windows Runtime apps using DirectX with C++)
Creating an app bar or Setting



© 2015 Microsoft