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...

}

$(document).ready(
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(areaElem.data('last-touch-time')) {

lastTouchTime = areaElem.data(
'last-touch-time');

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

// Get the position of the last touch on the element
var lastX = areaElem.data('last-touch-x');
var lastY = areaElem.data('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
areaElem.data('last-touch-time', '');
areaElem.data(
'last-touch-x', '');
areaElem.data(
'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)
areaElem.data('last-touch-time', now);
areaElem.data(
'last-touch-x', x);
areaElem.data(
'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.

The JooJoo

The hate for the joo joo (formerly the Crunchpad) has been palpable,

From Silicon Alley Insider,

At $500, this Web-only tablet is very expensive. And it doesn’t do much — just a Web device.

From ZDNet,

You can get a far better device for far less money. Who does Fusion Garage think it is, Apple? the price alone, makes this device a FAIL. Forget that it’s from a name you’ve never heard of. Forget that it’s Linux. Forget that it’s a really cut down Linux distro that’s totally hooked to the web. Forget that chances are not a single machine will ever see light of day because it’ll become a casualty of litigation.

From CNet,

it’s priced out of reach of most consumers, and functionally doesn’t offer much more than a $300 Netbook, although arguably it performs many of the same functions with a lot more style.

(Though it seems more recent, hands-on reviews of the tablet have been a lot more favorable)

the joojoo

Call me an optimist, but I think the joo joo has a lot going for it, and many of the negative comments directed towards it seem to be based on the fact that it will be competing against similarly priced netbooks, and that’s only a valid comparison if you think netbooks (or laptops for that matter) are comparable devices; in my view, they’re not, tablets are a new form of computing devices, one poised to become more powerful and user-friendly than the netbook/laptop form. My primary reason for this view, user input.

A while back I noticed something, I do very little typing when browsing the web, the majority of the time I’m reading, browsing, or scanning a page’s content or scrolling; when I do type, it’s typically in short bursts – long emails and blog posts are not frequent activities for me. I suspect the same behavior is true to a certain extent for others as well. Given this behavior, the mouse can be viewed as the primary input device, with the keyboard being secondary. Of course on a laptop or netbook you don’t have a mouse, but a touchpad, which is, in my opinion, a terrible input device. The touchpad tries to replicate the functionality of the mouse, but never really hits the mark; it does not provide the same level of fine-grained precision, it’s not as comfortable, and it feels fairly awkward to use. The nipple is only slightly better, and has the added disadvantage of bruising your index finger after extended usage. This is why I’m optimist for the joo joo, and tablets in general, it provides a form-factor and input device that eliminates the horrid touchpad, and provides a computer with a form of user input that matches or, in some cases, rival the mouse.

The joojoo is not a netbook or a laptop, and it shouldn’t try to be one. As for some of the other criticisms,

  • When did everyone become an expert on pricing?! $500 is steep, but not necessarily for early adopters. New graphics cards and CPUs can hit or exceed the $500 mark (note, that’s $500 for a single component, where there is typically no software out that can push it to the limit). The iPhone debuted at $600, and that was before the app store.
  • I don’t like that it’s a web-only device, but it seems to be a necessity here, as there isn’t a real hard drive, which makes sense; a conventional hard drive would kill a tablet (too heavy, too bulky, too much power consumption) as would an SSD (too expensive).
  • There is no problem with this device running Linux. Linux is a very capable operating system.
  • I have no comment on the litigation issue, I have no knowledge of what the relationship was between Arrington and Fusion Garage (and I doubt anyone else does either, beyond the parties involved). I was under the impression that Arrington was founder of the company making the device, that was obviously not the case.