1- Elements Alignment and Margins
- All pages should respect the 12px or 24px margin on the left.
- Content, titles, headers, and header logos should be left aligned to 12px or 24px margin.
- If right alignment is required, the right edge margin will be also 12px or 24px.
- Tip: Check the semi-transparent grid of 25 × 25-pixel red squares on your application when running in debug mode. These squares are contained within a padding of 24 pixels around the page and are offset by 12 pixels between one another — the magic combo for Windows Phone design. The grid enables you to quickly and easily identify any alignment issues on the page.
- Field and value pairs should either be presented in two left aligned columns, or with the tile above the content as in the contact detail page in the people hub.
2- Element Spacing
Spacing between elements should be consistent both horizontally and vertically. It is recommended that elements are spaced a multiple or subdivision of 12px apart in order to follow the design grid.
3- Control Feedback on Tap
- When using standard controls such as Buttons, List Items .. etc, should use the standard Windows Phone tilt effect.
- No background, foreground, or border color changes
- Other controls, no animation or color changes are permitted
- Color change of any description is not permitted for touch feedback
4- Lists
- Tilt animations must be used to indicate a list item has been pressed.
- List items should not have a selected state, unless in a picker.
- Use strong consistent typefaces across the app, make list item text at least 12 pixels in height and make it ease for touch, and make sure that the text is legible from all angles and sizes.
Backgrounds
- Backgrounds are discouraged. They are allowed for brand reasons and to support contrast. Instead, use any accent colors on the text foreground
Layouts
- Use text size and color to establish list item hierarchy. See the Photoshop templates for a fullrangeof list templates.
Enhancements
- List enhancements should not be used unless they are distinct from one another, such as in a menu. A rule of thumb is that Icons in a circle represent actions and those without are for indication.
Scrollable Content
-If you have scrollable content on your page, you should put 95px bottom padding at the end of your content. This way the content doesn’t reach all the way to the very bottom of the page.
For example, here is a simple page that is slightly higher than the visible area:
- if the user scrolls to the end of the page, the rubber band effect will come into view and the content will be pulled slightly above the bottom. But once the scroll is released, the content bounces back down to the edge of the screen once again.
- While it doesn’t poke your eyes and it generally works OK, having content stretched all the way to the bottom is not ideal. The quick fix for this is adding 95px margin to the bottom to move your content away from the bottom – regardless if it is bottom of the phone chrome or the application bar. The final result is more pleasing to the eye.
- You can see the same padding in effect if you check the profile and history pages on any of your contact. It is also present on the new appointment page in the Calendar app and in the Internet Explorer’s settings page. Speaking of settings, scroll down to the bottom in the Settings application.
5- Pivot Controls
Pivot Pages
- All pivot controls should have at least two pages in them
Controls not permitted in Pivot
- Toggle switches
- Sliders
- Maps controls – unless they are static (pinch/zoom/pan are disable etc.)
- Browser controls - unless they are static (pinch/zoom/pan are disable etc.)
Gesture Competition
- Controls that provide a horizontally scrollable area or take a horizontal swipe gesture are not permitted in the pivot control as the horizontal swipe gesture is reserved for changing pivot pages.
Empty Pivot Pages
- If a pivot page relies upon user interaction in order to populate it with content, then placeholder text/image should be included that indicates to the user that content is outstanding. For example, if there are no items displayed on an ‘Unread email’ pivot page, then the page should not be removed, it should simply state that no content is available at this time.
for more information check: Pivot control design guidelines for Windows Phone
6- Panorama Controls
Controls not permitted in Panorama
- Toggle switches
- Sliders
- Maps controls – unless they are static (pinch/zoom/pan are disable etc.)
- Browser controls - unless they are static (pinch/zoom/pan are disable etc.)
Application Bar
- Common actions such as refresh, search and settings should be placed in an application bar.
- The options available in the application bar can change contextually with the panorama pane.
- Floating buttons on the panorama should be avoided or be kept to minimum
Gesture Competition
- Controls that provide a horizontally scrollable area or take a horizontal swipe gesture are not permitted in the panorama control as the horizontal swipe gesture is reserved for changing panorama pages.
Scrollable Panes
- Panorama panes should either scroll vertically or horizontally. Not both.
- All panorama panes should not scroll vertically. If this is the case a pivot control is probably more suitable.
- Using a variety of panorama panes (vertical and horizontal) will improve the overall user experience and make the panorama easier to navigate.
Navigation
- Floating buttons should be avoided. If necessary provide a navigation section to allow users to dig deeper into the content.
- The native Pictures and Music & Videos panorama have good examples of this. Generic tasks should be placed in the panorama app bar.
Interactive Content
- Minimize the use interactive content on the panorama (forms, search boxes etc.).
- Panorama controls should be used to entice the user to explore (i.e. overview about the app).
- Use only a small set of tasks at this level that are fresh, dynamic and compelling.
- The panorama control should not be your entire application.
Number of Panes
- A maximum of five panes are recommended. Any more than five and they will be difficult to navigate and performance will take a hit.
Background
- Panorama controls should have a background. These can be textures brand elements, graphics, photos.
- Ideally they should be engaging and where possible contextual.
Title
- The panorama title should be animated.
- The rate of motion for the panorama title is that it should be slow relative to the topmost content layer, and slower than the background art (if applicable).
Section Titles
- The font size should be larger than the corresponding content.Photoshop templates are available tofacilitate panorama design.
for more information check: Panorama design guidelines for Windows Phone
7- Headings
- Headings should be left aligned, and should not have backgrounds, borders, underline, or any other kind of decoration.
- The exception to this is panorama pane titles, which may use corporate branding.
- Also see text guidance section of this blog.
8- Buttons
Placement
- Wherever possible, buttons should be placed in the application bar.
Exceptions to this include:
- Panoramas - where guidance Error! Reference source not found may apply.
- Dialogs and settings where more verbose actions may be needed.
- Quick actions (for example call history on a Windows Phone)
Close Buttons
- Windows Phone applications do not need close buttons, as closing actions are handled by the hardware back button.
Back Buttons
- Back buttons are not permitted anywhere in Windows Phone. The user will make use of the hardware back button on the device.
Home Buttons
- Home buttons should be avoided as they can prove problematic to the Windows Phone navigation model. This becomes most evident if a user actions both the home button and the hardware ‘back’ button to navigate which may result in a loop effect.
9- Pickers
- The standard pickers should be used for picking the date and/or time, or for choosing a letter of the alphabet.
- Should a nonstandard picker be required, these should follow the look and feel of the ringtone picker in the Settings app on the device.
10- Start Tiles
Primary Tiles
- Start tiles should not have rounded corners or three dimensional elements to them. They should fit in with the look and feel of other items in the Start menu.
- Ensure standard tile templates are used
- The app logo should appear in the space dedicated to it in the template
- Logos should not be duplicated on the tile
- If the name of the app is included as part of the tile image, then the app name should be removed from the manifest to avoid it appearing twice
- Avoid including localized text in image files for tiles
- Start tiles should avoid having a full black (#000000) or full white (#FFFFFF) background, as these will not render properly in the dark or light themes.
Avoid using relative time stamps or dates (eg. ‘two hours ago’). This is a static statement and will become inaccurate as time progresses. Instead, use an absolute date or time (eg. ’14:00’)
Secondary Tiles
- Secondary tiles should not link to static content
- Secondary tiles should not interact with the app (eg. ‘skip to next track’)
- Good examples include pinning a news category that updates regularly or a specific stock with an updating share price
- Avoid pinning to content that may not be available to users when they access the app at a later date (eg. a specific news article that is no longer current and has been replaced)
Wide Tiles
- The wide tile should only be used to display new, interesting content and notifications which are updated frequently (at least weekly).
- Wide tiles must be live.
for more information check: Tile design guidelines for Windows Phone
11- Browser Controls
- Browser controls should not be embedded in any pages in an app. The user should always be taken off to Internet Explorer on the device.
- Links that navigate a user away from the app should clearly state that this will happen.
Exceptions
- Where the user is being taken to a single page for authentication (such as with Facebook or Twitter), and no Xauth or similar API is available for the authentication controls to be implemented in Silverlight controls, the authentication can be performed in an embedded web browser control in the application.
12- Dialog Boxes
- Use the standard Windows Phone Dialog box. Single buttons should be left aligned and multiple buttons centre aligned.
- Avoid creating custom dialog boxes – If this is unavoidable ensure the behavior of the custom control mimics that of the native dialog box.
- The Windows Phone toolkit also has a dialog control that allows for a greater degree of customization.
for more information check: http://msdn.microsoft.com/en-US/enus/library/microsoft.xna.framework.gamerservices.guide.beginshowmessagebox.aspx
13- Contrast
- There must be sufficient contrast between the background and foreground of controls on the page.
- This is particularly important for panoramas, where the background image can often interfere with the legibility of text. If this happens, either replace the image, or apply a semi-transparent black (or grey) layer over the image.
14- Text
Text Case
- Titles in Windows Phone should always be lowercase with the exception of section titles which should be all uppercase. If brand guidelines insist on a different case, then ensure that the use of the case is consistent across the app.
Custom/Brand Typefaces
- Custom or brand typefaces can be used in moderation in the application, though care should be taken. Custom typefaces can be used for page titles or panorama section titles. Segoe WP should be used everywhere else.
- Be careful if the typeface closely resembles Segoe WP, such as Arial or Helvetica, as mixing these with Segoe can look odd.
15- Images
- Images used within the application on backgrounds or UI elements should properly fit the application.
- Aspect ratios should be respected, images should not be pixilated or smudged as a result of scaling, and images with transparency should have proper anti-aliasing to ensure they display properly on different colored backgrounds.
- For most apps, we recommend that you include only WXGA assets. WXGA assets have the highest quality, and they automatically scale to work well for other resolutions. Multi-resolution apps for Windows Phone 8
16- Icons
Metaphors
- Don’t mix metaphors. Users recognize certain icons to mean certain things, either because they are used elsewhere in the device or because they are commonly associated with something else. For example:
- If no icon exists for the metaphor you are trying to convey, create one. Do not repurpose existing icons.
Look and Feel
- Icons should respect the Windows Phone design style look and feel – simple, one color, and two dimensional.
17- Touch Targets
- Ensure your application is optimized for touch.
- Minimum font size is 15pt
- Recommended touch target size is 9mm
- Minimum touch target size is 7mm
- Minimum spacing between elements is 2mm
- Visual size is 60-100% of the touch target size
- Provide feedback when an item is touched
18- Typos
- The app should not have any spelling mistakes.
- Copy that is spelt incorrectly looks bad and could negatively impact the brand perception.
19- Theme
- The application should either respect the theme and accent color changes of the device, or should have a fixed theme that is not affected by such changes.
- All elements should be visible and have appropriate levels of contrast regardless of theme.
20- Splash Screen
- Provide different splash screens for the different resolutions
21- The Hardware Back Button
- The hardware back button should always allow a user to complete one of the following tasks:
1. Dismiss temporary UI elements such as dialogs, keyboards (SIP) or pick lists.
2. Move backwards through the back stack.
- The back button must not be altered under any circumstances. This includes its behavior when implementing secondary tiles (please refer to section 4.1.22)
22- Secondary Tiles (deep linking)
- Secondary tiles are designed to launch the user into specific areas of the application. They are designed to allow quick and easy access to content and are generally not used as an entry point for exploration.
- Good examples of secondary tiles can be found on the device itself. For example, a pinned album from music and video will play the album when tapped. The tile serves as a specific purpose – go to the album and play it.
- Users can also pin people to the Start screen. Tapping on one of these tiles takes the user into the contact card pivot where they can see all the information and tasks related to that specific contact.
- Pressing the hardware back button returns the user to the Start screen.
Pinning
- The Pin icon should be used in the application bar to indicate that an item/section of the app can be pinned to the start screen. Please do not repurpose existing icons.
- Pinning can also be activated by using the touch and hold context menu – this is available in the Windows Phone toolkit.
- The pinning action should always be initiated by the user, or permission from the user should be sought. Do not pin items to a user’s Start screen without requesting their permission first.
Hardware Back Button
When a user launches an application by tapping on a secondary tile, pressing the hardware back button should exit the application (i.e. return to the Start screen). The behavior of the hardware back button should not be altered in any way.
23- Lock Screen
- Background images should contain minimal text to avoid conflict with on-screen messages
- Background images should be simple – ‘busy’ images affects the legibility of on-screen messages and notifications
- Logos should be kept small to avoid competition with date, time and notifications
- If text is included, it should related directly with the image
- The visual focus of the lock screen should be the image, not the logo or text
24- Lens Design
- Apps should support a left-pointing arrow icon to indicate that additional photos are available
- The animation for ‘Save’ and ‘Capture’ should be consistent
- Tap-to-tap capture and the camera hardware button should be supported
- Half-press to focus should be supported
- Focus brackets should function as they do for the basic camera where relevant
- Capture and confirm apps should use a consistent set of icons (‘save’ and ‘delete’) along with animation for confirming and cancelling the storage of the item.
- ‘Cancel’ and ‘save’ should return the user to the viewfinder. These icons are included with the Windows Phone SDK.
Rich Media Open Link
- The open link should launch an experience tailored to viewing or editing a selected item and not action a generic app launch point
- Displaying branding elements on items stored in the camera roll should be avoided – users should be able to share and edit these items without visual distractions
for more information check: Lens design guidelines for Windows Phone
25- Page Transitions
- Animations should be implemented when moving between pages. This effect is available from the Silverlight for Windows Phone Toolkit.
- couple of page transitions are included in the Silverlight for Windows Phone Toolkit:
- Use a bar to indicate progress
- Turnstile - To transition between contextually different areas
- Swivel - Partial and transient UI
- Slide - Staying in context while showing a set of options, and No forward navigation
- Tilt – Natural feedback a control is pressed
- Just as you use tilt animation to indicate to the user that their tap has taken effect, progress bars enable you to communicate that a process is being executed. This removes doubt for the user about whether the application is functioning properly. Two types of progress bars can be used: determinate and indeterminate.
Determinate progress bar.
Indeterminate progress bar.
- A determinate progress bar is used to communicate the percentage of completion, such as the percentage of bytes copied out of the total number of bytes. An indeterminate progress bar is much more common and is particularly useful when you don’t know the length of the process, such as when calling a Web service and waiting for a response.
26- Language and Tone
- Do not use computer jargon, hexadecimal error codes, or text that assumes computer knowledge.
- Use an authentic and clear tone and reflect the language that is used by the audience.
- Use friendly, light hearted and empathic tones. Never use angry or mechanical tones in the application.
In Conclusion
These are just recommendations from different cases studies that are usually application specific. So, feel free to do what is right for your application taking into consideration some success factions like:
- Deliver the best experience on any mobile platform is to design the app for the platform and its accompanying usage patterns.
- The first step in building a compelling Windows Phone UI-compliant application is to spend time using the apps that ship with the OS. This will familiarize you with Windows Phone’s unique set of controls and design paradigms.
References:
2)http://msdn.microsoft.com/library/windowsphone/develop/fa00461b-abe1-41d1-be87-0b0fe3d3389d(v=vs.105).aspx
Have a nice day by Subramanyam Raju 
Hi,
ReplyDeleteThe principles of user interface design are intended to improve the quality of user interface design.The structure principle,The simplicity principle,The visibility principle,The feedback principle,The tolerance principle,The reuse principle.omaha web design