You might notice in the

You might notice in the table above that many of the gestures in the touch language don’t actually have a single event associated with them (like pinch or rotate) but are instead represented by a series of gesture or pointer events. The reason for this is that these gestures, when used with touch, typically involve animation of the affected content while the gesture is happening. Swipes, for example, show linear movement of the object being panned or selected. A pinch or stretch movement will often be actively zooming the content. (Semantic Zoom is an exception, but then you just let the control handle the details.) And a rotate gesture should definitely give visual feedback. In short, handling these gestures with touch, in particular, means dealing with a series of events rather than just a single one. This is one reason that it’s so helpful (and time-saving!) to use the built-in controls as much as possible, because they already handle all the gesture details for you. The ListView control, for example, contains all the pointer/gesture logic to handling pans and swipes, along with taps. The Semantic Zoom control, like I said, implements pinch and stretch by watching MSPointer* events. If you look at the source code for these controls within WinJS, you’ll start to appreciate just how much they do for you (and what it will look like to implement a rich custom control of your own, using the gesture recognizer!). You can also save yourself a lot of trouble with the -ms-touch-action CSS properties described under “CSS Styles That Affect Input.” Using this has the added benefit of processing the touch input on a non-UI thread, thereby providing much smoother manipulation than could be achieved by handling pointer or gesture events. On the theme of “write for touch and get other input for free,” all of these gestures also have mouse and keyboard equivalents, which the built-in controls also implement for you. It’s also helpful to know what those equivalents are, as shown in the table below. The “Standard Keystrokes” section later in this chapter also lists many other command-related keystrokes. Touch Keyboard Mouse Pen/Stylus Press and hold (or Right-click button Right button click Press and hold tap on text selection) Tap Enter Left button click Tap Slide (short distance) Arrow keys Left button click and drag, click on scrollbar arrows, drag the scrollbar thumb, use the mouse wheel Slide + inertia (long distance) Page Up/Page Down Left button click and drag, click on scrollbar track, drag the scrollbar thumb, use the mouse wheel Swipe to select Right-click button or spacebar Right button click Tap and drag Tap on scrollbar arrows, drag scrollbar thumb, tap and drag Tap on scrollbar track, drag scrollbar thumb, tap and drag Pinch/Stretch Ctrl+ and Ctrl- Ctrl+mouse wheel or UI command UI command or other hardware feature Swipe from edge Win+Z, Win+Tab, Win+C or Win+Shift+C Clicking on corners of the screen; right-click shows app bar Drag in from edge Rotate Ctrl+, and Ctrl+. Ctrl+Shift+mouse wheel UI command or other hardware feature 368

You might notice a conspicuous absence of double-click and/or double-tap gestures in this list. Does that surprise you? In early builds of Windows 8 we actually did have a double-tap gesture, but it turned out to not be all that useful, conflicted with the zoom gesture, and sometimes very difficult for users to perform. I can say from watching friends over the years that double-clicking with the mouse isn’t even all it’s cracked up to be. People with not-entirely-stable hands will often move the mouse quite a ways between clicks, just as they might move their finger between taps. As a result, the reliability of a double-tap ends up being pretty low, and since it wasn’t really needed in the touch language, it was simply dropped altogether. Sidebar: Creating Completely New Gestures? While the Windows 8 touch language provides a simple yet fairly comprehensive set of gestures, it’s not too hard to imagine other possibilities. The question is, when is it appropriate to introduce a new kind of gesture or manipulation? First, it makes sense that apps don’t generally introduce new ways to do the same things, such as additional gestures that just swipe, zoom, etc. It’s better to simply get more creative in how the app interprets an existing gesture. For example, a swipe gesture might pan a scrollable region but can also just move an object on the screen—no need to invent a new gesture. Second, if you have controls placed on the screen where you want the user to give input, there’s no need to think in terms of gestures at all: just apply the input from those controls appropriately. Third, even when you do think a custom gesture is needed, the bottom-line recommendation is to make those interactions feel natural, rather than something you just invent for the sake of invention. We also recommend that gestures behave consistently with the number of pointers, velocity/time, and so on. For example, separating an element into three pieces with a three-finger stretch and into two pieces with a two-finger stretch is fine; having a three-finger stretch enlarge an element while a two-finger stretch zooms the canvas is a bad idea, because it’s not very discoverable. Similarly, the speed of a horizontal or vertical flick can affect the velocity of an element’s movement, but having a fast flick switch to another page while a slow flick highlights text is a bad idea. In this case, having different functions based on speed creates a difficult UI for your customers because they’ll all have different ideas about what “fast” and “slow” mean and might be limited by their physical abilities. Finally, with any custom gesture, recognize that you are potentially introducing an inconsistency between apps. When a user starts interacting with a certain kind of app in a new way, he or she might start to expect that of other apps and might become confused (or upset) when those apps don’t behave in the same way, especially if those apps use a similar gesture for a completely different purpose! Complex gestures, too, might be difficult for some, if not many, people to perform; might be limited by the kind of hardware in the device (number of touch points, responsiveness, etc.); and are generally not very discoverable. In most cases it’s probably simpler to add an appbar command on a button on your app canvas to achieve the same goal. 369