Navigation, orientation, and gestures (Windows Phone Store apps)
Windows Phone apps are based on a model where users can navigate forward through different views of content using links, and move backward using the hardware Back button. The goal of this model is to make it easier to create view-based apps that fit naturally into the Windows Phone page navigation model.
The page navigation model is a hub and spoke system. This means that unless you explicitly add links to other pages within your app, users must use the Back button to navigate back to a page that they viewed. This is similar to how a web browser displays and navigates webpage history.
The system tracks each page that a user has visited and places it in what is called the back stack so that when a user pushes the Back button, the last saved page in the back stack is served. There's no limit to the number of pages that can be placed in the back stack.
For example, this means that a user navigating from page 1 (p1) to page 2 (p2) to p1 to p2 to page 3 (p3) to p1 creates a back stack of p1, p2, p1, p2, p3, p1. If the user modified content in the second instance of p2 in the back stack, but navigates back using the Back button to the first instance of p2 in the back stack, previous changes don't appear on that page unless the page refreshes the data; the view is a snapshot of how the user saw that page at that point in navigation.
Important Note: Think carefully about implementing page-to-page links or buttons that could affect app navigation for the user and consider whether a page should be refreshed on entry.
The following are definitions in the context of the app page model for Windows Phone:
- Page: A user-recognizable collection of persistent state. It can be viewed as a page that contains info, memorable content, or links to other pages.
- Screen: A general UI screen such as a pop-up window, dialog box, or splash screen that doesn't contain memorable content. It isn't a user-recognizable collection of persistent state.
The following figure illustrates a hypothetical app structure with an assortment of pages and screens.
Sample app structure
An app may consist of the following pages:
- Home page
- Widgets page
- Widgets details page (containing pivots)
- Gadgets details page
- Search page
- Settings page
The splash screen and login screen aren't pages, because the definition requires a page to have a user-recognizable collection of persistent state; splash screens are simply used as a placeholder before your app is started. For more info about splash screens, see Essential graphics, visual indicators, and notifications for Windows Phone.
A login screen is also likely not to contain state data because it asks only for credentials to be entered (an exception is if you decide to remember the most-recently entered username).
Important Note: Not every view in Windows Phone requires a page.
To help decide whether your UI should be a page, consider the following questions:
- Would the user explicitly want to visit the page?
- Would the user remember being on this page and want to return to it?
Pages hold discrete sections of content in apps and appear as separate screens to the user. You can create as many different pages as needed and construct their UI to present content within an app and then provide navigation to those pages from the frame or page if you like. A simple app may require only one page; a more complex app may require many pages.
You can also implement a full-screen view where the Status bar or bottom app bar can optionally be displayed, but this must be explicitly defined using the visibility property, because the default is to not display them. The best practice for a full-screen view is to not display either so that users can focus on the content experience. Notifications and incoming calls are still displayed in full-screen mode, even if the Status bar or the app bar (or both) is hidden. For more info about the Status bar and app bar, see Essential graphics, visual indicators, and notifications for Windows Phone.
Note Using the full-screen view setting will result in the user not having access to the clock. We recommend that you avoid using the full-screen view unless the content requires it.
Navigation in Windows Phone can be defined as a transition between pages.
However, not every transition step is considered to be true navigation—for example, when you move from the splash screen to the home page. Leaving a non-page can be referred to as a transition.
The following section provides the best practices for using an effective page model.
Screens and non-navigational transitions
For transient UI, such as the login screen, you can use the popup or flyout control to display content that partially covers the screen without implementing separate screens that would require full navigation. You can add the BackKeyPress event to your code and set e.Cancel to true while the pop-up window is visible to enable users to use the Back button to close the dialog box.
Multiple content views
For pages that display multiple sections of content, you can transition between different pieces of content without using navigation by simply rebinding the controls on your page to a new DataContext. Also, you can rebind by loading multiple instances of a UserControl inside the page, or using any other mechanism to display new content. You can choose how the user transitions forward and backward through the items. For instance, you can consider using the Previous and Next app bar buttons. However, we recommend that you avoid overusing the Back button for local transitions.
Saving state and tombstoning
You can save a local history of transitions that occur in a given page, so if an app is tombstoned, users can retrace their steps. For simple scenarios like previous or next browsing, all you need to do is save the page state. Doing this along with the use of the Frame class should provide all the info you need to traverse the dataset when returning from a tombstoned state. For apps that have a more complex local transition history, such as free-form browsing of linked items, you may choose to store some of that history in page state, but you should put a reasonable limit on the items that you store. A key point is for the user to use the hardware Back button and return to the previous page instead of the previously viewed item.
The following table provides info about the common parts of an app that are considered to be pages.
|Type of screen||Page||Description|
|Splash screen||No||This is a transient part of the startup experience and the user can't navigate to it.|
|Hub experience||Yes||A common home screen approach for Windows Phone apps.|
|Details page||Yes||This page is common for data-centric apps parameterized through the query string.|
|Pivot item||No||A pivot item is a smaller component of the pivot control that is the place of interest for content.|
|Login or error dialog||No||This is transient UI triggered by the app state, and the user doesn't navigate to it directly.|
|Item enumeration||No||This is used for browsing similar content as an in-place activity and not as a means of navigation.|
The following table summarizes approaches that you can use to deal with various types of UI implementation.
|UI type||Implementation||Back button behavior||Tombstone behavior|
|Page||Page||The Back button automatically goes back or exits the app. You shouldn't override except in the case of data loss.||Automatically remains on the back stack.|
|Screen-transient UI||Pop-up or a child window||The app should override to cancel the pop-up window. The on-screen keyboard and message dialogs automatically cancel themselves when the Back button is pressed.||The app should dismiss or cancel the pop-up window during navigation.|
|Item enumeration||UserControl||N/A: hosted inside a parent page.||The app should save the active item as appropriate.|
Thinking across orientations and axes
Users on the Windows Phone platform will expect some apps, especially those that feature video, maps, or game elements, to function in both portrait and landscape orientation. For more info on orientation, see the "Screen orientations" section in First Look at Windows Phone.
They also expect navigation to operate across both the X and Y axes, and enjoy the sensation of being able to find new content by swiping across the phone's screen, as well as from top to bottom. Plan ways in which your app can use both orientation and axes.
When designing an app that can run in landscape orientation:
- Determine if your app will also run in portrait mode, and whether your app will be have one static orientation.
- Landscape orientation is useful when users want to maximize horizontal screen space. You can rearrange controls or layout when the user turns the phone, to enhance the impression that the screen can now fit more content horizontally.
- Landscape orientation is often used to present media content since that's the typical aspect ratio. If content consumption is the primary purpose of your app's landscape mode, fade out controls and navigation to enrich the viewing experience.
Touch gestures are the primary method for a user to interact with the Windows Phone UI. In Windows Phone, a touch gesture involves tapping or swiping one or more fingers on a touch screen.
The controls provided in the Windows Phone SDK are used as touch interaction elements. All touch interaction elements should always be properly sized for touch interaction. For more about touch targets, see Interactions and usability with Windows Phone.
The following single-touch and multi-touch gestures are supported in Windows Phone:
- Double tap
- Touch and hold
- Pinch and stretch
A tap is a single, brief touch on the screen within a bounded area and back up off the screen again.
There are two behaviors associated with a tap gesture:
- Finger down provides touch indication
- Finger up executes the action
A tap also fully dampens the inertia of any motion that may have been underway.
A double tap is two quick taps within a bounded area.
A double tap toggles between zoomed-in and zoomed-out states of a control or an app. The app determines its current zoomed state and zooms in or zooms out accordingly. The app defines the zoomed-in and zoomed-out states.
A pan is a single finger placed down and moved across the screen in any direction. The pan gesture ends when the finger is lifted from the screen.
There are two behaviors associated with a pan gesture:
- Content can be moved through direct manipulation. It will stick to and follow the movement of the finger. Controls or the app can decide what panning direction to support. This movement can be horizontal, vertical, or any other direction specified. If content is moved to an in-between state, the content should snap back to the closest state.
- A pan can move or reorder a specific item. An item follows the finger and drops in the new location when the finger is lifted from the screen.
A flick is a single finger in contact with the screen, moved rapidly in any direction, and ending with the finger lifted up off the screen while the finger is still moving. A flick can follow a pan gesture.
A flick gesture pans a scrollable area, or moves an object, with inertia. The controls or the app can be configured to support specific flicking directional behavior. This can be horizontal, vertical, or another specified direction. If horizontal or vertical paths are specified, movements in other directions will be converted into vertical or horizontal movement.
Flick typically moves the whole canvas, but you can specify individual objects to be moved instead.
Pinch and stretch
A pinch and stretch is two fingers down within separate bounded areas followed by the fingers moving closer together (pinch) or further apart (stretch).
Pinch and stretch
Pinch and stretch provides continuous zoom on content with the origin of the zoom located at the center of the two fingers. If a pinch or a stretch ends with flicks then you can choose to have your app respond by zooming with inertia.
Touch and hold
Touch and hold is a single finger down within a bounded area for a defined period of time. The touch and hold gesture should generally be used to display a context menu or options page for an item.
Touch and Hold
Windows Phone supports at least four simultaneous user touch input points to enable unique app interactions. Simple examples would be games or musical instrument apps.
Screen touches 7 mm or larger in diameter are treated as unique touches when the edges of the touch are separated by 3.5 mm or more, and all gestures are supported.
Every touch point also adds additional processor load, so if you're implementing more than two simultaneous touch input points, be aware of potential performance impacts. While Windows Phone supports up to 10 touch points, not all hardware screens will support more than four touch points.