Guidelines and checklist for app bars (Windows Store apps)
Follow these guidelines when working with app bars for Windows Store apps.
Roadmap: How does this topic relate to others? See:
- Roadmap for Windows Store apps using C# or Visual Basic
- Roadmap for Windows Store apps using C++
- Windows Store app UI, start to finish, highlighted in our App features, start to finish series
User experience guidelines
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 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.
Guidelines for commands in the app bar
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 snap and portrait view.
Make sure your app bar commands show correctly in snap and portrait views.
For more info, see How to use an app bar in different views.
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 scrollbar 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.
For more info, see Quickstart: Styling app bar buttons.
Do use the bottom app bar for commands and the navigation bar for navigation.
In general, use the bottom app bar for commands that act on the current page. Use the navigation bar for navigational elements that move the user to a different page.
Do use the built-in icons for commands.
For more info, see Quickstart: Styling app bar buttons.
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.
Handling the right mouse button
To keep your app's UI consistent with other Windows Store apps, users 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 app 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 Microsoft 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.
- When using touch, 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.
Build date: 12/12/2013