Recently I watched a video on building for touch screens that discusses the challenges when building for touch and keyboard interactions —something that is on the mind of many, many, many, many, many people and something I’ve written about before. So what’s the best way to deal with touch at the moment? Modernizr? Well, detecting for touch primarily using something like Modernizr.touch can sometimes lead to false positive results plus it can be dangerous to make that assumption when a device also includes a keyboard.
Cloud Four has been pounding away with great articles that discuss the multitude of devices that fill our landscape today, but they also don’t leave out the elephant in the room (i.e the television/billboards…who knows what else). Devices like the Windows Surface not only have a touch screen, but they also have a keyboard too! This opens up a whole other can of worms because that means your user not only can enter input with their keyboard, but also their touch screens as well. We see more of these devices popping up and now would be a good time to decide how we’re gonna attack these beasts.
The prediction in our year(2014) Mobile(whatever that is) will overtake desktop use by a huge margin and around 25% of Windows 8 machines will have a touch screen (not to mention we have touch laptops entering the scene like the Chrome Pixel). Devices like the Chrome Pixel open the door for simultaneous interactions that not only involve touch, but summon the power of monkey arms to interact with the keyboard at the same time. If you attempt to wrap your code in an if() {} else {} condition and feature test for touch (once again using Modernizr.touch) means you cut off your user from using the trackpad or keyboard!
You’ll see in the demo below I’ve setup two event types. One event will be a click and the other will be a touchstart. Each time you click the HTML node the event type is reported for us along with a time stamp in order to let you know you’re clicking each event and that same event type is being fired. You can also open up your console in the DevTools and see that only the click event fires. If you use the DevTools emulator you can emulate touch events and notice the console.log only reports a touchstart event fired. We don’t get both the click and the touchstart happening at the same time (which is a big concern for many developers). If you write your methods/functions robust enough you can use them over a multitude of event handlers plus you don’t need to monkey with a meta viewport tag and disable zooming all together to achieve a fast click. There will however be exceptions to this in cases like scrolling.
See the Pen CODING FOR TOUCH & CLICK EVENTS by Dennis Gaebel (@grayghostvisuals) on CodePen.
The moral of the story is don’t make the user suffer just because they happen to have a touch screen. In cases where we don’t need a fastclick library we should avoid it at all costs. Just because someone has a touch screen on their laptop doesn’t necessarily mean they’re gonna use it. Developing your handlers for both touch and click is a great approach that we should all be doing immediately.
“Demo Code for handling click and touch event handlers. The question I’m asking to myself is “Why are we immediately going to a library like fastclick? Why are we not suggesting this by default?””
the answer is: if you want to tap the element, slide your fingers off the element to cancel your click, you can’t use touchstart. Also some androids will fire off touchstart even when you’re just scrolling the page.
This was the first attempt:
then bind events to the variable
TOUCH_OR_CLICK_EVENT.We had all the problems mentioned above.
We also had those issues with a large responsive web app. So our experience was better when we utilized google fast buttons. Btw you can still get the very snappy click experience with fast buttons.
Another thing is old androids are very unpredictable and do weird things.
cheers
Leonardo