Pivot control design guidelines for Windows Phone
[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]
The Pivot control provides a quick way to manage the navigation of views within an app. The control places individual views horizontally next to each other, and manages the left and right navigation. Flicking or panning horizontally on the page cycles the pivot functionality.
The content of the page inside the Pivot control is defined by the app.
.png)
This topic contains the following sections.
- Appearance and action
- Detailed description
- Standard use
- Design guidelines
- Related Topics
Appearance and action
A Windows Phone pivot app provides a quick way to manage views or pages. It can be used for filtering large datasets, viewing multiple data sets, or switching app views. For example, flicking or panning left to right on the page advances to the next page of content.
The Pivot control comes with built-in support for touch interaction and navigation. You don’t have to implement any special gesture functionality in your app because it’s enabled by default. The Pivot control supports the following gestures and navigational effects:
Horizontal pan (tap and drag left/right)
Horizontal flick (tap and swipe quickly left/right)
Navigating hosted controls—for example, links can be tapped and lists can be scrolled
.png)
Detailed description
At the base of an app is a Pivot control that is essentially a container for a secondary control called a PivotItem control. PivotItem controls contain individual page content such as controls, grids, or links inside each page. You can use the designer or programmatically work with these elements. For more info about the Pivot control architecture, see Pivot control architecture for Windows Phone 8.
.png)
Standard use
Use this control for filtering large datasets, viewing multiple data sets, or switching application views. Your app can look and react like the integrated Windows Phone pivot experiences.
Design guidelines
The following are general best practices for using a Pivot control to create a pivot experience.
Never place a Pivot control inside another Pivot control. Never place a Pivot control inside a Panorama control.
You can, however, have an element in a Panorama control link to a Pivot control and vice versa.
Apps should minimize the number of pivot pages (four pages or fewer). Users can become lost if they jump from pivot page to pivot page. Use Pivot controls sparingly and limit the use of pivot pages to scenarios where it’s appropriate for the experience.
The Pivot control shouldn’t be used for task flow (exposing radically different tasks). Different pages should flow seamlessly (look and feel), and changes shouldn’t change the user’s activity drastically (for example, one page to filter mail and another to view pictures).
The Pivot control should be used only to display items or data of similar type (for example, filtered views of the same data).
Consider that pivot pages are cyclical. After reaching the last pivot page, the next page to display if the user continues to swipe will be the first pivot page. Use this behavior to create a seamless flow between pivot page options and content.
The pivot header is a fixed height and can’t be changed.
An empty pivot page should be removed only when there’s no chance that additional info can be added to the page by user action. (For example, if the Unread Email pivot page had no items to display, don’t remove the Unread Email pivot page. Instead, provide placeholder text or an image that shows some contents will be placed on the page when data is available or simply to indicate to the user that the pivot page is "empty.")
We recommend that you limit pivot header text to a maximum of one or two words, both to provide the user a visual clue about the existence of the next pivot pane and to help with localization.
Don’t use Slider, ToggleButton, or Map controls in a Pivot control. Don’t use controls that can pan or scroll inside a Pivot control. For example, if you put a Map control inside a Pivot control it might be difficult to use the Pivot control. The gesture input gets confused. For example, if you have a slider and try to slide it left, it’s unclear if you want to scroll the map or if you want to move the slider or if you want to go to the next pivot page. The solution is to navigate to a subpage with controls that require gesture input. You can place a map in a pivot page 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 Pivot control.
Never use an edit control within a pivot. Doing this interferes with the left-to-right flick and pan gesture interactions.