Touch events less responsive than On Swipe events for iPad

(Rachel) #1

For Hype documents using multiple scenes, I get a good level of responsiveness when I program transitions between scenes using swipe events from the Scene panel (On Swipe Right, etc.) However, images/buttons programmed to run the same transitions from the Actions panel (On Mouse Click, Jump to Scene, Next Scene, Push (Right to Left), 0.3) work only after a long lag time.

I’ve selected “Use touch events” under the document settings.

Why the difference in performance when using touch events vs. on swipe for iPad? Is there a better way to get faster transitions when using images and buttons?

Thanks!

(𝕄𝕚𝕔𝕙𝕒𝕖𝕝 𝔾𝕒𝕣𝕠𝕗𝕒𝕝𝕠) #2

Ha, I was going to ignore this, but it’s the next part that I’m working on in the Hype book. I think I might know what the problem might be.

Did you try the “Mouse Down” action instead of “Mouse Click” action?

I was working on an Abacus and the results were inconsistent and not so responsive. Switching the actions fixed the problem. Mouse Click is a full cycle… down and up… where Mouse Down is just the down part. It’s quicker.

(drewbullen) #3

In projects built with previous versions of Hype I would use fastclick.js to improve the responsiveness of button clicks on mobile devices. More recently, my subjective observation is that this is no longer necessary because either Hype is somehow handling these events differently or something equivalent is happening in mobile browsers.

In spite of this I would still like better responsiveness than I’m currently getting on mobile devices.

(Rachel) #4

Thanks for the suggestions. I haven’t tried “Mouse Down” or “fastclick.js.” I’ll try both.

To clarify, if I swipe to another page, the transition is immediately available. If I use touch events instead, I see a delay of several seconds. It appears the entire page needs to load in order to enable the touch event to work.

Can anyone else comment on this? Are others seeing the same discrepancy in desktop (works with no noticeable delay) and mobile?

Thanks again!

(stephen) #5

Could you send me your hype document (or a sample document) that demonstrates the problem?

(stephen) #6

If you check Use Touch Events we do special event handling to make clicks more responsive on mobile devices.

Do you have an example where you are seeing poor responsiveness or better responsiveness using something like fastclick.js? I would expect our handling to have the same performance as fastclick.

(drewbullen) #7

So I wrote a small test program to assay the “poor responsiveness” on touch devices.

Simply, I measured the time between the click (or tap) event and a subsequent function. The readout was a console.log statement viewed in the developer console of Chrome or in the equivalent console in Hype Reflect. “Use touch events” was selected in the document inspector.

There was little or no difference in response time between real & pseudo buttons or between desktop & touch devices. This is good.

However, on touch devices not every tap was detected. In some tests, the proportion of detected events was quite low! This is not good.

I believe this is the real problem - events are being missed on touch devices and swipes are just harder to miss than taps.

Here is the test program -

clickTester.hype.zip (12.6 KB)

(Rachel) #8

Hi! Sorry for the delay, was out of the office for a while.

I can’t share this project publicly. Would it still be helpful to submit it via email or for offline review?

What to you think about Drew’s test where he thinks users are missing the target? I’ve made all targets larger than Apple’s dev specs call for but don’t have room to go larger.

Any additional help or review would still be greatly appreciated. Thanks!

(stephen) #9

Ok, I think I have fixed this now. Please try it out in the next update and let me know. (If you would like to be a part of our beta program you can send me a direct message).

(drewbullen) #10

I tested this problem in Hype 3.5Beta (using Hype Reflect 2). This behavior might be improved but it certainly isn’t fixed. There was still a less than a one to one correspondence between physical taps and tap events registered - at least on my iPad.

(stephen) #11

I should have been more specific, I fixed it yesterday so it should be out in a beta next week. Sorry about that!

I really appreciate you trying it out, please try again with build 502 next week.

(drewbullen) #12

OK, so after testing in Hype Beta (502) this problem seems to be resolved. There is a one-to-one correspondence between physical taps and events registered. Hooray!

(stephen) #13

Hurray! Thanks for checking.