• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Jsconf 2011-us
 

Jsconf 2011-us

on

  • 3,583 views

The making of Yahoo!'s universal JavaScript player, by Dan Beam.

The making of Yahoo!'s universal JavaScript player, by Dan Beam.

Statistics

Views

Total Views
3,583
Views on SlideShare
3,342
Embed Views
241

Actions

Likes
4
Downloads
0
Comments
1

9 Embeds 241

http://developer.yahoo.com 197
http://www.techgig.com 23
http://lanyrd.com 10
http://feeds.developer.yahoo.net 5
http://www.ucrca.org 2
http://www.slideshare.net 1
http://developer.yahoo.com:9999 1
url_unknown 1
http://searchlogger.net 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • ‘ Sup guise. My name is Dan, and as you can by the liberal use of purple on my slides, I work for Yahoo!, haha. I ’ ll be giving a short presentation called “ How to be a player ... on the internet - the making of Yahoo! ’ s universal JS media player. ” So, let ’ s go.
  • First of all, what is Yahoo! Media Player? By a show of hands, has anybody heard of our player (or used it)? Cool. Because this is JSConf, I added a gist of how installation of the player should go...
  • Let ’ s do a quick demo now for those unfamiliar with our product, to see what it does for you. > Click link > Scroll down to third play button> Click in-page play button for Ben E. King: Stand by me> Seek to middle> Open 17. Atlas Sound> Find on page This is cool, but what if you want more customized experience? Don ’ t think we ’ ve forgotten about...
  • Developers! Our goal is to make our player hackable and as friendly to the developer community as possible.
  • The API we expose is an abstraction and common set of functionality we find useful for you to use the player in more advanced ways. We open up control of the playlist, player controls, view settings, engine ... pretty much everything, so feel free to change it ’ s behavior as much as you want. You can also just set a global environment variable that we listen to in order to change various aspects about your player (for instance, if it should automatically start playing or not). Let ’ s show a real quick demo I made to show some custom behavior. > Click link > Explain what we ’ re about to do (search YouTube, using our player to play links in page) This is an example of loading videos from YouTube based on a search parameter (so you ’ re doing it dynamically after the page is loaded -- so you ’ re not using the default parsing mechanism built in the player by default). > Play first entry for keyboard cat (original, preferably with sound, maybe seek?) > Do one more search (spiderman?) with the playlist open to show how we ’ re populating on every search
  • We also promote skinning of our player ’ s visual appearance (and a quite a few people do). We attempt to make things easily skinnable with either the replacement of our button sprite with a custom one or the easy use of CSS to do more advanced things (the new version of the player is highly CSS-ified, using CSS gradients, RGBA and hacks, and various ways of making skins easier to change for developers and designers). We also have plans to make a theme chooser in the future, so stay tuned for this.
  • Now let ’ s talk a little bit about our goals for this player in general, and what it strives to be.
  • Firstly, we want our player to basically be the easiest way to add audio and video to your site. With only 1 script tag we handle pretty much everything for you in an unobtrusive, efficient way. We host the files for you for free on a globally distributed CDN so you can sure it ’ s be fast and reliable. Another goal of ours is to change webpages into playlists, giving your user a richer and more delighting experience (which in turn makes you more money, :D).
  • You ’ ve probably heard of the terms localization, internationalization, well we also believe in universalization -- being able to use our player on any page with browser or device using type of media or service. Whether you ’ re a web ninja or not, our player should work seamlessly for you. Any browser, includes IE6 quirksmode and mobile. We try any available browser plugin in a large fallback chain (we ’ ll soon be looking for codec support and possibly a transcoding service as well).
  • So, let ’ s talk about how we go about supporting 60 combinations of browser, OS, and document mode. About Opera - technically, we don ’ t offer *as much* browser support (by Yahoo! ’ s Graded Browser Suport guidelines). However, though we ’ re not officially mandated to support it we attempt to do our best of the goodness of our hearts. <3 Opera
  • This a rich web application with tons of logic, so we chose to use a pseudo-classical inheritance model and a clear MVC separation. A lot of this is basically engine normalization and taming crazy browser quirks to accomplish the effects we want.
  • The engines we support don ’ t work exactly the same (some of them suck). Each engine names their events differently, fire these events at different times (if at all), and have quirks that we ’ ve come to know and love (or hate). This adapter pattern allows us to abstract all nitty gritty details.
  • This pattern allows each level of inheritance to abstract the functionality that other classes will need while putting for a standard interface. For instance, each component starts by inheriting from a base engine which basically allows them to publish and subscribe to events with some slight dependency injection in the middle. Then, each media engine inherits from an abstract engine class which requires features like play, pause, stop, or seek (if it ’ s supported). As we get more and more and more specific we allow a divergence from the ultra-generic to slightly more specific (i.e. video probably needs to be showing to be useful while playing, so the video engine overrides the base engine ’ s logic just a little bit here). This pattern works awesomely to allow us to drop in engines relatively quickly as well as tame bugs at any specific level (whether it be for 1 engine or all of them).
  • So another cool aspect of our player is that we have a fallback chain of supported plugins and media players that ’ s designed to give you the best experience possible using a number of environmental clues (operating system, browser, possibly bandwidth or device in the future).
  • A good example of us taking care of the logic for you are movie trailers. If we currently have “ automatic trailer finding ” built into our player to find a trailer for a movie you ’ ve linked to in a page (for now only with Yahoo! Movie Links, but we ’ ll support additional things in the future). So, if you simply reference a Yahoo! Movie page we ’ ll find the best trailer for the movie by querying Yahoo! Movies ’ API via YQL as well as searching YouTube ’ s gdata API (and using either respective player to play your movie).
  • But enough about us, on to you! One of the things I think is really cool about our player is that we go to great lengths to not conflict with your page ’ s scripts, styles, or performance. Let me take you through a couple of examples of how we avoid making your page anything but awesomer, :).
  • So, firstly, we namespace all our CSS with a common classname prefix (currently .ymp-, will likely change in next version). This helps avoid style collision, but we don ’ t stop there - to avoid both CSS and JS collision we don ’ t use IDs (in the new player) as they ’ re always global and we don ’ t want to limit ourselves to having to create dynamic IDs on the fly. We also like to reuse as much as possible from trusted codebases like YUI (for us, the YUI Slider widget), so we grab the corresponding CSS and namespace it with ant at build time using (glorified search and replace for our needs) as well as YUI ’ s CSS prefix mechanism (very cool). We also employ a contextual CSS reset. This is similar to those resets you ’ ve seen by Eric Meyer, YUI, or HTML5 doctor but only on a small portion of the page (to not mess up your styles and ensure ours are the same cross browser). We also do more than just normalize across all browsers. For the nodes inside our player we apply styles to override the use of globals styles like using only tag selectors (i.e. blink on anchor hover!).
  • We are also a little bit paranoid about protecting your JavaScript (after all, we make a living on it, too, :P). We don ’ t want to slow down your page, so we only bring the things we need with us (we seriously have to justify every byte and are crazy about reuse). During typical usage of just 1
  • AHHHHHIGH!
  • We minimize how many HTTP connections are required to get our assets to your page. One of the many optimizations we ’ ve done is building our minified CSS into a simple string in JavaScript. When the player is evaluated it creates a stylesheet dynamically and put the minified style string into that stylesheet. We do this from an ant target using YUICompressor and a template at build time. We also use CSS sprites (everybody should know about this) extensively, generally using only 1 or 2 images for all of the UI. We ’ re investigating using data URIs (for those browsers than can handle them) to put both background images and engines inline in our script to minimize these connections even more (though we have to make sure this actually doesn ’ t hurt if some things can be parallelized).
  • We query the whole document only once for the top level containers, then make relative DOM queries after that into each subtree. We cache a reference to the internal DOM queries so that we never need to get an element more than once during initialization. Event delegation is useful for things with many or an unknown number of items that need to be handled (i.e. play buttons, playlist items). It also catches or prevents the default for events that we might not want to flow up to the document (i.e. we don ’ t want to send your reader to the top of the page with a play button with href= ” # ” )
  • Lazy kitty is lazy.
  • Like I mentioned before, we load the player asynchronously in the background after you site is done loading. This helps your page render quickly as it ’ s not waiting to parse our JavaScript. But we do more lazy stuff as well. We defer embedding / downloading video engines until you actually play a video link, as well as lazily retrieve all metadata and fallback availability until you play each item.
  • We also use an awesome technology called YQL (Yahoo! Query Language) to do some server-side processing for us and send us back exactly what we need.
  • For instance, if we want to normalize empty fields, do some aggregation or manipulation of data, and filter out unnecessary data, we do it with Rhino in a JavaScript block. This allows us to use almost any data source and transmit only the bare minimum in JSON back to the client (as well as lets us cache this for any TTL we want). Living inside a solely client-side widget doesn ’ t give you much security, so we also utilize YQL ’ s access control to be able to differentiate operations and hide sensitive information. YQL conveniently gives you execute, read, and write keys which can be passed to your calls to differentiate users and security levels.
  • So now on to our future plans.
  • As you can see from our awesome visual, the next version of our UI will be much sexier. It should be faster, safer for your page, and more modernizd (incorporating the last couple years of front-end advancements). Let ’ s see a quick mock.
  • We also have plans to add more engines, media, and device support. HTML5 / is pretty clearly useful for our purposes, so we hope to be incorporating this soon (and hope the implementations solidify soon as well). This will hopefully give us engines for additional codecs that have native support for free. Another item high on our radar is mobile / tablet support (there aren ’ t too many players for iOS). We hope to support additional audio and video publishers (the landscape of this industry is quite different from when the initial version of this player came out). We are also going to add a social aspect to be connect others with media you especially liked or create relationships or relevance over the content of media you ’ re playing. And there ’ s much much more, so stay tuned.

Jsconf 2011-us Jsconf 2011-us Presentation Transcript

  • How to be a Player (on the Internet)
    • The Making of Yahoo! ’ s Universal JS Media Player
    JSConf US 2011 Dan Beam [email_address]
  • What ’ s Y! Media Player?
    • It ’ s a JS media player, so I ’ ll explain in JS:
    • (function add(one_script, your_page){
    • (jQuery || Y.one)('body')
    • .append('<script src=&quot;' + one_script + '&quot;/>');
    • your_page = 'AWESOME!!!';
    • })(' http://webplayer.yahooapis.com/player.js' , 'cool');
  • Demonstration http://www.reviler.org/2011/02/14/favorite-love-songs-four-takes/
  • DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS API / Customization
  • API / Customization
    • API
      • Many public methods on YAHOO.MediaPlayer
      • Env vars: YMPParams = { ' autoplay ' : true};
      • Allows you to create custom experiences
      • API demo - http://danbeam.org/ymp_api.html
  • API / Customization
    • // populate content
    • content.innerHTML = '<span class=&quot;item&quot;>' +
    • spans.join('</span><span class=&quot;item&quot;>') + '</span>';
    • YAHOO.MediaPlayer.addTracks(content, null, true);
    • YAHOO.MediaPlayer.play(); // play first item
    • setInterval(function(){ // start cycle
    • YAHOO.MediaPlayer.next();
    • }, nextDelay);
  • API / Customization
    • Skinnable markup
      • You only need to change 1 image
      • All the rest easily styled with CSS
      • More preset themes in the future
    Yahoo! Search skin
  • Our Goals
  • Our Goals
    • Easy to install
    • <script src=&quot; http://webplayer.yahoo.com/player.js &quot;></script>
    • From page to playlist
      • Mixing audio and video in the same page is sweet
      • Richer experience (adds to page, isn't annoying)
  • Universalization
    • We want our player to work anywhere
      • Any page (even your cat's blog)
      • Any browser/device (desktop, tablet, mobile)
      • Any media/service (we ’ re adding more playback mechanisms / providers)
  • Universalization
    • How would you go about playing any media type on any platform?
    Well, kinda... Sorry, @miketaylr, :(
  • Flexible Architecture
  • Adapter Pattern
  • Adapter Pattern BaseEngine VideoEngine YahooVideo YouTube QuickTime Flv Rhapsody Flash HTML <audio> HTML <video> AudioEngine
  • Graceful Fallback
    • NOTE: Nimrod is another developer on the project
    • (and he ’ s really smart)
  • Graceful Fallback
    • MP3 link
      • Headless Flash Engine w/JS API
      • Windows -> WMP -> QuickTime
      • OS X -> QuickTime
    • Yahoo! Movie link ( http://movies.yahoo.com/movie/1810099246/info )
      • Yahoo! Movies API (via YQL)
      • YouTube (gdata)
  • But enough about us - on to you!
    • We co-exist with your page peacefully. **
    ** Unless your page is still on gopher
    • Namespacing
      • Our own class namespace (currently .ymp-)
      • No #IDs (always global, too risky)
      • Ant <filterchain> on YUI3's widget CSS at build
        • from .yui3-slider-widget { } to .ymp-slider-widget { }
    • Contextual CSS reset (protect our player ’ s style)
      • from html, body , div, ... to .ymp-reset div, ...
      • protects against a { cursor: crosshair; }
    Peaceful co-existence - CSS
  • Peaceful co-existence - JS
    • Minimal included dependencies
    • Small loader with one URL that always gets the latest version for you
      • Full player cached forever (including on other sites)
    • We don ’ t touch natives (Array, Object) (*cough* Prototype, Mootools *cough*)
    • We don ’ t conflict with any other libraries (including YUI)
    • We only introduce 1 global - YAHOO.MediaPlayer
  • Performance
  • Less is more
      • CSS-in-JS (minified CSS is built into the JS)
        • Combine/templatize at build time with Ant
      • CSS sprites
      • Investigating inlining data URIs for assets
    (When it comes to HTTP requests)
  • DOM caching / delegation
    • We cache DOM queries
      • As smartly as possible
    • Event delegation (kind of a must these days)
      • Less memory spent on event handlers
      • Catches extraneous events (if we want to)
  • Async laziness (D ’ awwwwww!)
  • Async laziness
    • Non-blocking (asynchronous append onload)
    • Lazy-loaded assets and media resolution
      • Media item resolution (we don't get metadata ‘ til you play something)
      • Yahoo! Video Player
      • Yahoo! Movies metadata through YQL
      • YouTube Player
  • SSJS via YQL
  • SSJS via YQL
    • YQL server-side processing with SSJS in an <execute>
      • Cached with YQL ’ s caching and our own
      • Only transmits what we need
      • Adds some information hiding / security
        • Access control per operation (r, w, x)
  • To the Future!!!
  • New UI
    • Sexier, Faster, Modernizd
  • More engines/media/devices
    • HTML5 <audio>/<video> (srsly, this is a big deal)
    • Additional codecs and services
    • Mobile / Tablet
      • Smaller version for all mobile devices / tablets
      • iPad / iPhone / iTouch support
    • Support additional video and audio publishers
    • Add Social (Twitter, Facebook, IntoNow)
    • ... and much much more!
  • Thanks for listening
    • If you have any questions or comments, let us know!
    • Dan Beam
        • email: dbeam@yahoo-inc.com
        • twitter: @danbeam
        • site: http://mediaplayer.yahoo.com
  • Credits
    • Images courtesy of:
      • http://flickr.com/28268402@N03
      • http://flickr.com/dancoulter
      • http://flickr.com/nimrodbar
      • http://flickr.com/e2
      • http://flickr.com/emilymills
      • http://flickr.com/hoanghaithinh
      • http://flickr.com/rongorongo
      • http://flickr.com/programmerman
    • (Did I mention Flickr rocks?)