Touch interaction design (Windows Store apps)
This topic describes the touch interactions for Windows 8 and provides guidelines for designing good touch interactions. For a handy downloadable version of this topic, go here.
- Use the Windows 8 touch language.
Windows 8 provides a concise set of touch interactions used consistently throughout the system. Applying this language consistently makes your app feel familiar to what users already know. This increases user confidence by making your app easier to learn and use.
- Use fingers for what they're good at.
A mouse and pen are precise, while fingers aren't, and small targets require precision. Use large targets that support direct manipulation and provide rich touch interaction data. Swiping down on a large item is quick and easy because the entire item is a target for selection.
- Browse content with touch.
Semantic Zoom and panning make navigation fast and fluid. Instead of putting content in multiple tabs or pages, use large canvases that support panning and Semantic Zoom.
- Provide feedback.
Increase user confidence by providing immediate visual feedback whenever the screen is touched. Interactive elements should react by changing color, changing size, or by moving. Items that are not interactive should show system touch visuals only when the screen is touched.
- Content follows finger.
Elements that can be moved or dragged by a user, such as a canvas or a slider, should follow the user's finger when moving. Buttons and other elements that do not move should return to their default state when the user slides or lifts their finger off the element.
- Keep interactions reversible.
If you pick up a book, you can put it back down where you found it. Touch interactions should behave in a similar way—they should be reversible. Provide visual feedback to indicate what will happen when the user lifts their finger. This will make your app safe to explore using touch.
- Allow any number of fingers.
People often touch with more than one finger and don’t even realize it. That's why touch interactions shouldn’t change radically based on the number of fingers touching the screen. Just like the real world, sliding something with one or three fingers shouldn't make a difference.
- Keep interactions untimed.
Interactions that require compound gestures such as double tap or press and hold need to be performed within a certain amount of time. Avoid timed interactions like these because they are often triggered accidentally and are difficult to time correctly.
This list describes the standard touch-related terms used in Windows 8.
Important To avoid confusing users, please do not create custom interactions that duplicate or redefine existing, standard interactions.
- Press and hold to learn.
This touch interaction causes detailed information or teaching visuals (for example, a tooltip or context menu) to be displayed without a commitment to an action. Anything displayed this way should not prevent users from panning if they begin sliding their finger.
- Tap for primary action.
Tapping on an element invokes its primary action, for instance launching an app or executing a command.
- Slide to pan.
Slide is used primarily for panning interactions but can also be used for moving, drawing, or writing. Slide can also be used to target small, densely packed elements by scrubbing (sliding the finger over related objects such as radio buttons).
- Swipe to select, command, and move.
Sliding the finger a short distance, perpendicular to the panning direction, selects objects in a list or grid (ListView and GridLayout controls). Display the app bar with relevant commands when objects are selected.
- Pinch and stretch to zoom.
While the pinch and stretch gestures are commonly used for resizing, they also enable jumping to the beginning, end, or anywhere within the content with Semantic Zoom. A SemanticZoom control provides a zoomed out view for showing groups of items and quick ways to dive back into them.
- Turn to rotate.
Rotating with two or more fingers causes an object to rotate. Rotate the device itself to rotate the entire screen.
- Swipe from edge for app commands.
App commands are revealed by swiping from the bottom or top edge of the screen. Use the app bar to display app commands.
- Swipe from edge for system commands.
Swiping from the right edge of the screen reveals the charms that expose system commands.
Swiping from the left edge cycles through currently running apps.
Sliding from the top edge toward the bottom edge of the screen closes the current app.
Sliding from the top edge down and to the left or right edge snaps the current app to that side of the screen.
Note Users can perform direct manipulations like the slide-to-pan, pinch-to-zoom, and turn-to-rotate interactions simultaneously and with any number of touch points.
Designing for touch is more than designing what’s displayed on the screen. It requires designing for how the device will be held (grip).
Typically, different people have a few favorite grips when holding a tablet.
The current task and how it’s presented usually determines which grip is used. However, the immediate environment and physical comfort also affect how long a grip is used and how often it’s changed.
Try optimizing your app for different kinds of grips. But if an interaction naturally lends itself to a specific grip, optimize for that.
Interaction areas: Because slates are most often held along the side, the bottom corners and sides are ideal locations for interactive elements.
Reading areas: Content in the top half of the screen is easier to see than content in the bottom half, which is often blocked by the hands or ignored.
Four most common grips: While there are many ways to hold a tablet, these four grips are most commonly used.
|Grip||Grip and interaction||Design considerations|
|One hand holding, one hand interacting with light to medium interaction||
|Two hands holding, thumbs interacting with light to medium interaction||
|Device rests on table or legs, two hands interacting with light to heavy interaction||
|Device rests on table or stand, with or without interaction||
Size vs. efficiency: Target size influences error rate
There's no perfect size for touch targets. Different sizes work for different situations. Actions with severe consequences (such as delete and close) or frequently used actions should use large touch targets. Infrequently used actions with minor consequences can use small targets.
People often blame themselves for having "fat fingers." But even baby fingers are wider than most touch targets.
The image on the left shows the width of the average adult finger is about 11 millimeters (mm) wide, while a baby's is 8 mm, and some basketball players have fingers wider than 19 mm!
Target size guidelines: Here are some guidelines for deciding how large or small to make your touch targets.
7x7 mm: Recommended minimum size
7x7 mm is a good minimum size if touching the wrong target can be corrected in one or two gestures or within five seconds. Padding between targets is just as important as target size.
When accuracy matters
Close, delete, and other actions with severe consequences can’t afford accidental taps. Use 9x9 mm targets if touching the wrong target requires more than two gestures, five seconds, or a major context change to correct.
When it just won't fit
If you find yourself cramming things to fit, it’s okay to use 5x5 mm targets as long as touching the wrong target can be corrected with one gesture. Using 2 mm of padding between targets is extremely important in this case.
Most people are right handed
Most people hold a slate with their left hand and touch it with their right. In general, elements placed on the right side are easier to touch, and putting them on the right prevents occlusion of the main area of the screen.
As you plan the UI and the interactions supported by your app, always keep in mind the wide range of abilities, disabilities, and preferences of your users. Following accessible design principles from the beginning helps make your app accessible to the widest possible audience. For more info on planning for accessibility, see Design for accessibility.
Build date: 5/14/2013