Learn about the layout of Windows Store apps and how they differ from traditional desktop apps. You have a number of surfaces you can use in your Windows Store app, like the app window, flyouts, dialogs, and app bars. Choosing the right surface at the right time can mean the difference between an app that is a breeze to use or a burden.
The app page, or canvas
The app page, sometimes called the canvas, is the base of your UI. The canvas holds all of your content and controls. Whenever possible, you should integrate your UI elements into this base surface. For example, instead of using a pop-up to display an error, you can smoothly show, hide, or shift the error message on the window with the built-in animations. Presenting your UI inline lets users fully immerse themselves in your app and stay in context.
You can create as many app pages as you need to support your user scenarios. See Planning Windows Store apps and Navigation design to learn more about laying out app pages to support user scenarios.
View states
People can snap your app so that they can use another app, or snap another app so they can use your app. You can design your app so that the content flows dynamically to optimize the user experience in each view state: full screen, snapped, or fill.
 |
Full screen view App fills entire screen. |
 |
Snapped view App is snapped to a narrow region of the entire screen. |
 |
Fill view App fills remaining screen area not occupied by the app in the snapped state. |
See Guidelines for snapped and fill views for more info on supporting these view states.
Touch keyboard and handwriting panel
The touch keyboard and handwriting panel provide a secondary command UI for text entry. This panel is displayed when a user touches an editable input field in a Windows Store app or when they click the keyboard icon in the taskbar of the Desktop. The panel is dismissed when the input field loses focus.
The touch keyboard enables text entry and editing for form factors that don’t have a hardware keyboard or other peripheral keyboard devices. The handwriting panel enables text entry and editing for pen-based form factors.
Similar to the view states mentioned previously, you can design your app so that the content flows dynamically to optimize the user experience when the touch keyboard and the handwriting panel are displayed.
See Guidelines for touch keyboard and handwriting panel for more info on supporting these text input modes.
App bars
Outside of the app page, the app bar is the primary command interface for your app. Use the app bar to present navigation, commands, and tools to users. The app bar is hidden by default and appears when users swipe a finger from the top or bottom edge of the screen. It covers the content of the app and can be dismissed by the user with an edge swipe, or by interacting with the app.
See Commanding design for more info on designing your command and Guidelines for app bars for user experience guidelines
Charms
The charms are a specific and consistent set of buttons to users in every app: search, share, connect, settings, and start. We believe these are core scenarios that every user wants to do in almost every app they use.
- Search Users can search for content located your app or in another app, and they can search your app's content from another app.
- Share Users can share content from your app with people or services.
- Devices Users can connect to devices and send content, stream media, and print.
- Settings Users can configure your app to their preferences and access user help.
- Start Users can go directly to the Start screen.
See these guidelines for more info: search, sharing, app settings, and app help
Context menus
The context menu, sometimes called a popup menu, shows actions that users can perform on text or UI elements in an app. You can use up to five commands on each content menu, like cut, copy, or open with. This limit keeps the context menu uncluttered, easy-to-read, and directly relevant to the text or object that the commands act on.
Don't use context menus as the primary command interface for an app. That's what the app bar is for. See Guidelines for context menus for more info.
Message dialogs
Message dialogs are dialogs that require explicit user interaction. They dim the app window and demand a user response before continuing. Use message dialogs only when you intend to stop the user and to demand response.
In the example above, the app window is dimmed, and the user must tap one of the two buttons to dismiss the dialog. That is, the message in the dialog cannot be ignored.
See Guidelines for message dialogs for more info.
Flyouts
Flyouts show temporary, dismissable UI related to what the user is currently doing. For example, you can use flyouts to ask the user to confirm an action, to show a drop-down menu from a button the app bar, or to show more details about an item. Flyouts are different from message dialogs in that you should show a flyout only in response to a user tap or click, and you should always dismiss the flyout when the user taps outside of it; you should show a message dialog only when you need to interrupt the user and demand some kind of interaction.
In the example above, the app stays active, and the user can tap the button or tap outside the flyout to dismiss it. That is, the message in the flyout can be ignored. See Guidelines for Flyouts for more info.
Toasts
Toasts are notifications that you show to users when your app is in the background. Toasts are good for updating users with information they want to know in real-time, but it's ok if they miss. Users tap on the toast to switch to your app and learn more.
Be aware that people can find toast notifications disruptive and annoying, so be thoughtful about when you want to show a toast to users. See Guidelines for toast notifications for more info.
Tiles
 |
Tiles appear on the Start screen and replace the application shortcuts that would have appeared on the desktop screen and in the old Start menu. People tap your app's tile to launch your app.See Guidelines for tiles for more info. |
Errors
Errors within an app can be communicated to the user through three main surfaces. The right surface for an error is chosen by the app developer based on the content and consequences of the error.
| To show: | Use this surface: |
|---|---|
|
A non-critical error specific to an element in the app. Your app cannot fix the problem, but users can. User interaction: Users can continue to interact with the app, system components, and other apps without dismissing the error. Example: The user enters an invalid string in a text box and then retypes it. |
Text inline on the canvas
|
|
A non-critical error that applies to the whole app. Your app cannot fix the problem, but users can. User interaction: Users can continue to interact with the app, system components, and other apps without dismissing the error. Example: Mail cannot sync at the moment. |
Text at the top of the page
|
|
A significant but non-critical error that applies to the whole app and your app can suggest a solution. User interaction: Users can respond to your prompt or continue to interact with the app, system components, and other apps without dismissing the error. |
Error and warning bar
|
|
A critical error that applies to the whole app and prevents the user from using the app. User interaction: Users cannot continue interacting with the app unless they dismiss the error. Users can still interact with system components and use other apps. |
Message dialog
|
Do not use flyouts, toasts, or custom UI surfaces to display errors.
Errors: Inline text
In general, the inline error is the first choice of surface. An inline text error delivers messages in the context of the user's current actions or the current app page itself. An inline error does not require an explicit user action to dismiss the message. The message goes away automatically when it no longer applies.
| Do | Align the message with the control or element that the message relates to. |
| Lay out the message with ample surround space to increase its focal strength. |
The following example shows an inline error message associated with a specific text box.
| Don't | Include actions or commands in the message. |
In the following example, an Error and Warning bar would be a better choice.
Errors: Error or warning bar
Use a Error or Warning bar to notify users of important errors and warnings and to encourage the user to take action. Error messages inform users that a problem occurred, explain why it happened, and provide a solution so users can fix the problem. Warning messages alert a user of a condition that might cause a problem in the future.
| Do | Position the bar at the top of the screen, encouraging the user to notice and take action. |
| Color the bar with a color from the app's palette. | |
| Use the same color and layout for all your error and warning bars. |
| Don't | Display bars with different colors or glyphs (such as a shield or exclamation point) based on perceived severity. |
| Use an 'X' glyph to close the bar; instead, use a labeled Close button. | |
| Use an error and warning bar for information-only message. |
The message in the example below is purely informational and no action is required. In this case, an inline message at the top of the screen should have been used.
Errors: Message dialogs
Use a message dialog only if a modal message is required, blocking the user from interacting with the app.
| Do | Use a message dialog if the user must take action before using the app any further. |
The following example is an appropriate use of an error message dialog because users cannot use the app unless they have an active account.
| Don't | Use a dialog if the user can ignore the message. |
In the following example, there is nothing about the error that would require you to block users until they address it. An error or warning bar would have been a better choice.
Related topics
- Guidelines for app bars
- Guidelines for app settings
- Guidelines for search
- Guidelines for sharing content
- Guidelines for Flyouts
- Guidelines for message dialogs
- Guidelines for context menus
- Guidelines for splash screens
- Guidelines for app help
Build date: 11/28/2012
