�ݺ�ߣ

Editor's Notes

• #3: To do that, I’d like to start with a“mr obvious” slide. Unless you have been living under a rock for the past 5 years, its been obvious that mobile browsing is growing at a tremendous rate.This year marks the inflection point where more people are touching web pages than clicking them. This fact is compounded by the fact that we’re adding touch to desktop browsing as well.All of this adds up to touch being the dominant way people will use the web over the next 5 years.This means that we need to rethink both some of the technical and design considerations that we’ve been using on the web for the last two decades.
• #4: The first of these is that in a browsing world where there are diverse mechanisms for selecting elements – and not just a mouse -- we need to rethink our UI techniques to make sure they are effective.One good example of this is hover. Its very difficult to express a hover with a pointing device like a finger that essentially either is touching or isn’t.Hover is an example of something that doesn’t translate to the touchable web.
• #5: Also need to rethink the size of our touch targets.Mouse -> fine grain control, Touch -> less control8mm to 19mm with 11mm average finger sizeSurface research: Touches below 5mm: More mistakes and more time7-9mm targets or 40 to 50 pixels idealSo as you design your applications, make sure you’ve considered touch sizeWe also need to rethink the size of our targets. With a mouse you have very fine control over the position of what you were pointing at and we were able to get away with small targets.We did research on this as part of building the Surface around the impact of target size on usability with touch.The human finger ranges in size from 8mm from to over 19mm for the largest hands and the average is 11mm.We set up an experiment where we used targets of various sizes and measured the number of missed taps.What we’ve found was that targets that are smaller than 5mm on-screen have asymptotically more missed taps.The other thing that we found is that users spend much more time trying to press touch targets under 5mm, so between the two of these factors, it took a user much more time to accomplish a given task.Our results were that somewhere between 7mm and 9mm was ideal for touch target sizes or between 40-50 pixels on a typical resolution screen.So when you are building your touch targets for your application, make sure they are big enough for touch.
• #6: Reconsider where you place most frequently used targetsExperiment where we captured hand reach: green is comfortable for small hands, red largeMiddle left and right are the sweet spotsAnother important thing to reconsider is where you place the most frequently used targets in the user interface.We did another experiment where we captured the span of people’s hands using the device.In this image, green are the areas that were universally reachable across hand size and red indicates the areas that are easy only for the largest hands.So targets that are in the middle right and left sides of the screens are the easiest for users to use with touch.
• #7: Based on this, here is the way our designers weight where place touch targets and reading areas on the screen for different devices.Interaction areas should be where its easiest for hands to reach and the most critical information should be at the top of the screen where it is not obscured by hands.
• #8: People bring their expectations from using native touch enabled applications to the web.Current mouse event model doesn’t easily enable multitouch.One of the other expectations that people have from using native applications is that they will be able to use the same multipoint gestures from the web. But here we run into a problem, as current mouse events don’t enable us to handle multiple pointing devices at once. Or said another way, we don’t currently have web applications that perform like native ones because this interaction model is very difficult.
• #9: Joint proposal with Mozilla on Pointer Events to the W3CProvide an event model that supports touch and beyond.Moved from first public working draft to candidate recommendation -> 5 monthsTo work towards solving this, the Internet Explorer team at Microsoft proposed PointerEvents with Mozilla to the W3C working committee. The goal of this proposal to enable multiple input types using a unified and expanded model for those input events.This specification has moved from First Public Working Draft to Candidate Recommendation in 5 months, a pretty fast pace for a proposal like this, which I think indicates how recognized it is as a problem.
• #10: Pointer Events are an evolution, not a revolution.Meant to be drop in replacement for mouse events.Addition: pointercancel: for screen orientation changes / accidential input.This proposal is modeled after MouseEvents that we’ve been using for years.All of the MouseEvents are includedAll of the properties from MouseEvent are included with one new event, pointercancel, for handling events like screen orientation changes or accidental input where the previous input should be cancelled.
• #11: Expands the set of attributes availableStill have the existing set of attributes Let’s look at each of theseThePointer Events proposal also expands the set of attributes available in these events to enable richer applications while still supporting the existing mouse events.
• #12: Pointing devices in the real world have a width and height.Pointerevents will contain the width and height of the point of contact of the pointer. This enables you to reason about how much error there is in their selection and/or their intent in their gesture. A fingerpainting application is good example of how you’d use this data to build a better application.
• #13: Pointing devices have pressure and tilt in the real world.Enables richness like varying stroke based on tilt.Likewise, the pressure or tilt may be important contextual information for how to interpret a gesture.For a pen, the tilt dramatically changes the way the tip draws on the canvas in a real world, so having this information in the virtual one allows you to replicate that.
• #14: Usually want to handle pointers the sameBut you can use pointerType to handle them differently.There can also be multiple pointer devices in use at once (two fingers)pointerId lets you tell them apartInmany cases, you’ll probably want to handle these pointer events in the same manner.There are cases, however, where you might want to handle pointer devices differently. The pointerType attribute allows you to do that.
• #15: Show this on Surface RT.Switch to IEShow paint.html onGitHub (http://github.com/timfpark/PointerPaint) Explain canvas-actionShow event listeners Show paintRun itLet’s try to use multitouchOoopsWhat we need to do use pointerId to disambiguate the different streams of touch eventsOpen paint-with-multitouch.html on GitHubShow managing separate streams of pointer events.DemoBut its so flat, no width or height depending on the amount my finger is pressing.Open paint-with-width-height.html on GitHubShow width/height code.Demo
• #16: So how to get started.