Archive for June, 2011

To a grade 6er, when is the web malleable?

Posted in open source, video, webmademovies on June 30, 2011 by scottdowne

Yesterday, while working with a classroom of grade 6ers on their Butter projects, as briefly mentioned in the end of a previous post. I had one of the kids ask me a pretty awesome question “which error console is the best”? He then showed me the FireFox error console, and web console. I responded to his question with “FireBug”, which he promptly responded to with “what’s that”? I said “It’s an add-on”.

Less than a minute later…

“OK, I have FireBug, now what”? I show him the very basics, like how to open it, how to move it to a new window, back to inside the browser, and where the shiny new console lives.

What was really cool, is when I showed him that you can change elements on the page, by selecting it, and changing it in the HTML tab. I showed him this by going to Google, and changing the text in the search bar to a bunch of nonsense. His eyes lit up, and he was on the path of destruction.

He hit a moment where the web was no longer a tool to get information or a toy, but a canvas that he can change. Luckily, he quickly understood that he was only changing his version of google, and not everyone else’s version of google. Few minutes later he was removing chunks of a webpage, because he could. He didn’t really understand his actions yet, until after he made the changes, and experienced the results. It’s a science.


Popcorn.js event effects framework landing in 0.7

Posted in open source, Uncategorized, video, webmademovies on June 23, 2011 by scottdowne

We’re just finishing up Popcorn.js 0.7.

One of the major things landing in this patch, is effects.

Effects are not just limited to effects, so we also decided to use the word compose. This allows our largest use case being effects to be obvious, but we also make it known that on a more abstract level, something exists. This way, the API itself is speaking the language of the user.

You create an effect plugin almost exactly like you create a regular plugin.

You can create a plugin like so:

Popcorn.plugin( "pluginname", {
  start: function( event, options ) {},
  end: function( event, options ){}

So create a plugin name, and define some functionality for start and end. Note, this is a very minimal example, as I was not intending to get too deep into creating a plugin.

Anyway, you can create an instance of your plugin like so:

  start: 1,
  end: 5

This means, between 1-5 seconds in the video, your defined start function will be called, and when it leaves the 1-5 time range, it’ll call your defined end function.

Effects work similar in creation, but to create an instance from an effect, you apply it to another plugin instance “composing functionality”.


Popcorn.compose( "effectname", {
  start: function( event, options ) {},
  end: function( event, options ){}
  start: 1,
  end: 5,
  compose: "effectname1 effectname2" // this way, we can apply as many effects as we wish

So now, that single plugin instance has the functionality of the start and end functions of the effect. Something to note is currently, the original plugin’s events fire first, then any composed events will be fired in the order they appear in the compose list.

Here is an example of it all in action.

Here, I create an effect for applying a css class name to the event’s target on start, and after 250 milliseconds later, it’ll go away. Using this, the potential for using CSS transitions is huge.

A more simplified demo.

Here, I do this:

    document.addEventListener( "DOMContentLoaded", function () {

      var p = Popcorn( "#video" )
        start: 5, // seconds
        end: 15, // seconds
        target: "footnotediv",
        text: "This video made exclusively for",
        effect: "applyclass",
        applyclass: "test1, test2"
        start: 20, // seconds
        end: 45, // seconds
        target: "footnotediv",
        text: "Visit for more details",
        effect: "applyclass",
        applyclass: "applyoverlay: .overlay, hover: parent"
    }, false);

What is happening here is the first footnote is simply having the two css classes applied to their target’s on start, and removed on end. Pretty simple.

The second footnote is not so simple. Here I am using CSS selectors split by semi-colon “classname: selector, classname: selector”. classname is the name of the class to apply, and selector is the target to apply it to RELATIVE to the target.

I want to stress that compose and effect are the same things, and that applyclass is only ONE example of how to use this. This is not limited to effects.

This is all pretty new stuff, and what I’ve just written is as far as I know the only documentation for effects. So anyone attempting to build an effect right now, is a trail blazer!

Butterapp new release candidate

Posted in open source, Uncategorized, video, webmademovies on June 15, 2011 by scottdowne

Butter app is about to release 0.3.

The above link is an older version. The release candidate can be found here.

The best of the new features are:

– Youtube support. You can now enter a youtube url as your video.
– draggable track creation. You drag a command from the bottom right menu onto the track to create a track.
– html and css bases track dragging. The old version used a canvas, and now we’re using jquery draggable and droppable.
– one preview of a track at a time.
– finally, you can now import univarsal subtitles as explained in my last post.

We also have a class of grade 6ers using and testing this software. I’m pretty excited about that, as I heard children are the best at finding bugs.

Popcorn.js + Butterapp + Universal Subtitles

Posted in open source, video, webmademovies on June 8, 2011 by scottdowne

Today, I finished up integrating Popcorn.js and butter with Universal Subtitles.


All you do is, enter a URL that has already been Universal Sub’ed on the opening page, under “Create a New Project”. Here is a URL you can test with:

Next step is, after the video loads, click “import project” on the top menu, and click “Universal Subtitles”.

This will load in all the subtitle data associated with that URL, via Universal Subtitles.

The subtitle data is not yet being displayed in the track, but I assure you, when you play the video, you should see subtitles over the video.

What is so cool about this is, you don’t have to sub the video yourself if someone already has. Just click “import project” -> “Universal Subtitles”. Also, once youtube lands inside butter, that should just click together!!!

Next step is, obviously, to display the subtitles in the timeline, but that will be much easier after my trackline ticket lands.

The less code that touches my code, the better

Posted in open source, video, webmademovies on June 8, 2011 by scottdowne

When developing software, always look for potential APIs. An API is an Application Programming Interface (API). That is, the interface software uses to communicate with other software. On a basic level, you’re breaking a larger problem into smaller ones.

APIs have some pretty HUGE advantages.

– Easier to test (automated). Example: When you are adding after manufacture features, you have to rely on tests to give you confidence that you are not breaking something. Right, pretty common. But, when tests are all testing separate parts, it is much easier to find where and what went wrong. Also, take for example a large web application like butterapp (I will use this as an example again). How does one test an application built around visual, UI, and interactivity with automated tests? Simulate a bunch of clicks, and compare the pixels? Or, start at the other end, the first thing that happens when that click happens, and work your way up to the actual click. Think a large engine, you can test the engine. Or, you break it into smaller engines, that sends commands to the larger engine. The smaller piece knows everything it is capable of doing, so you test everything it can do. You’re not testing end results, but functionality of the pieces. You’ll also come out with much stronger tests as a whole. That being said, no harm in visual tests of the end result as well. You can never have too many tests.

– Easier to maintain. Once you know where something is broken because a failed test led you to the broken area, you can lift it out, re wire its internals, and put it back in and none of the other parts know anything has changed, because the interface is the same. Adding new features become much easier, because an API is designed from an abstract point of view. You can easily change the way the parts interfaces with the other parts, to get different results. It is easier to read, like a book, to a point. A badly designed API is just spaghetti code. A good way to avoid this is to keep in mind that the less code that touches your code, the better. Modular, dynamic, and living in its own scope. We don’t share our Tupperware with our neighbors here.

– Distributable. Never know, someone else may have a need for the pieces in your engine, to use in something completely different. This also opens up my last point.

– Collaborative. Once people start using it for other things, to solve other problems, your community will grow exponentially.

What made me ramble about all this?

I’ve been working on something called butterapp, which is the front end registration tool for popcorn.js. Inside Butter, is a visual track, containing events attached to a timeline. So me and Bobby Richter specced out trackLiner.js. Here is an older demo I did to show while it was in mid development. And, here it is, updated, and plugged into butter.