Designing Windows Store Apps for Perceptive Pixel Displays

Designing Windows Store apps for Perceptive Pixel displays

February 2014

Abstract This document provides guiding principles for designing the user interface of a Windows Store app for large-screen touch displays, such as 55-inch and 82-inch displays from Perceptive Pixel by Microsoft (PPI). The user experience on a large touch display differs in some significant ways from that on smaller screens. The design principles here help you create a Windows Store app that scales from a tablet computer to a large-screen display and provides a great user experience across the range of devices. This info applies to the following operating systems:

Windows® 8

Disclaimer: This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet website references, may change without notice. Some information relates to pre-released product which may be substantially modified before it’s commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. You bear the risk of using it. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. © 2014 Microsoft. All rights reserved.

Designing Windows Store apps for Perceptive Pixel displays - 2

Contents Introduction ...... 3 Who this document is for ...... 3 What this document covers ...... 3 The opportunities in large-screen touch displays ...... 3 Planning your app ...... 4 Identify your core scenarios ...... 4 Design your app for scaling ...... 4 Screen resolution ...... 4 User-experience patterns for large displays...... 5 Design principles ...... 5 UI placement ...... 5 App bar placement...... 5 Toast notification placement ...... 5 Dialog placement ...... 5 Navigation patterns ...... 6 Navigation layers...... 6 Semantic zoom ...... 8 Command patterns...... 8 Comfort zone ...... 8 Command placement ...... 10 Keyboard text entry ...... 12 Touch patterns ...... 15 Sizing gestures...... 15 Content page zoom ...... 16 Accept multiple-finger touch ...... 16 Stylus patterns ...... 17 Ink patterns ...... 17 Animation and visual patterns ...... 17 Use appropriate background colors ...... 17 Minimize excessive motion and animations ...... 18 Considerations for multiple simultaneous users ...... 20 Evaluating your apps...... 20 Windows Store app certification requirements ...... 21 Additional resources ...... 21 Appendix: Common programming tasks for working with large-screens ...... 22 Determining screen size and pixel density ...... 22 Determining app position...... 22 Detecting the PPI stylus GUID ...... 22 Detecting stylus button presses ...... 22

Introduction This document offers a set of guiding principles for designing the user interface (UI) of Windows Store apps for large-screen touch displays, such as the 55” and 82” displays from Perceptive Pixel by Microsoft (PPI). The success of such apps can hinge on how easily users can navigate them, run commands in them, or touch elements of their UI. Follow the principles here to design apps that scale well from tablet computers to large-screen displays and provide a great user experience across the range of devices and form factors.

Who this document is for If you’re a member of a development team that creates Windows Store apps for large-screen touch displays, this info is for you. Whether you’re a UI layout artist, a UI developer, or a developer responsible for crafting the view-model classes that power your app’s UI, you’ll find this document helpful.

What this document covers This document gives you a thorough, high-level overview of UI patterns specific to large-screen displays. That’s a fair amount of info, so we’ve not included detailed examples of the code required to accomplish these patterns. We also don’t address programming issues related to business logic or data access. The Appendix does offer a few suggestions about how to approach certain common coding tasks. But in general, we introduce you to the patterns and leave the implementation to you. We also don’t cover the basics of Windows Store app development. For info about that, see Additional resources.

The opportunities in large-screen touch displays Windows Store apps that follow Microsoft® design guidelines for Windows 8 work well on a large-screen touch display. To optimize the user’s experience, however, consider the form factors of a large screen device, laptop, desktop, or tablet. The size difference between a large display and smaller form factors can change the way users interact with the info on screen, see and use controls and notifications, and navigate the app. Its size, multi-touch capabilities, and stylus create many new opportunities for data presentation and manipulation, content creation, and collaborative scenarios. Figure 1 gives you an idea of the size difference we’re talking about.

Figure 1 – Large-screen touch display compared to a tablet.

The size of a 55” or 82” PPI display presents interesting challenges for Windows Store app developers like you. When writing apps for the large-screen display, you can no longer assume that users can easily touch any point on its surface the way they can with a tablet, laptop, or desktop touch display. When users of average height interact with a large display, they may not be able to comfortably reach edges of the display where app bars and charms appear. Sweep gestures that work well on a tablet can be quite difficult on an 82” display. Visually, a large display can present another challenge to users. Unlike with a tablet or desktop display, where a user can scan the whole surface at a glance, a user may have to deliberately turn and look at the edges of a large display to interact with cues as they appear. Because of this, a user who’s not already looking where an important app cue appears can miss it altogether.

Planning your app When you plan a Windows Store app for large displays, like the PPI 55” and 82” displays, you can achieve an ideal user experience if you build your app according to the design principles presented in this document. The Windows 8 app development guidelines are a good baseline for designing apps for a wide range of devices. However, there are some important differences when you scale these experiences up for large devices or down for tablets. See these guidelines for adapting to a variety of devices and form factors.

Identify your core scenarios As we’ve already seen, large-screen interactions are different from those on devices like tablets, laptops, or desktop computers. When planning your app, think about how people are going to use the features of the device to achieve their goals. Your large-screen app should let groups of people consume and interact with data shown by the app. This large-screen experience can be a continuation of the tablet, laptop, or desktop experience. Or it can be a new experience that is possible only when a group of people are working together.

Design your app for scaling As noted previously, scaling is an important consideration for apps intended to work on large- screen devices. As you build your app, remember that it may be used across a wide range of screen sizes and scenarios. Fortunately, the user-experience (UX) patterns that you use in Windows Store apps for large displays generally work well on a smaller scale too.

Screen resolution Windows Store apps are well positioned to run on displays of any scale. App content that is hosted by a Canvas control and contains vector graphics can scale easily without extensive UI logic. The PPI display resolution is 1920 x 1080. Set your development computer screen to a matching resolution so that you can be sure your app fills the screen. Smaller-scale devices such as desktop displays and tablets usually support lower resolutions. Avoid designing apps with fixed layout unless you cannot create an adaptive layout to manage screen space.

If you use vector graphics, XAML declarations, or design primitives in your app, your graphics will be sharp and attractive regardless of the resolution of the display. For more info about scaling your app for screen resolution, see Guidelines for scaling to pixel density. Take advantage of the layout testing tools in Microsoft Visual Studio, which offers a Windows Simulator that you can set to different resolutions to see how well your app responds to scale changes.

User-experience patterns for large displays Designing for large-screen devices introduces an additional set of UX pattern constraints for you to consider during development.

Design principles An excellent app for large-screen devices is one that anyone can use, regardless of physical stature. Above all, the UI elements in your app must be visible and touchable no matter what a user’s reach is. Implement navigation, command, and touch patterns that let anyone have a great experience in your app. Before starting to build your app, visit and review the five Microsoft design principles for building great Windows Store apps.

UI placement Think about how a large display’s form factor changes the functionality of common UI elements in Windows store apps.

App bar placement An app bar is a visual ribbon structure that can appear at the top of the screen to show app- navigation icons, or at the bottom of the screen to show page-content commands. Avoid placing a navigation app bar at the top of a large-screen device because it can be difficult for many users to reach. For info about alternative ways to show navigation icons, see Navigation patterns.

Toast notification placement When your app is not the active foreground app, it can use toast notifications. Open a toast notification when you want a user to return to your app to respond to an interesting event. If your app relies on toast notifications, remember that they always appear in the upper-right corner of the screen and may appear while a user’s attention is elsewhere. You cannot control the toast location, but you can control the duration of the toast display and the sound played when it appears. Making the toast stay open longer and playing a sound helps draw users’ attention when their field of view is elsewhere on the screen. For info about customizing toast notifications, see Toast notification overview for Windows Store apps.

Dialog placement Use a dialog box when your app is already active in the foreground. A dialog is usually a standard window whose size, format, and content are under the control of the developer. You can place a dialog anywhere on the screen, but it’s a good idea to open it in front of the active user. One option is to use touch events to keep track of where the user has most recently touched the display. When you display a dialog, place it in the vicinity of the user and on the upper half of the screen. In this way, the dialog is most likely to be visible to the user. Figure 2 shows two optimal places to show dialogs. If the user has most recently touched the right side of the

screen, open the dialog on the right half of the display. If the last touch was on the left side, open the dialog also on the left.

Figure 2 – Dialog box appears on the same side of the screen as the user, and at or above eye-level.

Navigation patterns Provide your large-screen device app with simple and understandable navigation patterns. Large screen devices are often used for presentation or brainstorming scenarios in shared spaces, and are not typically available for exploration by individual users. Individuals thus have little opportunity to learn a complex navigation pattern before using your app in a group setting. A user who is familiar with Windows Store app navigation patterns should be able to start and use your app effectively on the first try. Ensure that the adaptations you make to these patterns for the large screen are intuitive. Two recommended navigation patterns are a hierarchical pattern (using a layered hierarchy) and semantic zoom.

Navigation layers For a hierarchical pattern, hub pages generally work well for navigating apps on a large display. Building navigation into well-defined hierarchical layers is a common hub navigation pattern and is generally familiar to users. Make sure that each layer of the hierarchy is easily identifiable so people understand their location in the hierarchy quickly. Try to limit the number of layers so that users are never far from the app’s home page or hub. Consider ways to allow users to step immediately back to the home page if they are “lost” in the hierarchy. For more tips on building hierarchical systems, see Navigation patterns for Windows Store apps.

Figure 3 – The Hub navigation layout in use. The blue arrows represent available user sweep gestures.

Figure 4 – Layered navigation schema.

Semantic zoom Semantic zoom is appropriate for content that follows some order or categorization. Content can be displayed as “zoomed out” (with less detail) or “zoomed in” (by focusing on categories). This allows users to navigate through the content using pinch and stretch gestures. These gestures can be performed almost anywhere on the screen. Combined with panning or scrolling, most of the content is accessible by user gestures. For an app on a large device, this approach makes it easy for users to navigate through on-screen content without having to reach for a button or menu. In figure 5, a pinch gesture takes us from a “zoomed-in,” detailed view showing all available books in each genre to a “zoomed-out” view showing only the genres. For more info about using the semantic zoom navigation pattern, see Guidelines for semantic zoom.

Figure 5 – Semantic zoom pattern.

Command patterns Command patterns for large-screen devices share some of the core command design patterns with Windows Store apps. When developing an app for a PPI device, keep in mind that commands are usually invoked and activated by touch or stylus input. Don’t use commands that are available only by hovering or positioning the mouse, because users are not likely to have a mouse to access them. Because of the size of the PPI display, there are also other significant differences with command patterns to be aware of.

Comfort zone When designing command patterns, it’s essential to consider the size and orientation of the device. For command placement, think about user height as well as device size. Before adding an app bar to the top or bottom of your app, consider the impact that placement will have on users.

In figure 6, shaded regions represent areas where people of various heights can comfortably reach.

Figure 6 – The comfort and stretch distances for users of varying heights.

The larger, non-shaded regions represent areas where a person must stretch to reach. The person on the left side would have difficulty reaching a navigation app bar placed at the top of the display. It is better to place non-interactive content in areas such as the top of the display, which are beyond the comfortable reach of most people. If you decide to use the top app bar, size it appropriately so that its controls are within reach of all users. Controls at the bottom of the display can be tiring to use as well. A taller person may be forced to bend down to interact with such controls. In general, quick tasks and commands are suitable for the bottom of the display, while more complex interactions can be started from context menus shown close to the person’s most recent touch. We recommend that PPI displays be mounted on a stand so that the mid-point of the display is 55 inches above the floor. At that height, the control-placement guidelines in this document are effective in respecting a user’s comfort zone.

Command placement Command placement for large-screen devices differs significantly from that for tablet or desktop form factors. Large devices require more physical interaction than smaller ones do.

Figure 7 – Dynamic command placement, where controls appear on the bottom of the side that the user last touched.

Viewing angles The human eye has a limited field of view. Consider that before placing commanding controls.

Figure 8 – Viewing angles and characteristics.

A person standing at a device has a clear field of view of about 30 degrees. At the usual working distance of 10 to 20 inches, the clear field of vision is typically less than 12 inches in diameter. This small visual “cone of awareness” can make it difficult to see commanding controls or toast notifications that appear outside it. There are also simple but important ergonomics issues to think about. Most users stand between 10 and 20 inches away from the screen when interacting with it, providing a usable interaction circle that’s between 40 and 63 inches in diameter.

These visual criteria can also be applied more broadly to any content that the user will see, like videos and animations. During a presentation, users or the audience may be sitting in front of the display or standing to the side. Be sure to size and position your content appropriately within the user’s field of view.

Figure 9 – Working distances.

Proximal commanding To best accommodate both visual and physical characteristics, have your apps use command patterns that rely on contextual, proximal UI. Make it so users can invoke and dismiss these commands easily.

Figure 10 – The Microsoft OneNote context menu, an example of contextual, proximal UI.

When designing a proximal UI, think about the actual distance of the command placement. Remember that a pixel in a 1920 x 1080 PPI display is far larger than a pixel in a tablet display of the same resolution. A reasonable proximal UI on a tablet with a pixel-based offset can be two inches from selected content but would be more than six inches away on a large-screen device. Ensure that your app’s UI accommodates the increased pixel size for large screens.

Fixed commanding In cases where you don’t want proximal and contextual commanding, you can make fixed commanding generally easier for users to reach by placing it at or near the bottom of the screen.

Consider centering controls in the command bar to reduce the distance a user needs to reach to interact with them. As shown in figure 11, centering the controls in the middle of the app bar may allow a user to reach them without walking from one side of the screen to the other. Locating a set of related controls in the same general region on the screen reduces the amount of movement necessary for the user to complete a task. It also leaves controls in a predictable place and is generally convenient for users working directly in front of the display.

Figure 11 – Centered command buttons that can be easily reached from either side of the screen.

Presentation commanding A presenter tends to stand to the left or right of the display device to give the audience a clear view of presented content. In apps that specialize in presentation interaction, use command patterns that let the presenter access UI controls without crossing in front of the display. For example, as seen in figure 12, you can show commands on the left when the user is touching the left side of the screen and on the right when the user is touching the right. Also remember that users often subconsciously tap the area of the screen they’re referring to, especially when presenting. So make sure that this tapping does not trigger unintended functionality.

Figure 12 – Side positioning of commands in a presentation app.

Keyboard text entry Large-screen devices are especially optimized for touch and stylus interaction. They are less suited to touch-keyboard interaction for two reasons:

• Keyboard orientation and docking location. The orientation and location of the touch keyboard can result in a poor ergonomic experience for a user standing in front of the device. (Figure 13 shows the typical screen placement of the keyboard.) In general, then, avoid keyboard commanding on large-screen devices. You can make an exception to this rule for the entry of short text strings such as partial names for a search.

Figure 133 – Typing on a vertical surface presents ergonomic challenges.

• Security. The touch keyboard is inappropriate for input of passwords and other sensitive info on large-screen devices, because the size and often public nature of these devices makes it very easy for other people to see the input.

Figure 144 – The height of the virtual keyboard relative to user reach areas on the 82" PPI display.

For apps that require text input, explore alternative methods of input that don’t rely on the touch keyboard. Good options to consider: • Wireless keyboard. This is probably the most natural and accurate text-input method for users. However, users may have to step away from the screen to find and use the keyboard. • Speech-to-text. A benefit of this method of input is that a user does not have to leave the screen to enter text. You can use Bing Speech Recognition to implement speech-to-text.

Figure 155 – Speech-to-text as another alternative method to on-screen keyboard input.

• Ink-to-text. Like speech-to-text, the user doesn’t have to leave the screen to input text using this method. Ink-to-text may be useful if your app’s experience involves a lot of stylus usage. The Windows 8 touch keyboard offers an ink-to-text input mode, which you can explore and use as a guideline for designing your app’s own ink-to-text functionality.

Figure 16 – Ink-to-text character recognition.

• Connected peripheral apps. Using a mobile device or laptop for input might be appropriate only under certain circumstances. If your large-screen enabled app includes a companion app on a mobile device or PC, you can consider using its keyboard for input.

Figure 177 – Connected peripherals like a laptop, a wireless keyboard, or a phone as forms of alternative input.

Touch patterns Touch patterns for large-screen devices generally follow Windows Store app development touch patterns. As with command patterns, there are some differences to be aware of.

Sizing gestures In interacting with an app on a large screen, a user may have to exert more physical effort to perform a touch gesture or invoke a command by touch. On a tablet, a gesture that requires a two to three-inch finger swipe may translate to a swipe of 9 inches or more on a large-screen device. Have your app account for this difference if it defines scale-gesture thresholds based on pixels. To minimize required gesture distances, scale gestures by distance instead of pixels. This lets users work within their own comfort zone on a large display. The DisplayInformation class in the Windows.Graphics.Display namespace provides you with the current pixels-per-logical inch value for the display your app is using. Learn about DPI and Device-Independent Pixels before defining the gesture threshold for your app.

Figure 18 – The effect of device scale on a swipe gesture.

Content page zoom Another approach to keeping controls within reach is to let users move window content or controls closer to themselves. One option, shown in figure 19, is to let users pull a page edge away from the far side of the screen and closer to themselves instead of walking across the screen to reach the far side of the page. Also keep in mind that zooming is often disorienting on a large display, so try to limit zooming animations unless you’re using semantic zoom.

Figure 19 – Users can pull the page content closer to where they are standing.

Accept multiple-finger touch People often touch the screen with more than one finger and don’t even realize it. This is especially true for large-screen devices. For example, many users will inadvertently use multiple fingers to pan the Windows 8 Start screen. This causes the Start screen to jitter because the gesture recognizer interprets the touch gesture as both a pan and a zoom. A person may touch with multiple fingers to move large objects because of their perception of the inertia of the large object. When designing gesture-detection logic, consider situations when multiple fingers are used to actuate the gesture. Make sure your logic doesn’t mistake a multi-touch slide for a combination of slide and zoom.

Figure 20 – A sample trace of a multiple-finger gesture on a large screen, intended to pan displayed content.

Stylus patterns All PPI displays come with touch and pen functionality. Consider what features your app offers and whether the stylus is appropriate for those features. The stylus is often used as if it were a similar real-world tool, like a pen or brush. Actions that require pinpoint accuracy may also be appropriate for a stylus. Because of these principles, common uses of the stylus include inking and content creation, but it can also be used for a variety of other functions. Touch is generally used for object manipulation and basic control. The stylus typically does not cross over to these functions, and is reserved for functionality and experiences that touch cannot already provide or enhance. For example, the stylus can activate common contextual ink controls while inking. A user should be able to tap command menu bars or contextual menus by using either touch or a stylus. You can also take advantage of stylus buttons to change the mode of the stylus, or to invoke contextual stylus commands. For stylus code samples, see Detecting the PPI stylus GUID and Detecting stylus button presses. By introducing a stylus, you also change the experience of interacting with the display. While planning your app, consider how users will react to using both touch and stylus. Users may find it difficult to switch between two modalities if it’s not clear when to use pen or when to use touch. If the stylus becomes the main experience, users may be inclined to ignore touch and try to use the stylus for functions that it’s not intended for. Take advantage of the user’s preconceptions and intuition around what touch and the stylus can do to make the stylus experience blend well with the touch experience.

Ink patterns If your app supports inking or other kinds of drawing, it’s suitable for a stylus. When inking, make the stylus ink seamlessly every time it’s brought to the screen, and make touch the way to manipulate objects and actuate controls. Make these default behaviors that the user doesn’t have to enable. For example, the user should not have to press a button to enable the inking mode in the stylus. However, an exception to this stylus use pattern can be made when a PPI stylus is not present. The portable nature of a stylus means that it may occasionally be misplaced. In this case, let the user change touch gestures from a content-manipulation mode to a “finger painting” mode. This mode switch allows users to ink with touch and to complete their inking scenario even if the stylus is missing.

Animation and visual patterns When a large display is used to present content to an audience in a meeting or conference room, you can improve viewers’ experience by following guidelines for large-screen visual effects.

Use appropriate background colors On large-screen displays, stark white backgrounds can be too bright and uncomfortable to look at for any length of time. Due to the size of the display, sudden shifts to a large white expanse can cause users to be temporarily blinded while their eyes adjust—it’s like stepping out of a dark room into a bright space. The closer a viewer is to a bright white display, the more uncomfortable the experience is. And for the presenter the experience can be overwhelming. On the other hand, an entirely black screen makes it hard to know whether the large-screen device is even on, and can highlight smudges and fingerprints on the surface of the screen.

Figure 21 – Bright white, especially in a darkened room, can overwhelm the viewer’s eye.

Use a light shade of grey instead of a white background. Without a comparison point, users often don’t realize that the background is not pure white. A dark shade of grey can be used in place of solid black. These alternatives make the display much more pleasant to look at for a longer period of time. Testing has shown that RGB(213, 213, 213) as a light-grey replacement for white, and RGB(84, 84, 84) as a dark-grey replacement for black, function well when used as the background canvas color for content-creation scenarios.

Figure 22 – A pleasing subtle gray background significantly reduces the blinding effect.

Minimize excessive motion and animations Watching a motion-intensive app on a large-screen display can cause queasiness and disorientation for an audience. You can reduce this effect by designing your app to minimize motion from panning and animation.

Content panning and zooming Panning or zooming content that moves across the entirety of a large screen can cause discomfort, especially if it moves too quickly or does not move analogously to a user’s gestures. When being panned or zoomed, content should not move excessively beyond the user’s control. While a user performs a gesture, content should slide along with it, following the user’s finger. As soon as the user’s fingers leave the screen, movement should stop or slow down to a stop. If the content continues to move excessively after the gesture is performed, the effect can be disorienting to both the user and observers of the screen.

Figure 23 – Fast, uncontrolled movement across the screen can cause motion sickness.

The Windows 8 Maps app demonstrates sliding and zooming. With this app, both pan and zoom gestures stick to the user’s finger during the gesture, and the map remains in place after the gesture is complete. Before creating your app, become familiar with Guidelines for panning in Windows Store apps. The Maps app is an example where physical zooming and panning are both needed and appropriate. In many cases, however, using these actions in excess can cause discomfort.

Animation Animations that run across a large portion of the screen are unpleasant to look at and can cause queasiness. Typically, unbounded motion in both the horizontal and vertical direction are responsible for most animation issues. Parallax effects can also be disconcerting. Moving several objects across different parts of the screen may be disorienting when standing close to the display and within the user’s field of vision. To reduce motion sickness, limit motion that spans large parts of the display. Here are some tips: • When you do have to move an object across the screen, start the motion at a fast speed and cover most of the distance quickly. Then have the object decelerate toward the end. • To limit the distance traveled, avoid making the object move all the way from one edge of the screen to the other. Instead, have it start some distance in from the far edge and stop some distance from the near edge. • An animation that includes abrupt direction changes after a movement starts is especially disconcerting. Instead, use linear motion. • When panning, try to make the motion analogous to the user’s movement: if the user performs short, slow movements, have the content also move a short distance slowly. Showing your animations on a large screen in front of an audience can be a good way to test whether excessive motion occurs.

Considerations for multiple simultaneous users PPI devices are often placed in a setting where they’re publicly used by several users at the same time. Consider the following unique aspects of creating an app for a PPI device: • The larger 82" PPI device lets multiple people use the app at the same time. • 100 simultaneous points of touch are supported by Windows 8, but the user who performs each touch cannot be identified. • Multiple controls can be activated simultaneously by different users. • Multiple users can make global conflicting gestures on the PPI display simultaneously. • While using your app on a PPI device, users may want to save content originated in your app or they may want to bring their own content to share with others. Consider having users sign in using a Microsoft account to claim and retrieve content. • Users may not have time to learn how to use your app in a communal setting. Use good design so that users do not need to search for help. If you address these considerations, it will likely improve users’ experience with your app in a simultaneous, multiple-user situation.

Evaluating your apps Consider the following criteria to evaluate your apps for use on large screens. These criteria reflect the concepts covered elsewhere in this document, and they all link back to those concepts for further info. Planning your app

Scaling your app

The app scales well for both large-screen and small-screen devices.

User experience patterns for large displays Navigation patterns

Reliance on the top app bar is minimal.

Toast notifications and dialogs are noticeable but not disruptive.

App workflow and features are intuitive: someone can use the app without spending much

time learning its structure.

Hierarchical navigation layers are few and well defined.

Users can return to an app’s “home” or “hub” experience from anywhere.

Command patterns

Controls are visible from any user’s location and field of view.

Controls are accessible to users of various heights.

Proximal commanding: controls are easily invoked and dismissed, and are accessible from □ where the user has touched the screen.

Fixed commanding: controls are accessible from the bottom app bar.

Presentation commanding: controls are placed appropriately for users in the presentation

scenario.

Keyboards and other input methods are considered for long-form input.

Touch patterns Gestures are appropriately scaled for a large screen, accounting for distance and physical

effort.

Multiple-finger gestures are interpreted as single-finger gestures where appropriate.

Stylus patterns

The stylus is considered a supplement to touch and its functionality is used appropriately.

The stylus is used only for command initiation in proper context.

When inking, switching between touch and stylus is seamless and does not require the user

to set an app to ink or touch mode. Animation and visual patterns Videos or animations are sized and positioned to be visible to the audience from any

perspective.

Light and dark shades of grey replace bright white and deep black as backgrounds.

Excessive motion, sudden color shifts, and wide-spanning animations are avoided.

Communal considerations Multi-user experience is accounted for and multiple simultaneous streams of input do not

conflict.

Users can save content created on the device or access their own content for sharing.

Windows Store app certification requirements The design principles in this document help guide your development of Windows Store apps that work great on large-screen displays. To publish your app in the Windows Store, though (regardless of how you have evaluated your app for large-screen usability), remember that it must meet the Windows Store certification requirements.

Additional resources Here are links to some further reading and sample code: • Guidelines for window sizes and scaling to screens (Windows Store apps) • How to develop Windows Store apps • Scaling according to DPI sample

Appendix: Common programming tasks for working with large-screens This appendix offers a few details about programming tasks common to app development for large-screen displays.

Determining screen size and pixel density When designing or changing your app to work better on a large screen, you may want to know the size of the screen. You can use the resources in the DisplayInformation class to determine whether your app is working on a large screen and how to scale your app appropriately for that.

Determining app position Windows 8.1 introduced two API properties that help apps determine whether they’re snapped to the left or right edge of the screen: • Left edge detection: http://msdn.microsoft.com/en- us/library/windows/apps/windows.ui.viewmanagement.applicationview.adjacenttoleftdispl ayedge • Right edge detection: http://msdn.microsoft.com/en- us/library/windows/apps/windows.ui.viewmanagement.applicationview.adjacenttorightdis playedge.aspx

Detecting the PPI stylus GUID It should be possible to get the GUID associated with the stylus and have it remain constant. To ensure that the stylus GUID does not change, inspect the raw human interface device (HID) stream to get the raw input device data. Check the HasUsage method of the PointerPointProperties class to see if it has the PPI wireless ID GUID. After you’ve verified that the property exists, use the GetUsageValue method to retrieve the value. If you don’t do the HasUsage check first, you may get an exception. Here’s an example that shows how to detect the PPI stylus GUID.

string FindPenGUID() { PointerPoint pt = e.GetCurrentPoint(InkCanvas); string PenGUID = "PEN"; if (pt.Properties.HasUsage(0x0006, 0x22)) PenGUID = pt.Properties.GetUsageValue(0x0006, 0x22).ToString(); return PenGUID; }

Detecting stylus button presses You can retrieve stylus button presses from the properties of a PointerPoint object. Typically, the second button on the stylus is used for erasing when the stylus is in inking mode. However, the buttons’ functions can be changed appropriately if your app uses the stylus for purposes other than inking.

This example code shows how to retrieve stylus button presses. public void OnCanvasPointerPressed(object sender, PointerRoutedEventArgs e) { PointerPoint pt = e.GetCurrentPoint(cmGrid); If (pt.IsBarrelButtonPressed) // Front rocker button { // Actions for front rocker button } If (pt.IsEraser) // Back rocker button { // Actions for back rocker button } }