Here we can track all the interaction development on the MWC site. From Jon: Here's a little demo of some parallax and scroll-position based animations (based off Steven's work): http://sandbox.equalpartscreative.com/supercool/supercool.html Credentials are the same as the IRC channel (name is channel name (sans pound sign), password is channel password).
One question so far from bug#832523 Should the phone "stick" to each slide, then smooth scroll to the next slide when the next slide is X% in view?
Anyone else having trouble loading the interaction demo (from the description above)?
Here's a link to the page on demo2: https://www-demo2.allizom.org/en-US/firefox/partners/
a few things to ask: • how many frames are being show per second? • how many frames are in the sprite image/png that you are moving through the window? • looking at the web inspector the image looks to be over 7500px wide, is this the most optimal way of laying out the sprite? • are there other sprite solutions beyond jQuerey that may allow for some time adjustments? the animation/png frames we created for the boot sequence were designed to run at 12 frames per second, any thing more than that is going to feel overly accelerated. currently there is not a version that would work at 24 or 30 frames per second. the speeding up and slowing down could be solved through a different implementation of the sprite being moved, maybe through CSS?
(In reply to barry munsterteiger from comment #6) > • how many frames are being show per second? The demo server is running at 24fps, but the code has since been updated to 12fps. The demo server will reflect this change later today. > • how many frames are in the sprite image/png that you are moving through > the window? There are 44 frames > • looking at the web inspector the image looks to be over 7500px wide, is > this the most optimal way of laying out the sprite? > • are there other sprite solutions beyond jQuerey that may allow for some > time adjustments? We have a fair bit of control with the jquery option. Did you have any other timing changes in mind? > the speeding up and slowing down could be solved through a different > implementation of the sprite being moved, maybe through CSS? Possibly - this is an initial proof-of-concept to see if it works at all as a sprite. So far, this proof-of-concept shows that it is feasible. The file size is fairly good (around 100Kb + phone bg), but that there are playback speed inconsistencies on some machines. This might be improved when the framerate is fixed down to 12fps. I think it is also worth seeing how small an MP4/WebM version of the fox could get. I do wonder about matching the background of a video with the image, as some color variation may be introduced with compression.