Posts Tagged ‘touchscreen’

Double-tap interactions

While click events are seamlessly supported on touch devices, double-click events are not and there is no equivalent double-tap event available. However, double-tap interactions can be captured by listening for multiple, subsequent touchend events. The code below shows how to do this, with the basis for a double-tap being:

  • Two touchend events, on a certain element, both occurring within a certain time interval (300ms)
  • Two touchend events, on a certain element, both occurring within a certain distance from each other (24px)

I’ve come across a lot of code that addresses the first point (see double tap on mobile safari), but the second point is just as important because almost all touchscreens are multitouch and a two-handed posture with a phone or tablet is not uncommon. With a two-handed posture, and an element large enough to span the screen, it’s easy to hit two different areas of the element (on opposite ends of the screen) in rapid succession – a double-tap would be detected, even though two distant points on the element were touched, unless the distance between the points is taken into account.

Ideally, both the interval and distance should be user-defined settings at the device/operating-system level, similar to the way setting the double-click speed is, but lacking such support, hacking it in at the application-level is the only viable option.

// Handler for when a double-tap (on a touchscreen) or double-click (with a mouse) is detected
var dblTapHandler = function (x, y) {

// Do stuff...


function() {

// Listen for double-click events for desktop/mouse-based interactions
$('.ia-dbltap-area').on('dblclick', function (e) {
// Call handler
dblTapHandler(e.pageX, e.pageY);

// Listen for touchend events for touch-based interactions
$('.ia-dbltap-area').on('touchend', function(e) {

var dblTapRadius = 24; // radius (in pixels) of the area in which we expect the 2 taps for a double-tap
var dblTapSpeed = 300; // interval (in milliseconds) in which we expect the 2 taps for a double-tap

if(e.originalEvent.changedTouches.length <= 0) {
return false; // we have nothing to work with

var dblTapDetected = false; // flag specifying if we detected a double-tap
var areaElem = $(this); // element in which this touchend event has occured

// Position of the touch
var x = e.originalEvent.changedTouches[0].pageX;
var y = e.originalEvent.changedTouches[0].pageY;

var now = new Date().getTime();

// Check if we have stored data for a previous touch (indicating we should test for a double-tap)
if('last-touch-time')) {

lastTouchTime =

// Compute time since the previous touch
var timeSinceLastTouch = now - lastTouchTime;

// Get the position of the last touch on the element
var lastX ='last-touch-x');
var lastY ='last-touch-y');

// Compute the distance from the last touch on the element
var distFromLastTouch = Math.sqrt( Math.pow(x-lastX,2) + Math.pow(y-lastY,2) );

// Check if:
// 1. If the time since the last touch is within the specified double-tap interval (dblTapSpeed)
// 2. The distance from the last touch is within the specified double-tap radius (tapRadius)
if(timeSinceLastTouch <= dblTapSpeed && distFromLastTouch <= dblTapRadius) {

// Flag that we detected a double tap
dblTapDetected = true;

// Call handler
dblTapHandler(x, y);

// Remove last touch info from element'last-touch-time', '');
'last-touch-x', '');
'last-touch-y', '');


if(!dblTapDetected) { // A double-tap wasn't detected

// Store time and position of this touch on the element
// (Next touch may be a double-tap, we can use this info to determine if it is)'last-touch-time', now);
'last-touch-x', x);
'last-touch-y', y);



The demo below shows the code in actions along with a bit of SVG to render where the user double-clicked or double-touched div.ia-dbltap-area:

Beginning of the end for the laptop

Something I said a few months ago in a previous post,

…tablets are a new form of computing devices, one poised to become more powerful and user-friendly than the netbook/laptop form…

I mentioned the JooJoo in that post, but the iPad pretty much demolished any chance the JooJoo had at success.

The iPad itself has done phenomenally well and my optimism for tablets seems to be shared by the general public. Despite lackluster first impressions of the iPad on tech sites when it was announced, the iPad has managed to sell at a staggering rate (2 million sold, 2 months after going on sale).

My prediction of the tablet overtaking the netbook and laptop form-factors seems to be coming true as well; from the Wall Street Journal,

…internal estimates [at Best Buy] showed that the iPad had cannibalized sales from laptop PCs by as much as 50%.

Nice summary at SAI.

The end of :hover

Interesting post on the realization that :hover (in CSS, this defines what occurs when the mouse is over an HTML element) is no longer viable for layout on touchscreen devices.

When I sat down to a redesign of the Gameplan2 admin interface I suddenly came to a realisation, :hover doesn’t work. It’s entirely possible I’d skim read this somewhere, but somehow the implications for my design work had passed me by until I saw an iPad in use.

I came to the same realization when designing the Ekkio web client, and realizing I couldn’t open the file and folder submenus on my Palm Pixi.

Ekkio web client submenu

The arrows on the left would only appear when the user hovered over a file or folder. The solution, as shown, was to always show the arrows, but make then a lighter shade; on hover or when the dropdown is open, the arrows become a darker shade. This works well, despite the visual clutter of the arrows always being visible.

I agree with Croll’s conclusion,

So my proposition is this: :hover as an web interface design tool going forward is going to be less and less important.

I see :hover (and javascript mouse events such as onmouseover, for that matter) being unused or used only for non-essential stuff, such as added visual flair.

On a related note, touchscreen also don’t allow viewing the alt-text when hovering over an image. This is probably not a big deal when it comes to web layout, but it sucks for reading xkcd.