How to Sync Web Page Events With Embedded YouTube Videos

As noted in the Creating CSS3 Snowflakes article, for our recent holiday card project we wanted to create an experience with the website that was closely tied to our centerpiece video. One of the keys to this was making the experience seem as seamless as possible to allow the viewer to immerse themselves in the video. We also wanted to see if we could connect events in the video to events on the web page to further enhance the experience.

Examples of Syncing Events

To get an idea of what I mean by ”syncing web page events with an embedded YouTube video” it might be good to check out two examples. The first example is very simple and it’s the one I created as a proof of concept for our holiday card project. The example page explains what you should see. The second example is the holiday card itself. The holiday card example will only work on Safari, Chrome and Firefox because of the CSS3 animations we used.

The main thing we did with the holiday card project to make the experience seem seamless was to hide the text and other traditional page “chrome” when the video started playing. We did this with a simple opacity transition and then moved those elements far off the screen. Once these elements are removed the viewer is left with the video playing and the background. The background, an overview of our campus, is not a static though. The main character in the holiday card video was a sprite visiting and bringing holiday magic to various locations around campus. As the sprite visits places like our freshman dorms or our football stadium the location of the sprite is highlighted on the page background with those same locations changing color. It’s a subtle effect because we didn’t want to distract too much from the video itself. My favorite part is the sprite rising into the air from downtown Morgantown (only viewable in Safari & Chrome because of a specific type of CSS3 animation).

So how did we do it?

YouTube’s JavaScript Player API

I think many folks are familiar with the various parameters that one can set on an embedded YouTube video to control how it looks & behaves (e.g. turn off related links). If you aren’t familiar with them go check them out now. They can give you a lot of control, especially from a branding perspective. One step beyond that though is the YouTube JavaScript Player API. It allows developers to control the player itself. It’s important to note that the YouTube JavaScript Player API only works with the older embed code. An API for the iFrame embed is currently experimental.

The YouTube JavaScript Player API allows you to use, you guessed it, JavaScript, to control things like starting a video, stopping a video, changing what video is playing in the player, playback quality, and even the player volume. While those things are useful, the best feature of the YouTube JavaScript Player API, especially when looking at syncing actions between a web page and video, is the event onStateChange. It is fired every time the video is started, paused, buffered, or ended. Luckily, there’s a simple YouTube JavaScript Player API wrapper, YouTubePlayer (originally created by Anurag Mishra), that makes it easy to quickly embed a video (via SWFObject) and then listen for these onStateChange events.

Using onStateChange & YouTubePlayer

Using YouTubePlayer to listen to these onStateChange events is actually quite straightforward. As with any video the first thing you’ll want to do is embed it. All you need to know is the ID of the

where your video will be embedded and the ID of the YouTube video.

Once that’s done you can set-up event listeners that do something when the event you want to track is fired. For example, let’s listen for when a viewer starts playing a video and then listen for when the video ends. It’s important to note that ‘playing‘ is fired after a user pauses and then restarts a video. There’s no differentiation between starting a video for the first time and after pausing the video.

YouTubePlayer gives really easy access to these events via the .on() function. But what about timing events like the fireworks in the original example?

Timed Events with YouTubePlayer

I  added the .at() alias and expanded the .on() functionality for YouTubePlayer to make it really easy to add timed events. Using the fireworks as a quick example:

Essentially the .at() function registers events with the browser with a certain name based on the time the event should take place (e.g. 1100). These events are then fired by a setInterval() function that tracks time once the viewer starts watching the video. Every time the tracked time is incremented (e.g. from 1000ms to 1100ms) a corresponding event is fired (e.g. 1100). Thanks to onStateChange, if the video is paused or buffering the tracked time isn’t incremented and no event is fired. If a video is scrubbed the tracked time is updated appropriately and incremented again.

For the most part timed events can be fairly straightforward as shown in the source for the simple example. It can also get a little complicated as seen in the source for the holiday card timed events JavaScript. With the latter I was trying to make sure, because buildings stay highlighted after their event is fired, that if a user scrubbed backwards in time that buildings would be hidden again if appropriate.

A Warning About Timed Events

There is one very important thing to keep in mind when working with timed events. Because the tracked video time is sort of faked by using the setInterval() function (e.g. we’re not polling the video directly for the current time in the video. that’s just not a good idea nor accurate) the tracked time can fall behind the real video time. The main culprit for this is heavy JavaScript that gets called by your timed events and then causes the execution of the setInterval() to be blocked until the heavy JavaScript finishes running. Keep whatever you launch via the timed events as light as possible. Simple manipulations of the DOM might be best. That way, if you have a longer video, the timed events will play when they’re supposed to.

Conclusion

I always find it difficult to explain something like this without saying “Just look at the code.” Hopefully you were able to get a reasonable idea of how easy it is to use timed events to sync web page content with your embedded YouTube videos. I think there are a lot of opportunities to create richer experiences for viewers with this technique.

This article was posted

Creating CSS3 Snowflakes

For our recent holiday card project we wanted to create an experience with the website that mimicked the video that was the centerpiece of the project. While it was straightforward enough to use the same graphic style as the video we also wanted to include some of the same atmospheric effects as well like twinkling stars, moving fog, sparkles and, most importantly, snow. To create these we used CSS3 animations and transitions.

Making it Snow

In order to make it snow in our project I modified some CSS created by Estelle Weyl (@estellevw) for a SXSW talk she gave. The talk does a great job explaining the ins-and-outs of the CSS that gets used (e.g. animations, border-radius, timing) so I won’t repeat that here. The main contribution I made, beyond tweaking the CSS some to have the snowflakes look the way I wanted, was to create an easy way with JavaScript to:

  • randomly places N amount of snow across the web page
  • randomly assign classes to each snowflake to randomize their look (e.g. size, speed, delay, opacity)
  • properly detect the height of a web page when snowflakes are created and update the animation keyframe so they fall an appropriate distance instead of a “one size fits all”-style. Unfortunately, window.onresize is not accounted for.

You can view a demo of the CSS3 snowflakes in action. If you think it’s interesting you can grab the code (CSS & JavaScript) on GitHub to use on your own site. Directions on how to get it snowing are in the README.

Dependencies & Browser Support

There aren’t any real dependencies for this project other than browsers that support animations. This means this project can be used with Safari, Chrome, and FireFox. If the appropriate -ms- extensions were added it would probably work with Internet Explorer 10 as well. In the demo I use domReady to include the JavaScript in the <head> but that’s not necessary if you instead put the code before the </body> tag.

This article was posted

Video of My “Developing a Progressive Mobile Strategy” Freshly Squeezed Mobile Talk Now Available

If you’re looking to fill 25 minutes during your day, you can now check out the video of my Freshly Squeezed Mobile talk, ”Developing a Progressive Mobile Strategy,” that I gave at Breaking Development (@bdconf) in September. The slide deck from that talk is available on SlideShare.

Dave Olsen – Developing a Progressive Mobile Strategy – BD Conf, Sept 2011 from Breaking Development on Vimeo.

The folks at Breaking Development are slowly sharing the videos of the other talks at the September event. I highly, highly encourage you to check them out. Many thanks to them for sharing mine and the others.

This article was posted

EDUCAUSE Mobile Webinar & Report

This Wednesday, December 7 at 1pm ET EDUCAUSE Live! will be hosting a webinar with representatives from the University of Mississippi to talk about their mobile strategy. A summary of the webinar:

Those who work in a university setting are aware of mobile devices and their potential for enhancing campus life. In response, vendors are offering mobility solutions that claim they can address the needs of a typical university. This sounds appealing, but in reality a solid mobility strategy will likely consist of a suite of tools, approaches, and partnerships. This webinar will identify some of the big questions surrounding mobility and describe the approach that the University of Mississippi is taking for each. Examples are selecting scenarios that are good candidates for mobility, targeting native programming efforts to get the biggest bang for the buck, determining when to outsource and when to “do it yourself,” and employing successful mobility strategies from other industries. Also included will be highlights from a recent mobility survey. For Ole Miss, a solid mobility strategy has evolved from focused study and struggle, yielding valuable insights for other institutions.

To attend the event you’ll need to register.

Related to this webinar is the ECAR report, Mobile IT in Higher Education. There’s an infographic that sums up the report. It’s always good to get more insight into how mobile is being used in higher education.

This article was posted

Mobile Strategy Is Dead, Long Live Content Strategy

Last Friday I gave my Developing a Progressive Mobile Strategy talk at the M3 Conference. During my talk Jen Matson (@nstop) tweeted this about my “mobile web first” section of slides:

“Search + links = mobile web first.” That is the biggest gateway for users to your content.

After reading her tweet my first thought was that Jen had shown me a way to sharpen my talk. I could and should expand on why search and links were important and how they ended up paying-off for content creators. This seemed especially true since all but one person in my audience were non-higher ed. But reflecting on her tweet on my drive home I think I hit on a broader theme that is probably more important.

There’s No Mobile Web, There’s Only Content

Jen makes a very good and a very simple point. Search and links are the gateway for our users to our content. And you know what? They’re the gateway regardless if our users are using a mobile device or desktop. Platform doesn’t matter because both have the same opportunities to discover our content. As Stephen Hay (@stephenhay) tweeted earlier this year (and I went after him recently on it so mea culpa):

There is no Mobile Web. There is only The Web, which we view in different ways. There is also no Desktop Web. Or Tablet Web. Thank you.

I completely misunderstood his original intent but now I get where he’s coming from. The “mobile web” does exist but it’s from the standpoint of giving a name to the technical issues and techniques that help us deal with the numerous issues surrounding developing for small-screened mobile devices. That being said, from our users’ perspective they just want access to our content and they want it on their terms. Make sure you read his follow-up and explanation.

Discovering Our Content

The same channels that we use to market to our users and that our users use to find us on the desktop also exist on a mobile device:

  • Browser? Check.
  • Search box in said browser? Check.
  • Ads on web pages that appear in said browser? Check.
  • Email client that handles links? Check.
  • Social networking tools that, again, handle links? Check.

And you know what? Users are using these channels on their mobile devices. Do you have a website that features information about your institution, volunteer information for your non-profit, or products for your business? 77% of smartphone users use search. Do you send out emails about products or events? 87% of smartphone users check personal email at least daily from their smartphone. Use tweets or Facebook posts to spread the word about your organizations’ goings on? 65% of smartphone users visit social networking websites (this number doesn’t include the use of apps).

By the way, that notion of “on the go?” Well, that’s out the window. 93% of smartphone owners use their smartphones while at home. 29% use a smartphone in front of the TV and 39% admit to using it on the toilet. The mobile device is becoming the information discovery tool of choice no matter the location or need. It’s just that it has a smaller screen than we’re used to designing for. I would also argue that many of us don’t have content that is mobile-only so “on the go” doesn’t matter much anyway.

By making this content available on the web and advertising it we hope users take some action. Those actions could be applying to our school, donating money, buying a product, or simply visiting our store. We shouldn’t ignore how that content is rendered and made available to users on mobile devices. At the end of the day we want to target as broad a population as possible with our content and advertising.

Next Step: Optimizing Content for Mobile Devices

We’re already putting our content out there to be indexed by search engines. We’re already trying to market that content to folks via email, social media, and web and print ads in the hopes that they access it. And we’re already working to make our content perform optimally on various desktop browsers. The trick now is to make sure our users can get the best experience for that content on their mobile browsers too. Optimizing our content for mobile devices, including tappable phone numbers and links to Google Maps, is a natural extension of what we’ve been doing for ages. There is no separate mobile strategy. There is only an existing content strategy and working to make sure that that content is best presented to everyone.

This article was posted