You can't detect a touchscreen | Hacker News Reader

You can't detect a touchscreen

stucox.com

58 pointsIsofarro32 comments

I really hate when people say you can't do something. It usually boils down to a lack of imagination on the part of the author.

* Hook document.onmousemove and track the number and location of movement events. If the mouse suddenly jumps around, you most likely have a touch event.

* Check the value of navigator.msMaxTouchPoints

* Pop a 0day on the client to get remote code execution, interrogate the devices attached to the USB bus looking for touch controllers.

etc.

So, is any of this actually backed with usability studies, or is it just pontificating?

The implicit advocation here is "design for the least common denominator". That means no hovers, no gestures, no secondary/tertiary clicks, no modified clicks, no long-presses, no multitouch, and big fat click targets that allow for lots of slop. That's all well and good until you realize that this leads to designs which are wildly inefficient on certain classes of devices and drive users away because the information density sucks and the interaction models are stunted. If you can get away with it without damaging your UX, then by all means, go for it. Device-agnostic design is awesome, but it's myopic to damage the UX for the vast majority of your userbase because someone might access your website on their XBox and use their Kinect to navigate it.

Know your audience and design appropriately. You're never going to design a perfectly futureproof website; make sure that your users today and tomorrow have a great experience, and then just keep iterating on that.

It's not about audience. You can implement all those "gestures" but only as shortcuts to functions that can be accessed in other fashions as well.

Don't make me have to middle click for something and make that the only way to perform said action.

The author even stresses this trend to focus too much on providing great interfaces for mobile and not for other platforms. :-)

It's a technical analysis – I didn't make any claims of user preferences.

"Know your audience and design appropriately."

Agreed. The aim of the post was to highlight that what people think they're using as a rock-solid feature detect is in fact seriously flawed.

If you understand those flaws and you're happy with them, great.

Related: what verb are we supposed to use now, for click/touch?

A couple months ago, I was writing a balloon-tutorial system for an app with a desktop and mobile version. The desktop version had to have commands like "click this, then click that". The mobile version, "touch this, then touch that." Often, the text was otherwise identical.

But what do we write when the user could be using either, for example on Windows 8? "Clicking" a link with your finger sounds strange -- there's nothing clicking. And "touching" something with your mouse seems equally strange, almost as if it implied moving the mouse but not clicking. "Press" works for buttons, but not menu items or links. "Activate" just seems weird. And writing out "touch/click" is just unwieldy.

What to do?

But what do we write when the user could be using either, for example on Windows 8?

Windows 8 uses "tap" everywhere, which is infuriating for desktop users, who now know on which side Microsoft's bread is really buttered.

For the Web, usability guidelines have said since forever to avoid phrases like "click here", because you have no way of knowing how your page is being viewed now or might be viewed in the future. They were blithely ignored by designers and marketroids.

Normally, when a verb is called for, I say "hit this link" or "follow this link"; for buttons and menu items I say "say". E.g., "Enter your IP address, netmask, and gateway and then say OK."

I was actually going to reply to the parent and say that Windows 8 often times tells me to "click or tap". Can you give an example of somewhere in Windows 8 where it says to only tap?

Of course, a large portion of laptop users have actually been tapping on trackpads to "click" for a long time now...

No matter what interface the user uses, they still "follow" links, and "press" buttons.

I tend to say "tap" instead of "touch" and, at a pinch, this could work for mouse users.

Saying that, most people will know what "click here" means, regardless of the input type, so I wouldn't lose sleep over it.

I would use "click". In fact, I do use "click" to refer to using touchscreens, all the time.

... which, incidentally, is the DOM event you can guarantee will be fired, regardless of the input device (unless you choose to `preventDefault()` before it gets a chance).

How about

Links => "follow"

[Nested] Menus => "navigate to"

Buttons => "press"

Other => "select"

How about 'press' ?

In addition to the suggestions of others, there is 'choose' which will work in some contexts (e.g. Menus)

JS API sniffing is the new User Agent sniffing.

How far we've come in 20 years.

<deadpan>HTML5 will save us from vendor-specific differentiating capabilities.</deadpan>

I'm trying to style the <deadpan> tag with CSS3 `sarcasm: loads`, but it's not working in IE7?

tangentially, you also cannot detect the number of thread-able cores for tweaking webworker spawns

Gah, forgot to mention that. I'd better write it again...

Indeed!

That's on my list of upcoming week-end projects: start some highly parallelizable task with an increasing number of workers, returns the number that works best.

Just make a page that's both touch and mouse-friendly. If you do that, support for people who don't have fine motor control, and support for pen input, is included.

At a former job we used to have a Just Jar, into which any programmer who said "why don't we just..." followed by something which is or may be nontrivial would have to put cash. Eventually the Just Jar's contents would be emptied out and used to buy a couple of rounds of beers. I heard that was actually fairly frequent at one time...

You seem to be implying making a touch-friendly interface is difficult. I made a touch-friendly interface for one of my websites by accident: making the buttons slightly bigger was all that was needed.

OH OH OH OH OH.

I'm stealing that idea because it's GENIUS.

In my experience, when talking about software development, "just" is almost always a dirty word.

Sometimes, "just" really means "just swap plugins".

Sometimes, "just" really means "completely re-implement functionality".

I'm just saying, be careful how you use "just".

Oh I so wish someone in Google+ team would hear the stance about hover, and why to avoid them. When I want to follow an author of a post, I have to play maze with my mouse, and often I just abandon the task in the middle.

Great article, as was the one before it. You should keep writing AND add an RSS feed so I can subscribe.

Ah, the web. Repeating the issues from 2000 over and over again.

What if you put an invisible div on the entire page with an onmouseover trigger which means that you will know that the device is not a touchscreen.

keyboard nav, screen readers - there are many ways of interacting with a non-touch browser that will never fire onmouseover.

Touch screens can trigger mouseovers, and desktops might not. At any rate, it doesn't seem practical to assume everybody is on a touch screen until they mouse over the page.

Reply on news.ycombinator.com