Pivot Control Design Guidelines for Windows Phone
March 22, 2012
The Pivot control provides a quick way to manage the navigation of views within an application. 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 application.
A Windows Phone pivot application provides a quick way to manage views or pages. It can be used for filtering large datasets, viewing multiple data sets, or switching application 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 do not have to implement any special gesture functionality in your application because it is 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
At the base of an application 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 information about the Pivot control architecture, see Pivot Control Architecture for Windows Phone.
The following are general best practices for using a Pivot control to create a pivot experience.
-
Never place a Pivot control inside of another Pivot control. Never place a Pivot control inside of a Panorama control.
-
You can, however, have an element in a Panorama control link to a Pivot control and vice versa.
-
Applications should minimize the number of pivot pages (six 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 is appropriate for the experience.
-
The Pivot control should not be used for task flow (exposing radically different tasks). Different pages should flow seamlessly (look and feel), and changes should not 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. Leverage this behavior to create a seamless flow between pivot page options and content.
-
The pivot header is a fixed height and cannot be changed.
-
An empty pivot page should be removed only when there is no chance that additional information can be added to the page by user action. (For example, if the Unread Email pivot page had no items to display, do not 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 to provide the user a visual clue about the existence of the next pivot pane as well as to help with localization.
-
Don’t use Slider, Toggle, or Map controls in a Pivot control. Don’t use controls that can pan or scroll inside a Pivot control. For example, putting a Map control inside a Pivot control can make it 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 is 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 sub-page with controls that require gesture input. You can place a map in a pivot page as long as the map is not 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.
