For any blog post like this, the absolute first thing should be a demo. "Simple" and "fast" are claims that cant be verified by looking at code, and a demo is a primer that makes code easier to understand.
You'd need to setup the Trigger.io build / test environment to see the full example code from the post used in a mobile app. Maybe next time we can show that to you in a screencast, we'll work on it.
If I have to set up a Trigger.io build/test environment to see something used in a mobile app, it fails on being simple. I know it's your platform and all and you're trying to sell it, but entice me to use it with breadcrumbs in the form of progressively more advanced demos up until I need Trigger.io to see the most advanced demos.
Is using/experimenting with Trigger.io as trivial as an apt-get or npm install?
Good start, but it'd be nicer if the swipe gesture was tracked live and the transition performed once the touch point was released (taking velocity into account for bonus points). This'd be more like the iOS home screen switch gesture (imagine if that didn't track live!).
Hi, author of the post here. I'll admit I kept the premise simple here in order to provide a more introduction on how to "roll your own" effects without too much overhead.
That is nice, thanks for the link :). It's a pity the touch events don't include finger velocity -- you can confuse the velocity tracker in that example by swiping back and forth quickly before releasing.
This is an especially pertinent question as CSS transforms tend to be hardware-accelerated on mobile Webkit, playing more smoothly and using less battery, while jQuery animations tend not to be.
This makes for some jerky transitions, unfortunately, but the alternative is forgoing the simplicity and performance afforded by position:fixed for persistent nav.
13 comments
[ 2.7 ms ] story [ 41.4 ms ] threadYou'd need to setup the Trigger.io build / test environment to see the full example code from the post used in a mobile app. Maybe next time we can show that to you in a screencast, we'll work on it.
Not a screencast as I can't gauge lag from that, but a functioning demo to play with.
I want to be able to test on my phone to see it's "simple and fast" from the UX perspective before I'll investigate further.
Is using/experimenting with Trigger.io as trivial as an apt-get or npm install?
The sort of thing you've described seems to have been implemented pretty well as a zepto plugin: http://blog.kojo.com.au/flickable-zepto-plugin/ (in particular this demo: http://blog.kojo.com.au/demos/flickable/demo2.html ) which works wonderfully on my Galaxy Nexus, but I haven't had much of a chance to play with this yet!
Android has a whole bunch of velocity trackers, but they're probably expensive in JS (solve least squares, etc). Code is here: https://github.com/android/platform_frameworks_base/blob/mas...
"Zepto exclusively uses CSS transitions for effects and animation. jQuery easings are not supported."
From http://zeptojs.com/#animate
We can't accelerate animation on a mobile app that uses position:fixed for persistent headers due to http://code.google.com/p/chromium/issues/detail?id=20574
This makes for some jerky transitions, unfortunately, but the alternative is forgoing the simplicity and performance afforded by position:fixed for persistent nav.
:-D