An Event Apart: Touch Events

In his Touch Events talk at An Event Apart in Seattle, WA 2012 Peter-Paul Koch talked about touch support in mobile browsers and how to handle touch events in Web development. Here's my notes from his talk:

Mobile browsers

Mobile browsers that support touch events (in order of excellence).

Safari: Safari is the best mobile browser in the World. Only small differences between desktop, tablet, and mobile versions of Safari.

Blackberry WebKit on BB Torch OS7: Blackberry v5 browsers supported Javascript but so poorly that it might as well not be supported.

Samsung Dolfin on bada

Opera Mobile 12 on Android 3: is not Webkit based.

Android Webkit on Android 2.2 and 3: has had limited resources and has lots of bugs. The browser is also fragmented across devices and carriers.

Firefox 8 on Android 3

UC 8 on Android 2.3: the most popular browser in China. Overall, not a good browser but does have a lot of local marketshare.

IE 9 on the Windows Phone does not support touch events. Neither does Palm’s WebOS.

Interaction Modes

We used to have only one interaction mode: the mouse. We spent a lot of time trying to use mouse actions to adjust interfaces but not a lot of useful things came from that.

Then we adjusted scripts to cover keyboard interaction modes (accessibility)

Today we have a third interaction mode: touch. How do we adjust scripts to work with touch?

Touch Events

It’s all about events. A Javascript event fires when a user does something. You can attach actions to these events.

Touchmove: continues firing as a user’s finger is on the screen. It also continues to fire when you move outside the element the event handler is on. It’s complicated to figure out whether the user has left the element.

A touch event contains: touches array (contains all current touches), changed touches (all touches that caused an event to fire), target touches (only the touches on the target element)

Supporting Modes

We have three interaction modes to consider and three sets of events. Sometimes they all need the same approach, sometimes a completely different one.

Same approach: drag and drop is easily translated between mouse and touch. It’s the same concept.

How do you decide which event trail to use? If a touch event occurs, you are certain your user is on a touch device. So if touch start event fires, you can remove all mouse events.

Mouse and touch events are equivalent but that doesn’t mean they are the same. Area, pressure, and mutlitouch are distinct to touch events. Area and pressure are not supported now.

Multitouch has the most browser compatibility issues. It does not work in Android browser, Blackberry Webkit on phones, Firefox mobile, etc.

You cannot port multi-touch to mouse or keyboard events. They only have one interaction point.

Event Cascade

Simultaneous modes can happen (mouse and keyboard events firing at the same time) on older mobile devices.

On a touch device, mouse events still need to be supported because a lot of Web sites depend on them.

Events happen in this order: touch start, mouseover, mouse move (one), mousedown, mouse up, click, :hover styles applied. This sounds complicated but it isn’t. In general, you only use one of these events. Problems can occur when you use both mouse up and mousedown.

There is no equivalent to mouseover and mouse out events. It’s possible to detect a finger above the screen but even in this case your finger obscures the screen.

All our hover-based interactions have to be rethought.

Stick with Click

Click is the wrong name for the event. It should be called activate. It always fires whether you use keyboard, mouse and touch.

Clicks are slow on touch screens because they can mean lots of things: tap, scroll, zoom, press, etc. The only way to find out is to wait (for 300ms). This means there’s a delay in click actions.

Fire scripts ontouchstart instead of on click. If you do this, you are now responsible for making sure the user can zoom and every other action. Don’t do this.

Some touch solutions can’t be ported to a mouse.

Your site should be best viewed in any interaction mode: mouse, keyboard, touch, remote control, speech,

To set up a testing lab: Save $100 a month for devices. Buy a non-iPhone, non-Android device. Buy a non-touch screen device. Buy an android from a different vendor. Install opera Mini. Swap devices with other freelancers in your area. Coordinate with them when buying new devices.