833871 - [MWC 2013] Interaction for MWC website

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect)

Description

[Mike Alexis [:malexis]]

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).

Comment 1

[Mike Alexis [:malexis]]

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?

Comment 2

[Jonathan Petto [:jpetto]]

Anyone else having trouble loading the interaction demo (from the description above)?

Comment 3

[Mike Alexis [:malexis]]

Here are notes from John Slater from our implementation kickoff to guide the interaction work:

1. Parallax scrolling... the main thing is the phone image moving from section to section (with different content appearing around it and on the screen as it moves), but there may be other details around scroll timing, etc to work through. Obviously there are many, many examples of this on the web, but we've been using http://www.autographer.com/ as a proof of concept for the folks here who aren't familiar with the concept.


2. Floating side nav would act in a very similar way to http://www.projectrebrief.com/volvo/#page=overview .


3. Contact form slideout would be generated by clicking on the Partner With Us buttons as well as the small arrow on the right side of the page. Here's our example: http://iwantaneff.in/repo/plugins/menu-nav/pageslide/index.html


4. Phone screen content (homepage)…this most likely would be a light animation to replicate the actual experience one will have while booting up a FxOS device. I've attached a very rough example of how it will look. Below is a quote from Barry, our animation guy, as to how it might work on the web…please advise on what you think would be best so I can work with him to get you what you need.


there are a couple ways we could get it working on the site. one method is an animated sprite… if you're not familiar with that it is a big image that is gridded out with all frames of the animation and using javascript it cycles through the frames, it isn't reliant on a video player of any sort. another option is to make it an h.264 or theora file and have it linked via the video tag.


5. Phone screen content (FxOS page)... this has gone through a lot of iterations and still is being scoped out, but the most likely current option is to have some sort of slideshow functionality along the lines of what we have at https://www.mozilla.org/en-US/firefox/fx/ . 

The goal would be to showcase a few different parts of the FxOS interface, and generally make the page feel less static. If you have any creative ideas on how this could be enhanced or smoothed over in any way (without dramatically increasing the scope) I'd love to hear them…otherwise this will probably work. Still waiting on confirmation from our product marketing team though.

Comment 4

[Mike Alexis [:malexis]]

Notes from Steven re: Foxtail animation:

1. Fox-tail Animation

I've added a simple javascript+background-image sprite animation of the
foxtail. It's using the Spritely jquery plugin, which might be a bit
heavy for our purposes, but it's a proof of concept.

By separating the fox out from the textured background, I was able to
use an 8-bit PNG for the fox, which is under 100Kb (not including the
phone image itself). I think this could work, but it's worth seeing how
small an MP4/webm video could get too.

This fox-tail animation is on the mwc-animations branch.

Comment 5

[Mike Alexis [:malexis]]

Here's a link to the page on demo2:

https://www-demo2.allizom.org/en-US/firefox/partners/

Comment 6

[barry munsterteiger]

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?

Comment 7

[Steven Garrity [:sgarrity]]

(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.

Comment 8

[barry munsterteiger]

adding cmore and mKelly

cmore made the recommendation of having a timing engine that wraps the javascript timer to ensure that the faster machines aren't "sprinting" ahead.  he also mentioned that mkelly had experience with this via games in HTML.