Laying out your UI (HTML)

[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]

Learn about the layout of Windows Runtime apps and how they differ from traditional apps. You have a number of surfaces you can use in your Windows Runtime app, such as 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.

Windows: Resizing your UI

A user can resize your app so that they can use another app, or resize another app so they can use your app. You can design your app so that the content flows dynamically to optimize the experience when a user resizes your app.

	Full screen App fills entire screen.
	Resized App is resized to a portion of the entire screen. Other apps can fill the remaining screen area.

 

See UX guidelines for layout and scaling for more info.

Touch keyboard and handwriting panel

The touch keyboard (and the handwriting panel in Windows) provides a secondary command UI for text entry. This panel is displayed when a user touches an editable input field (or when they click the keyboard icon in the taskbar of the Desktop in Windows). The panel is dismissed when the input field loses focus.

The touch keyboard enables text entry and editing for tablets and phones—that is, form factors that don’t have a hardware keyboard or other peripheral keyboard device. The handwriting panel in Windows 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 or 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. On Windows Phone, the menu is hidden by default and it appears when the ellipsis is tapped. On Windows, the entire app bar is hidden by default and it appears when the user swipes in from the top or bottom edge of the screen. The app bar occludes the content of the app and can be dismissed by the user in the same way as it is shown, or by interacting with the app.

See Commanding design for more info on designing commands and Guidelines for app bars for user experience guidelines.

Windows: Charms

The charms are a specific and consistent set of buttons in every app: search, share, devices, 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 your app's content or for web content from anywhere in the system.
• 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 the user can perform on text or UI elements in an app. You can use up to five commands on each content menu, such as 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 a response.

In the Windows 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 in 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 Windows 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 (or banners)

A toast (also known as a banner on Windows Phone) is a notification that you show to users when your app is in the background. A toast is good for updating users with information they want to know in real-time, but it's ok if they miss. The user taps 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 (in Windows, they 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 correct 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 the user can. User interaction: The user 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 input box and then retypes it.	Text inline on the canvas Text only Dismissed by app Appears inline near the source of the error
A non-critical error that applies to the whole app. Your app cannot fix the problem, but the user can. User interaction: The user 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 Text only Dismissed by app Appears 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: The user 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 Text, two buttons Dismissed by the user Appears near the top of the page
A critical error that applies to the whole app and prevents the user from using the app. User interaction: The user cannot continue interacting with the app unless they dismiss the error. The user can still interact with system components and use other apps.	Message dialog Text, 1 to 3 buttons, title (optional) Dismissed by the user Appears centered across the app

 

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 Windows example shows an inline error message associated with a specific text input box.

 

Don't

Include actions or commands in the message.

 

In the following Windows example, an Error and Warning bar would be a better choice.

Errors: Error or warning bar

Use an Error or Warning bar to notify the user of important errors and warnings and to encourage them to take action. Error messages inform the user that a problem occurred, explain why it happened, and provide a solution so the user can fix the problem. Warning messages alert the 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 Windows 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 Windows example is an appropriate use of an error message dialog because the user 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 the user 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