Essential graphics, visual indicators, and notifications for Windows Phone
[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]
Beauty is integral in mobile apps, where it’s synonymous with intuitive operation. In Windows Phone, the visual elements of your Tile, splash screen, icons, controls, and navigation should draw attention to relevant tasks, priorities, or operations inside your app, and present info in novel, eye-catching ways. Your app will need custom designs for a Live Tile, or animated icon, as well as a splash screen image that introduces your app to the user while it loads. These and other visual indicators are the subject of this section.
Be sparing with graphics. Remember to use content and typography for visual appeal, and never use visual elements that are purely decorative in nature.
Keep in mind that on mobile platforms, simplicity is the most appreciable source of attractiveness. Where art is appropriate, use high-quality, original graphic art, branding, or photography. Ensure that art meets or exceeds the required dimensions in your app, and looks crisp and intelligible.
This topic contains the following sections.
- Tiles
- Splash screens
- Visual indicators
- Status bar
- App bar
- Icon buttons
- On network outage
- Include an end-user license agreement
- Related Topics
Tiles
A Tile is an easily recognizable visual shortcut for an app or its content that users can set in the phone's Start view. Which Tiles show on the Start screen can be customized by “pinning” an app’s Tile to the view. A Live Tile is better than an icon, because it can surface info about or relevant to the app. For example, a Tile for a weather app can dynamically show the temperature. We strongly encourage you to take advantage of this feature because it makes your app that much more useful.
.png)
Correct and incorrect Tile usage
The best Tiles communicate some info about the app, show off the personality of your brand, and look great beside all the other Tiles on the screen. Tiles can communicate info to the user by displaying an optional counter that uses the system font, updating Tile background images that you’ve provided, or displaying an optional Tile that uses the system font in a fixed size and color. Counter, background image, and Tile updates are controlled using the Tile Notification service. The accent color for the counter is always the accent color that the user has selected. Counter display is optional.
Windows Phone devices come with some Tiles already installed by Microsoft and its mobile operator and hardware manufacturer partners. These Tiles consistently reflect the unique Windows Phone Experience. Double-width Tiles are available only to Microsoft and its partners.
For more info, see Tile design guidelines for Windows Phone.
Tile art is important
If you use multiple Tile images, they should be visually consistent with each other and have a recognizable theme or style. You can’t change the color, font, font color, or the size of the counter display.
Apps that don’t incorporate a Tile image or title will display a generic, system-defined icon and the name of your project. If you’re developing an app with a tight design budget, there are many websites where you can buy icons for a reasonable fee. Whether you’re designing the Tile yourself, commissioning it, or buying it, keep it simple. Icons should have simple geometry and limit the amount of very fine detail. If possible, they should use metaphors that are already familiar to people.
Note
Be conservative in the use of Tile Notifications. Excessive use can reduce battery life.
Styles to avoid
3D typography
Icons or backgrounds with gradients, bevels, or casting shadows
Rounded corners
Black or white color backgrounds; the Tile background will disappear on a Windows Phone device’s dark or light theme
Using nondescriptive, ambiguous icons
Transparent backgrounds with colorful images
Tile background colors
There are two key elements to a Tile: the icon or logo that appears in the foreground, and the square, colored background. These two should complement one another.
Choose a background color that represents your brand and makes your foreground icon easy to see or read. The following figure shows three examples that follow the guidelines.
.png)
Phone Company, Adatum, Margie’s Travel
You should avoid using a black or white background color, because the Tile background won’t be visible in the white or black color themes that are available in the phone UI.
.png)
Incorrect use of black background color for a Tile
If you want your Tile background to be the same theme color as the phone UI, you can make the background of your Tile transparent. If you do this, it’s very important to:
Make only your Tile transparent. The other icons you submit with your app shouldn’t have transparent backgrounds.
Make your foreground icon white. If the foreground icon is colored, the icon won’t be visible or will be jarring to look at on some of the phone theme colors, as seen in the figure below.
.png)
Problems with not making the foreground icon white
Splash screens
Many apps take a moment to load. Use this opportunity to introduce the user to your app with a splash screen. The splash screen is visible only for a few seconds, so we recommend that you avoid using any copy text that requires the user’s attention or would take time to read. Instead, use this space to transition the user’s gaze into your app with graphics. A good splash screen is a graphical advertisement for your app, and uses colors and graphics to that end.
.png)
Correct and incorrect splash screens
To add a splash screen to your app, add an existing JPG image file to the root folder of your project, and name the file SplashScreenImage.jpg.
Keep the following things in mind when planning your app’s opening views:
If your app uses loading or intro pages, they shouldn’t be included in the back stack. In other words, they should be skipped when the user presses the Back button.
There are several certification requirements related to the Back button and the first screen of the app. For more info, see Technical certification requirements for Windows Phone.
Visual indicators
Windows Phone OS uses three different types of indicators to show task progress, scroll views, signal strength, battery life, and other vital information.
Progress indicator
A progress indicator shows in-app activity related to an activity or a series of events. This is a system-reserved control that’s integrated into the Status Bar and that can be displayed across multiple app pages. For more info about the Status Bar, see the “Status Bar” section later in this topic
Note
A progress indicator can be either determinate or indeterminate. Determinate progress indicators have a beginning and ending point. Indeterminate progress indicators continue until a task is finished.
If you want to mimic this control, use the determinate progress indicator for tasks such as downloading content, and use the indeterminate progress indicator for tasks such as remote connections.
For more info about how task progress is displayed to users, see ProgressBar control design guidelines for Windows Phone.
Scroll indicators
Page scrolling occurs when content on the screen exceeds the bounds of the visible page and a user pans or flicks. When a user scrolls, visible scroll indicators appear on the right side for vertical scrolling and along the bottom for horizontal scrolling. These scroll bars indicate that the content is longer or wider than the page, and represent the current position on the page. After page scrolling ends, the scroll indicators fade from view after one second has elapsed.
The scroll indicators aren’t user actionable and are an overlay to the content beneath them. Their primary function is to provide a hint to the user about the page size.
Scroll viewer
The Scroll Viewer allows users to navigate to content that isn’t directly viewable within the frame of the app, such as a long section of text or an image.
When a user scrolls, scroll indicators fade in as the user pans or flicks and fade out after one second at the end of the gesture, but the scroll indicators aren’t user actionable. The Scroll Viewer supports pan and flick gestures.
Status bar
The Status Bar is an indicator bar that displays system-level status info in a simple and clean presentation in a reserved portion of the app workspace. It automatically updates to provide different notifications and keeps users aware of system-level status.
.png)
Status bar
The Status Bar is system-reserved and can’t be modified. It can be hidden, but many users view the system clock as an essential feature, so think carefully before hiding it.
The Status Bar displays the following information (in order from left to right):
Signal strength
Data connection
Call forwarding
Roaming
Wireless network signal strength
Bluetooth status
Ringer mode
Input status
Battery power level
System clock
System clock
By default, only the system clock is always visible. If a user double taps in the Status Bar area, all other relevant indicators slide into view for approximately eight seconds before sliding out of view.
The system clock is 32 pixels high in portrait mode and 72 pixels wide in landscape mode. It always extends to the edge of the screen and is opaque in appearance.
App bar
The App Bar provides a place for you to display up to four of the most common app tasks and views as icon buttons. This bar provides a view that displays icon buttons with text hints, as well as an optional context menu called the App Bar Menu that is activated when a user taps the visual indicator of sequential dots, or flicks up the App Bar.
.png)
App bar
Use the App bar instead of creating your own menu system. This helps to create a consistent user experience across all apps on the device. The App bar provides menu animation and rotation support for you.
You can add an App bar to a page in your app entirely in XAML. However, the App bar is not a standard control and doesn’t support data binding. This means that the string values used for the button labels must be hard-coded in the XAML and can’t be localized. If you plan to localize your app, you should create the Application Bar in C#, or use C# to programmatically modify the label values at run time.
Design considerations
Use the user-defined system theme color unless there’s a compelling reason to override it. Using a custom color can affect the display quality of the button icons, create unusual visual effects in menu animations, and reduce battery life on some devices.
The opacity of the App bar can be adjusted finely, but we recommend that you use only opacity values of 0, 0.5, and 1. If the opacity is set to less than 1, the displayed page will be the size of the screen, with the App bar overlaid on top of it. If the opacity is set to 1, the displayed page will be resized to be the area of the screen not covered by the App bar.
The App bar always stays on the same edge of the display as the steering buttons (Back, Start, and Search) and extends the full width of the screen in portrait or landscape mode. Icon buttons rotate to align with the three phone orientations.
The App bar height in portrait mode and width in landscape mode is fixed at 72 pixels and can’t be modified. It can be set to be displayed or hidden.
For an explanation and an example of how to localize the App bar, see How to build a localized app for Windows Phone 8.
App bar menu
The App bar menu is an optional way for users to access specific tasks from the App bar. Place tasks that aren’t frequently used in the App bar menu.
This menu is activated when user taps the visual indicator of sequential dots or flicks up the App bar. The view can be dismissed by tapping outside of the menu area or on the dots, using the Back button, or selecting a menu item or App bar icon.
.png)
App bar menu
Design Considerations
To prevent the menu from scrolling, the number of items displayed in the menu is limited to five.
The text for an App bar menu item runs off the screen if it’s too long. The recommended maximum length for the text of a menu item is between 14 to 20 characters. Again, less is more in this space.
If no menu items are displayed, only the icon text hints are displayed.
The App Bar Menu remains on the screen until the user performs an action.
App bar icons
App bar icons should be clear and understandable, and should use real-world metaphors that are familiar to users. The best icons have simple geometry and limit the amount of fine detail.
Buttons should have an icon and a text hint. Text hints should be short and provide context for what the button does, and they don’t need to be fully descriptive. An example would be a button that flips an image horizontally. Instead of “flip horizontally,” “flip” would be sufficient.
Note
Buttons should have an icon and a text hint. They should be 48 x 48 pixels and have a white foreground on a transparent background using an alpha channel.
App Bar buttons can be displayed in an enabled or disabled state. An example of a disabled button would be a Delete button in read-only scenarios.
.png)
App bar icons
Use icon buttons for the primary, most-used actions in the app. Don’t employ more icons just to use them.
Usage considerations
Some actions are difficult to clearly convey with an icon. Place these actions in the App bar menu instead.
Text hints for app bar icons are displayed when users display the App bar menu.
Don’t use an Icon button for a Back button that navigates backward in the page stack. All Windows Phone devices are required to have a dedicated hardware Back button that should always be used for backward navigation.
Choose icons that have clear meanings when the App bar is rotated. The App bar automatically handles changes in screen orientation. When the device is in a landscape orientation, the menu is displayed vertically on the side of the screen. The icon buttons are rotated so that they appear upright to the user, but the order of the icons in the list is not changed. It’s possible for icon meanings to be confused when this occurs, particularly if two of the icons are mirror images of each other along the Y axis.
Design considerations
Icon images should be 48 x 48 pixels in size.
Icon images should use a white foreground on a transparent background using an alpha channel. The white foreground graphic for the button should fit in a 26 x 26 area square in the center of the image so that it doesn’t overlap the circle.
Images that are sizes other than the recommended size are scaled to fit and can potentially lower the overall image quality of the App bar Icon.
The circle that’s displayed on each icon button is drawn by the App bar and shouldn’t be included in the source image.
Use the user-defined system theme color unless there’s a compelling reason to override it. Using a custom color can affect the display quality of the button icons, create unusual visual effects in menu animations, and reduce the battery life of some devices.
Icon buttons
A set of 64 App bar Icons (32 dark and 32 light) in PNG format are installed as a part of the Windows Phone SDK 8.0. Only the white icons should be used in the App bar. To locate these items, navigate to:
C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Icons\Dark
Icon buttons
For app development, the Push Notification Service is designed to provide a cloud service with a dedicated, resilient, and persistent channel for pushing a notification to a mobile device.
When a cloud service needs to send a push notification to a device, it sends a notification request to the Push Notification Service, which in turn routes the notification to the app, or to the device as a Tile, toast, or raw notification.
There are three methods for displaying push notifications: Tile notifications, toast notifications, and raw notifications.
Tile notifications
Tile notifications inform users of changes or events that may have occurred and are nondisruptive to the user workflow. They appear on Start Tiles. Using tile notifications, you can dynamically set properties on a Tile such as the count, background image, and title.
.jpg)
Tile notifications
Proper Usage
Use Tile notifications for awareness-only notifications.
Toast notifications
A web service can generate a special kind of push notification known as a toast notification, which requests an action from the user. Toast notifications appear as an opaque bar in the accent color at the top of the screen, and display a scaled-down version of the app icon in the left corner. Two fields of text are available: one bolded title and one normal subtitle. Text that’s longer than the display area is truncated.
Toast notifications are displayed for 10 seconds before disappearing. If the notification is tapped, the app that sent the notification will launch. Toast notifications are system-wide notifications, but they don’t disrupt the user workflow or require intervention to resolve. An example of these notifications is when the user receives a text message or instant message.
.png)
Toast notifications
Proper Usage
Use toast notifications for action-requested notifications, but use them sparingly. All apps have access to Toast notifications, and too many toast notifications annoy the user. Examples would be notifications produced via an instant messaging client or a peer-to-peer oriented app.
Note
Turn-based games should use the XNA Framework GamerServices for notifications.
Apps must default to turn toast notifications off. Toast notifications should be personally relevant and time-critical to the user. Generally, they’re reserved for peer-to-peer communication, as in the SMS application.
Raw notifications
Notifications that require action inside an app are fully controlled by an app and affect only that app. These are called raw notifications. They can be generated by the app itself or sent from a web service. There is no system-wide way to display a raw notification.
.png)
Raw notifications
Proper Usage
Use raw notifications for in-app notifications that require the user’s action.
On network outage
If there is no network connection, the app should provide an appropriate warning. You can use Airplane mode to test your warning.
Verify that the app can still be navigated when there is no network available. Although there may be no data coming in, navigation of the app should still be functional.
If a network outage interrupts a feature or operation, always let the user know what’s wrong.
Include an end-user license agreement
An end-user license agreement, or EULA, is a set of guidelines for use that the user consents to follow when he or she first launches an app. It also lays out the user's rights, as you envision them. It's an agreement between you and the person purchasing the app that stipulates that the user won't misuse it.
Use of an app should depend on a user accepting the EULA. If the user doesn’t accept the terms of your EULA, the user shouldn’t be permitted to use the app.
This statement should discuss behaviors and uses of your app that you endorse, including specific terms about content, license, installation, activation, validation, Internet-based services, or the use of certain information. It's also a good place to inform users about your plans to update or offer upgrades to the app, or your use of software formats and standards. If your app is associated with a business, your EULA should also indicate where your business is registered, and whether you offer any kind of warranty.
See Also
Other Resources
Tile design guidelines for Windows Phone
Icon templates for Windows Phone 8
Screen design templates for Windows Phone 8
Tiles and notifications for Windows Phone 8
How to create a splash screen for Windows Phone
How to create a custom indeterminate progress bar for Windows Phone 8