[This documentation is preliminary and is subject to change.]
You have a number of surfaces you can use in your Metro style app, like the app window, pop-ups, dialogs, and 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 window, or canvas
The app window, 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.
The app bar
Outside of the app window, 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.
The 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.
- Start Users can go directly to the Start screen.
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.
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.
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.
Toasts
Toasts are notifications that you show to users when your app is in the background. Toasts are great at 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.
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.
Build date: 5/22/2012
