Interactions and usability with Windows Phone
This topic discusses the implications of how layout can affect the usability of your app. Other common UI pieces, such as search and settings, are also discussed in the context of app usability.
Before you continue working with controls and interactions:
- Learn about strategies for conceptualizing an app in Design the best Windows Phone app you can.
- Read the design guidelines for the standard system controls in Controls.
Your app should present users with touch targets of ample size. Users should get feedback that their taps have operated controls and have allowed them to make progress in your app. To these ends, Windows Phone has certain requirements about using touch targets and text.
Designing for touch is a complex balance between size, spacing, and visuals. Achieving this balance reduces what's known as the "index of difficulty in target acquisition"—in other words, it makes controls easier to press.
Extensive user testing suggests that 9 mm square is the ideal touch target size across all Microsoft touch platforms.
9 mm square or larger is the ideal touch target for a touch UI asset
Where smaller hit target heights are warranted, the minimum target size is 7 mm. In these cases, it's better to have a wider visual asset in these cases. For example, list items or menu items should be wider.
7 mm is the minimum target size
About the 9 mm requirement
The recommended touch target size is greater than or equal to 9 mm square. Use this for controls that support the majority of tasks.
If space is severely constrained, you can use a minimum touch target size of 7 mm, as long as the width is much larger.
Nine millimeters is a number determined by hundreds of hours of user testing, and represents the lowest average error rate (or the ratio of false taps to the total number of taps) for both discrete and serial tasks. A 9 mm minimum touch target size can limit error rate to as little as 1.6 percent.
The minimum touch target size is 7 mm. Use this for controls that are infrequently used or controls that are wide enough (greater than or equal to 15 mm), and only when too much height limits the design.
Minimum visual size
The minimum visual size for a touchable item should be greater than or equal to 4.2 mm. Any smaller, and users won't perceive the item as touchable at all. Use this size only when a smaller visual asset is necessary. Targets can be 10-15 mm or larger.
Tip: In most cases, make the visual size equal to the touch target size. Use spacing to make controls look easier to hit.
Assess the consequences of mistaps
Always remember the task context and assess the error rate when assigning a target size to a control. Controls with major error consequences should have bigger targets. Controls used in motion should also have bigger targets.
For example, the system phone dialer has very large touch targets, because mis-taps have a fairly high cost: a user could dial the wrong number. In operations where errors are more easily tolerated, you may choose to use smaller targets.
The following figure shows the discrete parts of a touch target.
Touch target parts
In the preceding Tile figure, pay notice to the:
- Visual Spacing: Intermediate spacing between controls and buttons increases comfort of touch.
- Visual Asset: This is the actual size of the icon/control/text that the user sees.
- Touch Target: This is the green border around the visual asset shown in the image above. Touch targets can be equal or larger but never smaller than the visual asset size. They are indicated by the Green Lines in the common controls Style guide.
- Dead Space: Space between two touchable items is the area where no action occurs.
To learn more about making great looking Tiles, see Guidelines for tiles and badges.
Using smaller targets
If space and task constraints make it difficult to use proper touch targets, consider how you can vary the following attributes of your touch target to improve the experience:
- Frequency of use
- Task context
- Visual design (padding/spacing)
- Error consequence
|Make the target size bigger than the visual asset. Don't go below 4.5 mm for the visual asset size when the asset's visual size will be smaller than the target.|
|Introduce spacing between adjacent visual assets. In these cases, adjust for the hit target size by including space (2 mm minimum) between adjacent assets to enable better hit targets.|
|Create a visual padding around the asset. The difficulty in hitting a small target can be reduced by introducing a visual padding to create a safe boundary. This will reduce the perceived difficulty in hitting the target.|
When defining the proper size for UI elements, consider the importance of the element and its attendant task. Mundane tasks, such as checking email, should require less attention from the user; special tasks should draw more attention.
Spacing small controls
If you have small elements, you can adjust for the target size by using spacing. Use spacing to adjust for closely spaced small controls. Remember to use spacing for closely spaced small controls.
Important Note: No matter the size of the actual control, use enough spacing that you can still accommodate the 9 mm minimum touch target size.
Let's say you have a 4 mm check box control. Make the touch target 3-5 mm larger so that it reaches the size of 7-9 mm. If you want to reduce error further, put spacing between the check box control and the next adjacent 9 mm target (or roughly 90 pixels on a 262-dpi device). Measure the image on your device with a caliper; the size is important, not the pixel count.
Some controls, such as the on-screen keyboard and the hyperlink controls, use algorithms to improve touch accuracy.
Exceptions like keyboard and hyperlink lists need to have correction mechanisms like hit target resizing algorithms or zoom to enable better hit targets. In most cases, the height of the target is more important than the width, but there are some exceptions (for example, the keys on a soft keyboard where width might influence target acquisition). Ensure that the ideal target size is achieved in at least one dimension.
If all else fails, try not to have too many adjacent hit targets around a small hit target.
Too many adjacent hit targets
Size and placement of typographical elements are crucial to forming the screen layout. A foundation of modern design is the lack of chrome elements, and this means that text and typography are very important elements.
Tip: Make font labels and prompts legible and adequately spaced. The minimum font size on Windows Phone is 15 points.
Core elements typically use additional elements like borders and frames to craft the layout of content. Make sure you use a different font size, color, or style to create the needed hierarchy on screen so that the user can identify easily primary and secondary tasks.
Creating custom controls
While considering how your app content will fit or be displayed, don't create your own custom control until you've reviewed the design guidelines for the standard system controls in Controls.
Custom controls should be created only to make functions, tasks, or operations easier to complete or understand.
Consider using standard system controls as a model for operation in your custom controls. If your controls will be used during content viewing, make them discreet. Controls should fade out during full-screen viewing.
To provide a consistent experience throughout the Windows Phone platform, it's important to follow a common structure when you place buttons. This way, you provide a consistent and simple structure for users to navigate through.
It's also important to understand what the hardware and software will give you for free. For starters, every Windows Phone contains three steering buttons—Back, Start, and Search. Understanding how these buttons are used throughout the system can help prevent issues within the UI and flow of your app.
Home buttons and the back stack
Placing a Home button in your user interface is an exception to the typical navigation model. While innovating on the platform isn't necessarily bad, changing the expected interaction model of the platform can confuse users. The exception to this standard is when your app has been launched from a deep link and there is no back stack; in that case, some way to return to the top page is needed.
Implementing a Home button in your app may also cause a second issue, one that has a much more severe implications for your app: it might inadvertently create a scenario where a user can get stuck in an infinite (or near infinite) loop when he or she uses both your Home button and the hardware Back button to navigate. This loop may get worse if they use the Back button to move from one app back through your app just to get to another. Ensure that these issues don't affect your app.
All apps have a different interactive flow, some more complicated than others. However, try to keep the architecture of your app as shallow as possible, and make use of lists and pivots so that the user can navigate back to the landing screen with few steps back and from there to previous launched apps. When in doubt, try to mimic common elements and navigation structures already in the platform; you'll be less likely to confuse the user.
Back and close buttons
There should be no Back or Close buttons at all within your app UI. Windows Phone provides a physical Back button on every device so that you can keep your app's navigation clean and simple.
Incorrect: Back and/or Close buttons within an app
Floating buttons produce inconsistent, confusing navigation. Using an app bar is the best way to add commands to a page. For more information about the app bar, see Essential graphics, visual indicators, and notifications (Windows Phone Store apps).
If you can't place all your commands on the Application Bar, be sure to place them consistently within your UI. Variable placement may interfere with content browsing, and icons that are haphazardly placed may not even look like an interactive element to users.
The Windows Phone library of common controls provides a consistent approach to implementing command UI within your UI. Follow layout ideas suggested in Design resources for Windows Phone to achieve interaction that's common throughout the platform.
Search is built into the hardware and software of every Windows Phone. You cannot modify or change the behavior of the hardware Search button. For more info, see the "Search button" section in First Look at Windows Phone.
In Windows Phone, app settings are implemented within the app itself. You don't have access to place app settings within the System and Applications system settings.
Tip: Familiarize yourself with the system settings options and consider how various user settings could affect UI or app behavior. For example, if you're creating a web service–connected app, consider app behavior when the user puts the phone in Airplane mode.
For apps that have several user-selectable settings, you should create a settings page within the app and model it on the layout and behaviors in System and Applications system settings.
Model app settings pages after system settings pages.
Changes to app settings should be immediately applied. This means that a Done, OK, or other confirmation dialog is not needed. In some cases, even though the change has happened immediately, the user may not have feedback that the change has occurred until an ongoing event is completed or a future event occurs. For more info about providing feedback, see Animations, motion, and output for Windows Phone.
Keeping app settings brief and clear should be a design goal. Complex, multi-page, multi-level app settings can frustrate or confuse users into thinking that they've entered another app entirely.
Important Note: Avoid creating app settings that have more than two pages.
Also, remember the following:
- Settings that require more than a single screen should use overlying half screens to avoid losing context when the soft keyboard is displayed.
- If a task can't be undone, always provide the user with an option to cancel. Text entry is an example.
- Provide a Cancel button for actions that overwrite or delete data or are irreversible.
- If you're using additional screens with Apply and Cancel buttons, clicking those buttons should perform the associated action and return the user to the main settings screen.
- Provide an option to disable data usage in apps that fetch data over the network.
To keep the heading of settings control panels consistent, the heading for the settings page should look like the following:
<Control Panel Name/Application Name>
The following are basic guidelines for the minimum quality of advertising units in Windows Phone. As you review these guidelines, keep in mind that your ads also need to be consistent with the Windows Phone design principles.
When there are no ads to display, the AdControl will hide itself. Include code in your app to account for this case and reclaim the available space.
Recommended ad unit sizes
The default and recommended size for an AdControl is 480 x 80 pixels. This is the recommended size for ads in Windows Phone.
Even if your ad units were created using a format size of 300 x 50 pixels in pubCenter, set your AdControl size to 480 x 80 for a better user experience. Smaller ad unit formats will be centered within this space and rendered inside the AdControl by using the ad unit size set in pubCenter. For example, a 300 x 50 pixel ad will be displayed at 300 x 50 pixels, with the center of the ad unit located at the center of the AdControl. This configuration is displayed in the following figure.
Centered ad control
Tip: The 300 x 50 pixel AdControl size is included to maintain backward compatibility. It may be deprecated in the future. To avoid having to revise your ad units later, consider creating new ads in the standard AdControl size of 480 x 80 pixels.
Position the AdControl at the top of the screen or at the bottom of the screen. The recommended positions are at the top or bottom of a given view.
Ads that are included inside a scroll viewer will scroll on or off the page as the user scrolls through content. If you want the ads to remain stationary as the user scrolls, place the AdControl outside the scroll viewer. Place the scroll viewer at either the top or the bottom of the screen.
Using ads with a hub or pivot control
Ads that are included in a section inside a hub control—or in an item inside a pivot control—won't be in view as the user pans over to an adjacent section or item. To persist the ad across all sections or items, place the AdControl outside the control, as demonstrated in the following figures on the left. To show different ads on various sections or items, create a new instance of the AdControl within each section or item for each discrete ad, as demonstrated in the following figures on the right.
Ads in a hub control
Ads in a pivot control
Use system theme colors. If you change the theme colors, pick colors so that the AdControl border and text are still easily readable.