Interactions and usability with Windows Phone

아티클
11/23/2015

[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]

The following topics discuss the implications of how layout affects 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 a Windows Phone app in Design resources for Windows Phone.
Read about system standard controls in Controls design guidelines for Windows Phone.

This topic contains the following sections.

Touch targets and text

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.

Size requirements

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.

If the visual size equals the target size, you can add padding between controls to making the controls look easier to hit. Try to make the user feel comfortable.

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 mistaps 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 diagram

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. These are indicated by the Red Lines in the common controls Style guide.
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 Tile design guidelines for Windows Phone.

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:

Shape
Location
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.

Exceptions

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.

Soft keyboard

If all else fails, try not to have too many adjacent hit targets around a small hit target.

Too many adjacent hit targets

Minimum text size

Size and placement of typographical elements are crucial to forming the screen layout. The foundation of the Windows Phone visual style is the lack of chrome elements, and this means that text and typography bear more importance on Windows Phone than in other Microsoft platforms. The minimum font size on Windows Phone is 15 points.

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

Review the Controls design guidelines for Windows Phone section to consider how your app content will fit or be displayed before creating your own custom control for a page.

Custom controls should be created only to make functions, tasks, or operations easier to complete or understand.

Consider using system standard controls as a paradigm for operation in your custom controls. For example, consider using graphical elements that operate as buttons, check boxes, and other controls. If your controls will be used during content viewing, make them discreet. Controls should fade out during full-screen viewing.

Buttons

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 hardware 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 deviates from the Windows Phone navigation model. While innovating on the platform isn’t necessarily bad, changing the expected interaction model of the platform can confuse users.

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.

Basic Back button

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.

Floating buttons

Floating buttons produce inconsistent, confusing navigation in Windows Phone apps. Using the Application Bar is the best way to add actions on a particular page. For more information about the Application Bar, see Essential graphics, visual indicators, and notifications for Windows Phone.

Floating buttons

If you can’t place all your icons 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 icons and buttons within your UI. Follow layout ideas suggested in Design resources for Windows Phone to achieve interaction that’s common throughout the platform.

Using search

Search is built into the hardware and software of every Windows Phone. You cannot modify or change the behavior of the hardware Search button; when pressed, it will always launch the Bing search experience for the user to find content from anywhere on the device.

In select system apps such as Outlook, the hardware Search button launches an in-app search.

You can’t replicate in-app search, but you can mimic an in-app Search button by using the SearchTask class.

Present settings in the standard way

In Windows Phone OS, app settings are implemented within the app itself. You don’t have access to place app settings within the system and system app 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 system app settings.

Model app settings pages after system settings pages.

Changes to app settings should be immediately implemented. 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.

Immediately implement user-selected app settings without a confirming dialog box and provide a feedback method to indicate that the change has occurred.

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 SIP keyboard is displayed.
If a task can’t be undone, always provide the user with an option to cancel. Text entry is an example.
Supply a Cancel button for actions that overwrite or delete data or are irreversible.
If you’re 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.
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:

Application Settings

<CPL Name/Application Name>

In-app advertising

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 the Windows Phone 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.

Ad positioning

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.

Full-sized AdControl

Scroll viewer

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 the panorama control

Ads that are included inside a panorama control won’t be in view as the user scrolls horizontally to the next page in the panorama control. To persist the ad across all pages, place the AdControl outside the panorama control, as demonstrated in the following figure on the left. To show different ads on various panorama pages, create a new instance of the AdControl within each panorama page for each discrete ad, as demonstrated in the following figure on the right.

Ads in a Panorama control

Using ads with the pivot control

Ads that are included inside a pivot control will not be in view as the user scrolls horizontally to the next page in the pivot control. To persist the ad across all pages, place the AdControl outside the pivot control, as demonstrated in the following figure on the left.

To show different ads on the different pivot pages, create a new instance of the AdControl within each pivot page, as demonstrated in the following figure on the right.

Ads in a Pivot control

Colors

Use system theme colors. If you change the theme colors, pick colors so that the AdControl border and text are still easily readable.

다음을 통해 공유