Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FastClick

github.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: FastClick

#21

Post by joahua »

The impact this makes on perceived speed is impressive.

However, a word of caution. We tried this for a while and found it interfered with scrolling behaviour on link-heavy pages, not to mention making event capture for swipeable elements difficult.

The technique is a useful one to be aware of, but I'd be wary of using a library for this - it didn't work out for us, and I'll hazard it is unlikely to work as well it initially appears to.

That initial 300ms speedup is astounding, though :)

Re: FastClick

#22

Post by mattcg »

FastClick dev here. We're trying to support as many platforms as possible, so if you notice any problems while testing please file an issue, even if your platform is IE8. I typically fix really bad bugs within about 24 hours. The version on GitHub is the same one that's used by the FT web app, which is built to support Android, Chrome, IE, Firefox, Safari and so on.

Re: FastClick

#23

Post by mattcg »

Revisor wrote: post #11

Use at your own risk. On our website it brought a lot of small unanticipated errors in the user interface that we only uncovered slowly. It didn't work in IE8 out of the box. Some users reported they had to double tap very fast on iPad to actually activate any link (I couldn't reproduce it on my iPad). On some older Android devices it made links and menus behave erratically. In the end we disabled FastClick completel…

I'm sure it won't be too difficult to fix those bugs. What version of FastClick were you using? Were you testing on Android 2? If so I'm working on support for that.

Re: FastClick

#24

Post by mattcg »

joahua wrote: post #21

The impact this makes on perceived speed is impressive. However, a word of caution. We tried this for a while and found it interfered with scrolling behaviour on link-heavy pages, not to mention making event capture for swipeable elements difficult. The technique is a useful one to be aware of, but I'd be wary of using a library for this - it didn't work out for us, and I'll hazard it is unlikely to work as well it i…

I recently changed the way touch events are observed - bubbling listeners are used instead of capturing listeners. This fixed a problem we had with scrolling libraries. Have you tried the latest version?

Re: FastClick

#26

Post by hayksaakian »

aneth4 wrote: post #15

This seems useful in a subset of circumstances but should really be used on a limited basis. A lot of careful design and thought went into existing behavior. The default delay is there for a reason - to better understand user intent and give access to additional features. Users are also used to the delay and may be frustrated or confused rather than delighted at the change, and some touch-hold functionality may be af…

I'd argue the opposite, native controls on most mobile platforms have a very low delay and almost always respond faster than web interfaces. The delay perpetuates the stereotype of unresponsive web apps on mobile devices.

Re: FastClick

#27

Post by aneth4 »

hayksaakian wrote: post #26
aneth4 wrote: post #15

This seems useful in a subset of circumstances but should really be used on a limited basis. A lot of careful design and thought went into existing behavior. The default delay is there for a reason - to better understand user intent and give access to additional features. Users are also used to the delay and may be frustrated or confused rather than delighted at the change, and some touch-hold functionality may be af…

I'd argue the opposite, native controls on most mobile platforms have a very low delay and almost always respond faster than web interfaces. The delay perpetuates the stereotype of unresponsive web apps on mobile devices.

I agree in part.

This is not something to throw into your average mobilized web page, but into an HTML application designed for mobile. Facebook clearly does something like this for their mobile app.

Re: FastClick

#28

Post by ryanpetrich »

mrchess wrote: post #7

Nice implementation. For those not wanting to use a library you can achieve the same functionality by binding to the touchStart/touchMove events instead of 'click'.

touchend actually, and the fake "click" should be aborted if the user scrolls.

Re: FastClick

#29

Post by hayksaakian »

aneth4 wrote: post #27
hayksaakian wrote: post #26

Earlier quoted context omitted.

I'd argue the opposite, native controls on most mobile platforms have a very low delay and almost always respond faster than web interfaces. The delay perpetuates the stereotype of unresponsive web apps on mobile devices.

I agree in part. This is not something to throw into your average mobilized web page, but into an HTML application designed for mobile. Facebook clearly does something like this for their mobile app.

That's actually what I'm working on (phone gap app) and why I plan on using this.

Re: FastClick

#30

Post by kalms »

joahua wrote: post #21

The impact this makes on perceived speed is impressive. However, a word of caution. We tried this for a while and found it interfered with scrolling behaviour on link-heavy pages, not to mention making event capture for swipeable elements difficult. The technique is a useful one to be aware of, but I'd be wary of using a library for this - it didn't work out for us, and I'll hazard it is unlikely to work as well it i…

It also conflicts with tap/click markers, when initiating animations on click event.
Post reply on HN