Added better swiping support for touch devices.

[and3rson]

So, recently I've been doing some stuff for a presentation and noticed that it is not working on my Android.

A little examination has shown me that Android, iPhone and iPad are blacklisted for the swipe.

I think the time has come to disable the blacklist as most modern (and not-so-modern) devices nowadays work flawlessly with Impress.JS.

So, I've implemented a "swipe" left & right effect and removed "Android" User-Agent from the blacklist.

Check out the video below.

Hope this is useful to somebody :)

[FagnerMartinsBrack]

It would be amazing if there was an algorithm to simulate exactly the changes a native do when swiping (like moving the step while you drag until a given threshold).

[and3rson]

@FagnerMartinsBrack I think that's possible to do having transition interpolations for mid-frames. The only question is performance. I will try to experiment with that :)

[and3rson]

@FagnerMartinsBrack I've added interpolation for frames to provide native-like dragging. The performance seems usable on mobile devices :) Check this demo out:

Tested on Samsung Galaxy A5, Chrome browser.

P. S. I also implemented a toAdvancedNumber function to allow using values like:

<div class="slide step" data-x="0.5w" data-y="2h"> ... </div>

This means to use 0.5 * screen width for X and 2 * screen height for Y to build responsive presentations (to use current screen dimensions Instead of using explicit pixel-values)

You can check out the demo presentation here: http://crowdsourcemyname.com

[FagnerMartinsBrack]

Really awesome!

I believe though, for the sake of usability, that it should swipe using the pointer as the reference instead of the actual slide edges. If you use the slide edges it will not transition when you start the swipe after the middle of the screen.

[and3rson]

@FagnerMartinsBrack Thanks :) However I'm not sure if I understand you correctly, can you describe the desired behavior?

[FagnerMartinsBrack]

can you describe the desired behavior?

In the current implementation, the step change only occurs if the border of both slides pass through the middle of the screen. If you start swiping from the end, the pointer is after the middle of the screen, so the swipe doesn't happens.

Example below:

[and3rson]

@FagnerMartinsBrack ah, I see now. Sure, I can just change threshold to some lower value (currently 1/2 screen width, probably need 1/4 or 1/5 or smth)

Thanks for the demo! I'm gonna push update in few minutes.

[and3rson]

@FagnerMartinsBrack Done! Check out the demo site :)

[FagnerMartinsBrack]

👍

[and3rson]

Anyone with write access to the repo around? :)

[FagnerMartinsBrack]

I am not sure if this is going to be merged soon, see #435.

The reason I suggested some improvements was because I see a lot of value in something like this, even if it is not merged. I will probably cherry-pick some of the changes if you don't mind ;D

[and3rson]

@FagnerMartinsBrack use as you wish, it's open for everyone :)

[FagnerMartinsBrack]

@and3rson I find this feature very useful. Just pinging to say that we haven't forgotten it. The problem is that without proper automated testing this can't be landed. We will keep this in the queue and come back later.

To give a little bit of context, recently a decision was made in the project to make the development more active. If you want to keep track of what we are doing right now, please check #512.

[and3rson]

@FagnerMartinsBrack Awesome! Thanks for info.

You guys are doing an awesome job.
In case you get back to this feature later, I'll be glad to fix or reimplement it to suit the new architecture (and create tests as well.)

[henrikingo]

Hi @and3rson

Your code is really cool! I've merged this in the past 2 commits to my fork. You can try it with the official demo here. Note: To play with the swiping, you may want to stop the autoplay by clicking on the pause button to the bottom right.

Testing with my 3 year old tablet, the official demo animates a swipe pretty smoothly on Chrome. Only the "tiny ideas" slide is tough, as it zooms (ie scales) so heavily. On Firefox for Android it was quite sluggish, but doing a quick swipe instead of trying to "enjoy it" will bring you to the next step no problem.

Details:

• I made the w/h positioning as a separate commit. It's also a bit different: Since there was already a relative positioning plugin in my fork, I naturally added this to the same plugin. As a result, a presentation needs to use data-rel-x="2w", etc...
• I separated the swiping code into a new impress().swipe() api method, and a touch plugin. That worked out pretty well, the swipe() method just needs a single parameter to render the swipe: a ratio between -1.0 to +1.0.

[Pierstoval]

Is there any news from here? 😉

[FagnerMartinsBrack]

@Pierstoval This depends on #575. We can't start implementing new features until we have a considerable amount of integration test coverage in the project. We don't want to break the presentations of who is using it :)

[henrikingo]

This is now merged to master (with some refactoring to fit the new plugin based approach). Thanks @and3rson, I enjoyed your code! (Never did anything that swiped before.)

[and3rson]

@henrikingo Glad it helps!