Essential Graphics, Visual Indicators, and Notifications for Windows Phone
March 22, 2012
Beauty is integral in mobile applications, where it is synonymous with intuitive operation. In Windows Phone, the visual elements of your Start Tile, splash screen, icons, controls, and navigation should draw attention to relevant tasks, priorities, or operations inside your application, and present information 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 to derive visual appeal, and never use visual elements that are purely decorative in nature. For more about typography, see Part 2.
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 application, and looks crisp and intelligible.
A Tile is an easily recognizable visual shortcut for an application 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 information about or relevant to the application. For example, a Tile for a weather application can dynamically show the temperature. We strongly encourage designers and developers to take advantage of this feature because it makes your application that much more useful.
Correct and Incorrect Tile Usage
The best Start Tiles communicate some information about the app, show off the personality of your brand, and look great beside all the other Tiles on the screen. When designing a Tile, follow the Metro design principles.
Tiles can communicate information to the user by displaying an optional counter that uses the system font, updating developer-provided Tile background images, 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 Start Tiles already installed by Microsoft and its mobile operator and hardware manufacturer partners. These Tiles consistently follow the Metro style. Double-width Tiles are available only to Microsoft and its partners.
Tile Art Is Important
Tile images should be 173 pixels x 173 pixels at 256 dpi, and in PNG format. Images larger or smaller than this are cropped or scaled up using the top left corner as the origin. A separate 62 pixels x 62 pixels application image must be included for display in the application list. For more information, please see Application Artwork.
Note:
|
|---|
|
Be conservative in the use of Tile Notifications—excessive use can reduce battery life. |
If you use multiple Tile images, they should be visually consistent with each other and have a recognizable theme or style. Developers cannot change the color, font, font color, or the size of the counter display.
Applications that do not incorporate a Tile image or title will display a generic, system-defined icon and the name of your project. If you are developing an app with a tight design budget, there are many websites where you can buy icons for a reasonable fee. Whether you are 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 leverage metaphors that are already familiar to people.
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 non-descriptive, ambiguous icons
-
Transparent backgrounds with colorful images
Start Tiles Background Colors
There are two key elements to a Start Tile: the icon or logo that appears in the foreground, and the square, colored background. These two should complement each other.
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.
Phone Company, Adatum, Margie’s Travel
You should avoid using a black or white background color, because the Tile background will not be visible in the white or black color themes that are available in the phone UI.
Incorrect Use of Black Background Color for a Tile
If you want your Start 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 your Start Tile alone transparent. The other icons you submit with your application should not have transparent backgrounds.
-
Make your foreground icon white. If the foreground icon is colored, the icon will not be visible or will be jarring to look at on some of the phone theme colors, as seen in the figure below.
Problems with not making the foreground icon white
Many applications take a moment to load. Use this opportunity to introduce the user to your application with a splash screen. The splash screen is visible only for a few seconds, so we recommend that you not place 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 application with graphics. A good splash screen is a graphical advertisement for your application, and uses colors and graphics to that end.
Correct and incorrect splash screens
If you are using the Windows Phone templates to build your app, a default splash screen with a small clock on it is used as a placeholder until you replace it. It’s important that you replace this graphic, or users will see the default placeholder image every time they launch your application. You can import a new asset into the Microsoft® Expression Blend® library or just replace the asset located here:
\Documents\Expression\Blend4\Projects\WindowsPhoneApplication1\WindowsPhoneApplication1\SplashScreenImage.jpg
Keep the following things in mind when planning your app’s opening views:
-
If your application uses loading or intro pages, they should not 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 application. For more information, see Technical Certification Requirements.
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-application activity related to an activity or a series of events. This is a system-reserved control that is integrated into the Status Bar and that can be displayed across multiple application pages. For more information 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. |
Developers who want to mimic this control should 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 information 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 scrolling, 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 are not 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 is not directly viewable within the frame of the application, such as a long section of text or an image.
When scrolling, 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 are non-user actionable. The Scroll Viewer supports pan and flick gestures.
The Status Bar is one of the two primary components of Windows Phone OS chrome. The other is the Application Bar.
Status Bar
The Status bar is an indicator bar that displays system-level status information in a simple and clean presentation in a reserved portion of the application workspace. It automatically updates to provide different notifications and keeps users aware of system-level status.
The Status bar is system-reserved and cannot 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.
The Application bar provides a place for developers to display up to four of the most common application 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 Application bar menu that is activated when a user taps the visual indicator of sequential dots, or flicks up the Application bar. For more information about the Application bar menu, see the “Application Bar Menu” section later in this topic.
Application bar
Use the Application bar instead of creating your own menu system. This helps to create a consistent user experience across all applications on the device. The Application bar provides menu animation and rotation support for you.
You can add an Application bar to a page in your application entirely in XAML. However, the Application Bar is not a Silverlight® control and does not support data binding. This means that the string values used for the button labels must be hard-coded in the XAML and cannot be localized. If you plan to localize your application, you should create the Application Bar in C#, or use C# to programmatically modify the label values at run time.
Design considerations for the Application bar are as follows:
-
Use the default system theme colors for the Application bar unless there is a compelling reason to customize the colors. Using custom colors for the Application bar can affect the display quality of the button icons, can cause unusual visual effects in menu animations, and can even influence power consumption on some display types.
-
The opacity of the Application bar can be adjusted finely, but we recommend that you use only opacity values of 0, 0.5, and 1.
-
Note that if the Application bar opacity is set to less than 1, the displayed page will be the size of the screen, with the Application 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 Application Bar.
For an explanation and an example of how to localize the Application bar, see How to: Build a Localized Application for Windows Phone.
Design Considerations
-
Use the user-defined system theme color unless there is 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 Application 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 Application 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 Application Bar.
-
The Application 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 application bar height in portrait mode and width in landscape mode is fixed at 72 pixels and cannot be modified. It can be set to be displayed or hidden.
Application Bar Menu
The Application bar menu is an optional way for users to access specific tasks from the Application bar. Place tasks that are not frequently used in the Application bar menu.
This menu is activated when user taps the visual indicator of sequential dots or flicks up the Application 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 Application Bar icon.
Application 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 Application bar menu item runs off the screen if it is 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 Application Bar Menu remains on the screen until the user performs an action.
Application Bar Icons
Application Bar icons should be clear and understandable, and should leverage 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 do not 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 should have a text hint. They should be 48 x 48 pixels and have a white foreground on a transparent background using an alpha channel. |
Application 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.
Application Bar icons
Use icon buttons for the primary, most-used actions in the application. Don’t employ four icons just to use them.
Usage Considerations
-
Some actions are difficult to clearly convey with an icon. Place it in the Application Bar Menu instead.
-
No text-only buttons are permitted. Icon text hints are displayed when users display the Application Bar Menu.
-
Do not use an Icon button for a Back button that navigates backwards 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 Application Bar is rotated. The Application 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 is 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 does not 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 Application Bar Icon.
-
The circle that is displayed on each icon button is drawn by the Application Bar and should not be included in the source image.
Use the user-defined system theme color unless there is 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 Application Bar Icons (32 dark and 32 light) in PNG format are installed as a part of theWindows Phone SDK 7.1. Only the white icons should be used in the Application Bar. To locate these items, navigate to:
C:\ Program Files\Microsoft SDKs\Windows Phone\v7.0\Icons.
For application 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 application, or to the device as a Tile, toast, or raw notification.
There are three methods to display 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. To read more about Start Tiles, see the “Start Tiles” section earlier in this topic. Using tile notifications, you can dynamically set properties on a Tile such as the count, background image, and title.
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 application icon in the left corner. Two fields of text are available: one bolded title and one normal sub-title. Text that is longer than the display area is truncated.
Toast notifications are displayed for 10 seconds before disappearing. If the notification is tapped, the application that sent the notification will launch. Toast notifications are system-wide notifications, but do not 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.
Toast Notifications
Proper Usage
Use toast notifications for action-requested notifications, but use them sparingly, as all applications 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 application.
|
Note:
|
|---|
|
Turn-based games should use the XNA Framework GamerServices for notifications. |
Applications must default to turn toast notifications off. Toast notifications should be personally relevant and time-critical to the user. Generally, they are reserved for peer-to-peer communication, as in the SMS application.
Raw Notifications
Notifications that require action inside an application are fully controlled by an application and affect only that application. These are called raw notifications. They can be generated by the application itself or sent from a web service. There is no system-wide way to display a raw notification.
Raw Notifications
Proper Usage
Use raw notifications for in-application notifications that require the user’s action.
-
If there is no network connection, the application 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 indicate to the user what is wrong.
An end end-user license agreement, or EULA, is a set of guidelines for use that the user consents to abide by when he or she first launches the app . It also lays out the user's rights, as the developer envisions them. It's an agreement between the developer and the person purchasing the app that stipulates that the user won't misuse it.
Use of an app should be contingent upon a user accepting the EULA. If the user does not accept the terms of your EULA, the user should not 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.
