#optimalisation

Even though the delay was small, it was still enough to have impact on the user experience. Since the aim for the project from the beginning was to create an optimal user experience on mobile this was something that had to be fixed. 

After a quick search I bummed into an stackoverflow answer which led me to an article on the Google blog were one of the developers explained that the delay is caused by a method mobile devices use to detect if a user is going to preform a double tap.

When you tap on button that triggers javascript code the device you’re on will wait around 300 milliseconds to see if you’re going to preform a double tap. This way it will know if you actually want to click the button or just simply want to zoom in. Since this is not disabled when a website does not allow zooming in; we have a website with a function which is apart from annoying to our users, not useful.

Even though I do not doubt the skill of the developers at Google, some parts in their solution seemed kind of unnecessary to me at first sight and I started trying some things with some own code.

I thought at this point the solution to the delay would actually be quite easy. Opening the menu when the user touches the screen and with under the condition that the screen was dragged over a distance less than 10 pixels.

However, as I soon discovered, the actual solution was a bit more complicated than that. Even though the principe of Google’s method is the same as the method I was using the Google one does I bit more to prevent the so-called ‘ghost clicks’.

Discovering this I decided to put together the method Google posted on their blog.

Since the code Google provided is a class and you have to create a new instance for every fast button, I wrapped the creation of an instance into a prototype function so I have better control over what happens after and before the creation of a new fast button instance.