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.
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.
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 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.
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.
... 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).
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?
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.
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.
32 comments
[ 2.9 ms ] story [ 38.2 ms ] threadHow far we've come in 20 years.
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.
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".
I'm stealing that idea because it's GENIUS.
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?
Saying that, most people will know what "click here" means, regardless of the input type, so I wouldn't lose sleep over it.
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."
Links => "follow"
[Nested] Menus => "navigate to"
Buttons => "press"
Other => "select"
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.
"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.
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. :-)
* 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.