Saturday, January 08, 2011

Windows Phone 7–Design Guidelines–Cheat Sheet

An excellent resource put together by the Silverlight SDK team, if you are developing a WP7 app, print it and paste it on a wall. Many of the guidelines will help you through the certification process and maybe even get your app through on its first submission.

Windows Phone 7 – Design Guidelines – Cheat Sheet

The tips are copied from the post here:

Navigation, frames and pages

  • Mockup the pages and navigational map of your application and walk through them several times before coding. This will minimize or eliminate the need to add pages or change the map later, when it will be much harder.
  • Make sure to consider the back button and user interactions with the application bar when creating your navigation map.

Application Bar

  • Use the application bar button for common application tasks.
  • You are limited to four application bar buttons.
  • Place less frequently performed actions in the application bar menu.
  • If the action is difficult to clearly convey with an icon, place it in the application bar menu instead of as a button.
  • You are limited to five application bar menu items to prevent scrolling.
  • Standard application bar icons are installed as part of the Windows Phone Developer tools. Find them at C:\Program Files\Microsoft SDKs\Windows Phone\v7.0\Icons
  • Custom application bar icons should be 48 x 48 pixels and use a white foreground on a transparent background. You do not need the circle in the icon, as this is drawn by the application bar.

Back button

  • Pressing the back button from the first screen of an application must exit the application.
  • Pressing the back button must return the application to the previous page.
  • If the current page displays a context menu or a dialog, the pressing the Back button must close the menu or dialog and cancel the backward navigation to the previous page.
  • You should only implement back button behaviors that navigate back or dismiss context menus or modal dialog boxes. All other implementations are prohibited.

Screen orientations

  • Portrait is the default application view-you must add code to support landscape view
  • If an application supports landscape it cannot specify only left or only right landscape views – both views must be supported.

Application icon

  • Application icon should be 62 x 62 pixels and PNG format.

Tiles and tile notification

  • Tile images should PNG format and measure 173 pixels by 173 pixels at 256 dpi
  • Make sure to change Build Action for images to Content when you add them to Visual Studio.


  • Avoid using too much white in applications, such as white backgrounds, as this may have an impact on battery life for devices that have organic LED displays.
  • If the foreground or background color of a control is explicitly set, verify that the content is visible in both dark and light themes. If the set color is not visible, also explicitly set the background or foreground color to maintain contrast or choose a more appropriate color.

Application settings

  • Application actions that overwrite or delete data, or are irreversible must have a “Cancel” button.
  • When using additional screens with commit and cancel buttons, clicking those buttons should perform the associated action and return the user to the main settings screen.

Touch input

  • All basic or common tasks should be completed using a single finger.
  • Touch controls should respond to touch immediately. A touch control that lags or that seems slow when transitioning will have a negative impact on the user experience.
  • For time consuming processes, developers should provide feedback to indicate that something is happening by using content to indicate progress, or consider using a progress bar or raw notification as a last resort. For example, show more and more of the content as it is being downloaded.
  • The touch and hold gesture should generally be used to display a context menu or options page for an item.

On-screen keyboard

  • You should set the InputScope property for a text box or other edit controls to define the keyboard type and enable the appropriate typing aides. For example, if you choose the URL input scope, a keyboard layout will be shown featuring a .com key.

Canvas/Grid for layout

  • Canvas uses a pixel-based layout and can provide better layout performance than the grid control for deeply embedded or nested controls in for applications that do not change orientations.
  • Grid control is the best choice when the application frame needs to grow, shrink, or rotate.

Panorama control/pivot considerations

  • Both panorama and pivot controls provide horizontal navigation through phone content, enabling the user to flick and pan as necessary.
  • Use panorama elements as the starting point for more detailed experiences.
  • Use a pivot control to filter large data sets, providing a view of multiple data sets, or to provide a way to switch between different views of the same data.
  • Do not use the pivot control for task-based navigation, like in a wizard application.
  • Use for vertical scrolling through a list or grid in panorama sections is acceptable as long as it is within the confines of the section and is not in parallel with a horizontal scroll.
  • Never place a pivot control inside of another pivot control.
  • Never place a pivot control inside of a panorama control.
  • Applications should minimize the number of pivot pages.
  • The Pivot control should only be used to display items or data of similar type.

Text guidelines

  • Use fonts other than Segoe sparingly
  • Avoid using font sizes that are smaller than 15 points in size.
  • Maintain consistent capitalization practices to prevent a disjointed or jagged reading experience.
  • The title bar application title should be all capitals.
  • User all lower case letters for most other application text including page titles, list titles, etc.

No comments: