Guidelines for snapped and fill views (Windows Store apps)

These guidelines help you design the UI of your Windows Store app so that it adapts well to the snapped and fill view states. A snapped app occupies a narrow region of the screen, while an app in the fill view fills the screen area not occupied by the snapped app.

Note  Snapped and fill views are only available on displays with a horizontal resolution of 1366 relative pixels or greater. This is because the snapped view is 320 pixels wide, and can be placed on either side of the screen. The remaining 1046 pixels are allocated to the splitter (22 pixels) and the fill view, which must always have a horizontal resolution of 1024 relative pixels or greater.

User experience guidelines

Because users can snap every app, you should design your app for the snapped view state. If you don't, the system resizes your app anyway and might crop your content or add scrollbars.

Here are some general principles you should follow:

• Maintain state and preserve continuity. Maintain the state in the snapped view, even if it means showing less content or reducing functionality. Prioritize maintaining state over showing the user a more attractive, but otherwise out-of-context, snapped page.
• Have feature parity across states. Remember that snapping is simply resizing your app. The user expects to be able to interact with your app when it is snapped. If you can't keep parity for a specific feature, we recommend that you include an entry point to the feature and programmatically unsnap the app when the user triggers that entry point.
• Use media queries for your layout logic. This allows your application to respond appropriately when your application layout changes. To learn more, see Media Queries and -ms-view-state media feature.
• Use application view API. This ensures your app is notified of layout changes, especially during app launch and relaunch from a suspended state. To learn more, see ApplicationView.
• Put the user in control. Don't programmatically unsnap your app to get the user's attention. Unsnapping should be reserved only for situations when the user tries to use a feature that is not available in the snapped state. If your app has snapped views for all pages in the app, you shouldn't need to programmatically unsnap at all.
• Don't add UI controls to programmatically unsnap your app. The splitter between the apps is always present and lets the user unsnap whenever they want to.

Remember, the snapped app is your app resized! It is not a gadget or a minimized window. You want to maintain state, context, and interactivity for your users. Snapping and unsnapping should never destroy the user's work or state.

This image shows an app going from full-screen to snapped view.

When should you use media queries and when should you use JavaScript layout change events?

Snapped layouts

Planning direction Take advantage of the snapped layout's "tall and skinny" aspect ratio to pan vertically. If your app changes panning direction between snapped and fullscreen or fill states, make sure it is clear in the UI that the panning direction has changed.

Column layouts Given the narrow width of the snapped state, we recommended that you change multi-column layouts to a single column layout when the app is snapped. The following example has a multi-column layout in its unsnapped state. When the app is snapped, elements of the layout are stacked to create a single column layout.

View State and Window Dimensions

Depending on the needs of your app, you can base your app's UI layout on view states, the app's window dimensions, a combination of view states and window dimensions, or neither.

View states give you high-level information about the "shape" of the app and context around the app. Window dimensions give you finer control over the layout of UI elements, which is useful if specific widths and heights matter for how elements are laid out.

Whether you use view states or window dimensions depends on how your app "treats" its content, as described in the following sections:

Completely fluid content The app content flows off the screen horizontally, adding more rows if there is sufficient height.

For fluid content, the width of the screen and the window dimensions don’t matter for layout purposes. However, you might need the view state to determine whether the app is snapped so you can convert content for vertical panning.

Shape dependent The app lays out UI elements based on the "shape" of the app, regardless of its exact dimensions. For example, the app might stack UI elements when the app is taller than it is wide. The view state gives sufficient information for this scenario.

Exact dimensions matter The app has optional UI that appears only when there is sufficient space. For example, a social networking site might show a real-time news feed only when there is enough width.

When exact dimensions matter, the view state alone doesn’t give enough information to determine whether to show the optional UI. The fill state might be wide enough to show the optional UI, or the full screen state might not be wide enough. In cases like these where exact widths matter, use window dimensions to lay out your app.

Full screen matters The app needs to know whether it has all of the pixels on the device screen. For example, a game might place controls at the sides when it is full screen, and reposition them at the bottom when not full screen.

Window dimensions don’t tell you whether your app is full screen. You’ll need to get the fill view state to determine how to position controls.

Hands-on labs for Windows 8

If you’d like to try working with snapped and fill view states and other key Windows 8 features, download the hands-on labs for Windows 8. These labs provide a modular, step-by-step introduction to creating a sample Windows Store app in the programming language of your choice (JavaScript and HTML or C# and XAML).

Related topics

Quickstart: Defining app layouts

Guidelines for layouts

Build date: 11/28/2012