Appearance and action

Panoramic experiences are a part of the native Windows Phone look and feel. Unlike standard apps that are designed to fit within the confines of the phone screen, panoramic apps offer a unique way to view controls, data, and services by using a long horizontal canvas that extends beyond the confines of the screen. These inherently dynamic views use layered animations and content so that layers smoothly pan at different speeds, similar to parallax effects.

Elements of a panoramic app serve as the starting point for more detailed experiences. Your goal should be to give users a visually rich content presentation.

Detailed description

The user interface consists of layer types that operate with their own independent motion logic: a background image, a panorama title, panorama section titles, and panorama sections. Thumbnails complete the experience and are a main element of the panoramic view. They link to content or media that’s consumed outside the panoramic experience.

The background image is the lowest layer and is meant to give the panorama its rich, magazine-like feel. Usually a full-bleed image, the background is potentially the most visual part of the app.

The panorama title is meant to identify the app and should be visible no matter how the user enters the app.

Panorama sections are the component of the panoramic app that encapsulates other controls and content. Panorama sections move at the same rate as the finger pan or flick.

A panorama section title is optional for any given panorama section.

Thumbnails can be a main element of the panoramic view. They link to content or media that’s consumed outside the panoramic experience.

Panorama control with thumbnails

Standard use

A panorama experience consists of a Panorama control and one or more PanoramaItem controls. The Panorama control serves as the base for the app, and the PanoramaItem controls host individual content sections. Based on the requirements of the app, you can add multiple PanoramaItem controls to the Panorama control surface with each offering a distinct functional purpose. For example, one PanoramaItem may contain a series of links and controls, while another is a repository for thumbnail images. A user can pan back and forth through these sections using the gesture support already provided by the panorama app.

Design guidelines

General Guidelines for Panoramas:

The Panorama control wraps from the last section to the first section and vice versa. Use this effect to properly design the flow of your app.

If you use an App Bar in your Panorama, set the Mode to Minimized. This mode is designed specifically to maximize screen space on a Panorama page. For more info, see App bar for Windows Phone.

For performance reasons and also to limit the number of views that the user has to navigate through, you shouldn’t have more than five sections in a Panorama control. Fewer sections should be used when the contents are more complex. Don’t overwhelm the user with lots of sections. With just four or five sections, users can get their bearings as to where they are and what’s to the left and right.

The Panorama control is portrait orientation only. There is no landscape support for the Panorama control. Dialogs launched from within the Panorama control shouldn’t be rotated to avoid jarring experiences.

The Panorama control can show a progress bar in the System Tray or a full-screen “loading” indicator on launch. A progress bar in the System Tray is shown when a section of a Panorama control is being updated or refreshed but isn’t blocking user interaction.

First visit: the first section shown should have the Panorama control title correctly aligned on the left. There is no standard guidance for which section is the default; it depends on the content being presented.

For subsequent visits, the user should be taken back to the pane where they left off when user revisits the same Panorama control.

Don’t use Pivot controls inside Panorama controls or vice versa. You can, however, link items in a Panorama control section that takes the user to a Pivot control.

Don’t use controls that can pan or scroll inside a Panorama control. For example, putting a Map control inside a Panorama control section can make it difficult to use the Panorama control. The gesture input gets confused. For example, if you have a slider and try to slide it left and you’re in a section of a Panorama control, it’s unclear if you want to scroll the section or if you want to move the slider. The solution is to navigate to a single subpage with controls that require gesture input. You can place a map in a section of a Panorama control as long as the map isn’t enabled for gesture interaction. You could overlay a button that would activate the map. Pressing the button would actually navigate to a separate page with just the Map control on it. The user could then press the Back button to go back to the Panorama section.

For more guidance about when to use a Panorama control versus a Pivot control, review the following topics:

Use either plain text or images, such as a logo, for the Panorama title. You can also use multiple elements, such as a logo and text (or other UI elements).

Ensure that the font or image color for the title works across the entire background and that it isn’t dependent on the background image for visibility. Use the system fonts and styles unless there’s a need for a specific branded experience that uses a different font, size, or color.

Use the same Panorama title for the launch Tile in Start for consistency.

Use a rate of motion for the Panorama title that’s slow relative to the topmost content layer, and slower than the background art.

For Panorama Section Titles:

Use plain text for Panorama section titles. Alternatively, you can use images. You can use multiple elements, such as an image and text (or other elements in the UIElement class).

Ensure that the Panorama section title isn’t dependent on the background art.

Avoid animated Panorama section titles because the title will be moving.

Span the entire Panorama section with Panorama section titles, even if multiple controls are present.

Animate Panorama section titles off the screen when a user navigates to a new section.

A Panorama section title should act differently depending on whether the section’s width is greater than or less than the width of the screen. If the section’s width is greater, there should be a horizontal animation—the title shouldn’t stay in the top left of the section, but rather it should move at a different speed along the top while the Panorama is moving. Under these circumstances, there shouldn’t be vertical scrolling. Alternatively, if the section’s width is less than the screen width, the title should always be set to the top left of the section. Under these circumstances, there shouldn’t be any horizontal animation, and the title should move along with the content.

For Panorama Sections:

Vertical scrolling through a list or grid in Panorama sections is acceptable as long as it’s within the confines of the section and isn’t in parallel with a horizontal scroll.

Animate Panorama sections off the screen when a user navigates to a new section.

Panorama controls can be themed, and the app Branding color can override the system theme.

Be careful about including embedded text and logos within the Panorama control title because there may be overlapping or occlusion problems with the System Tray or other elements.

Keep the beauty of the Panorama control experience intact by being selective about the text and images included in the content so that it doesn’t become overwhelming and busy.

Use dark, soft, and low-contrast backgrounds. One practical technique is to use a semi-transparent black or white filter (a rectangle) on top of the background image to improve text legibility. This could be done in a bitmap editing tool or overlaid on top of the background image using a rectangle control.

Preferably, use a single image as the background of a Panorama control.

Use either a single-color background or an image that spans the entire Panorama control. If you decide to use an image, most UI image types are supported. However, JPEGs are recommended, because they generally have smaller file sizes than other formats.

You can use multiple images as a background, but note that only one image should be displayed at any given time.

Background images should be between 480 x 800 pixels and 1024 x 800 pixels (width x height) to ensure good performance, minimal load time, and no scaling.

For Thumbnails:

Use cropped images that highlight an identifiable subject rather than an entire image. If the image isn’t identifiable without text, up to two lines of text can be used to identify the content.