Guidelines for app bars (Windows Store apps)
Follow these guidelines when working with app bars for Windows Store apps.
App bars provide the user with easy access to commands when they need them. The user can swipe the 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.
If you have a command that is necessary for a user to complete a workflow (such as buying a product), place those commands on the canvas instead of in app bars.
Follow these guidelines when placing your commands on the app bar.
- Do separate distinct command groups on opposite sides of 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.
- Do keep 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.
- Do 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.
- Do 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.
- Do set the app bar's dismissal mode to sticky when displaying contextual 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 people select an image, but you want to let people 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.
- Do use menus and flyouts when you have too many commands.
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.
Don't create a menu such as "More" or "Advanced" for unrelated, miscellaneous commands. These types of generic commands tend to make an app feel more complicated, and only a small subset of users explore these menus. If you find yourself needing an overflow and there aren't any logical groupings available, consider simplifying your app.
- Do 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.
- Do design for horizontal scrolling.
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.
- Do use the default styles for commands, menus, and flyouts.
People get used to button placement and sizes, so if you want to customize an app bar, we recommend customizing the colors of the background, icons, and labels, but not the size or padding of the buttons. The default layout is designed to support touch and to fit ten commands on all supported screen widths. Making changes to the layout may result in undesirable behavior.
- Do use the built-in icons for commands.
See the list of icons available for use in the AppBarIcon enumeration.
- Don't put critical commands on the app bar.
Don't place commands that are core to what makes an app great 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.
- Don't put clipboard commands for text on the app bar.
Place Cut, Copy, and Paste commands in a context menu on the app page rather than in an app bar.
- 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.
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 row||Number of full-sized buttons with labels in a single row|
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 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.
- If there are regions of the DirectX surface that don't need app-specific contextual right-click actions, like border menus, show the app bar when the user right-clicks these regions.
- If right mouse button support is needed everywhere on the canvas, 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, place a custom control on the DirectX surface to enable mouse gestures to open the app bar.
- Use the MouseDevice class events, like MouseMoved, to implement your own context menu behaviors.
- If your app supports touch controls, remember that a long press, or press-and-hold, is the same as a right mouse 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 the GestureSettings property to support holding with touch and pen and stylus input. To enable holding behavior with a mouse, set HoldWithMouse in the GestureSettings property.
- Don't provide an alternate behavior for the Win+Z keypress combination in your app. Develop an app bar or similar context menu, and display it when the user presses the Windows key in conjunction with the Z key. Register for the KeyDown and AcceleratorKeyActivated events to determine when these two keys have been pressed.
- Quickstart: Adding an app bar (C#, C++, VB)
- Adding context menus
- Commanding design
- Making the app bar accessible
- Navigation design
Build date: 12/16/2013