A significant portion of the Mozilla Foundation’s effort this year will contribute to Popcorn Maker’s eventual success, culminating in a 1.0 release in or around November. We’ve correctly identified that achieving this is a tall order, so we planned and roadmapped harder than I’ve ever planned and roadmapped before.

Update: The popcorn roadmapping PDF explains the entirety of the project from a high-level design perspective. Here is the lighthouse link to add your comments about what will be happening, and here is a direct link to the PDF.

Popcorn Maker - Here and Now

In the past, we treated Butter, and to some extent Popcorn.js, as means to an end – namely, Popcorn Maker. This model used to make sense: we were creating an app (Popcorn Maker), which needed an API (Butter) and underlying library (Popcorn.js) to make it all tick. With some vision from the foundation, and specifically from Ben Moskowitz and Brett Gaylor who have both blogged tirelessly on the subject, that outlook has changed significantly. And, I believe it’s for the better.

Butter

Previously, we wrote Butter, and quickly stuffed it underneath Popcorn Maker once it was "ready". Finishing the app-version of Popcorn Maker was a greater and more demanding task than maintaining Butter separately, so we hacked at it only to give us results we could immediately use. It even lost touch with its own repo as we voted to make it a git sub-tree instead of a sub-module (deserving a rather passionate rant).

As spiteful as I might sound, this approach wasn’t all wrong. There was simply no need to maintain an API that was going to be used directly by a handful of people for a specific project at an accelerated pace for a short period of time. Butter was classified as a library – the underpinnings – of its shinier cousin, Popcorn Maker. Luckily, though, as careful engineers do when they acknowledge reasonable fear and forethought, we kept Butter isolated so as to still be separated from Popcorn Maker by an API – just an ugly one.

Now, as I’ve already stated, things are a bit different. Some of the things Butter did well were identified as useful to other parties, and we don’t necessarily want to package the entire Popcorn experience inside of one app, Popcorn Maker. So, we’ve pulled out the Butter which lay unappreciated inside of Popcorn Maker, and given it its own repo again!

After a few iterations, Butter will be an SDK (the BDK, perhaps) to support the development of Popcorn-centric apps, exclusive of Popcorn Maker or not. It will retain control of editors and templates, but with an important architectural change.

With Popcorn Hacker, Scott Downe showed us that editing Popcorn directly in a page is a great feature – a feature which was downplayed by Popcorn Maker for sake of app consistency and safety. So, we’ve folded the idea back into Butter.

Butter is slimmer, and meaner. It lives directly inside the page it’s editing, so no postMessage loops are necessary. Bloat down, functionality up. With some external guidance (bookmarklet or manual insertion), it opens itself in a page (UI and all) and, with increased versatility, attempts to recongnize existing Butter or Popcorn data. When the user is done editing, Butter attempts to stay resilient and small, insisting only on HTML and JSON for storage – no external dependencies.

The result is an SDK which allows developers to create templates and apps based on the Butter library to take advantage of the UI elements and Popcorn abstraction which Butter achieves. Developing an app specifically for "making videos with contextual tidbits which popup at specific times" is as easy as building a design for the app with CSS and HTML (the template), and enabling the Butter library within it.

Also, we heard a loud cry from template and editor developers to have editors which interact directly with the template. Now, editors can live in the template, simply using the Butter API to interact with timed events.

Sounds great, right? Well, we’re only getting started: the 0.2 release is scheduled for the end of this month.

The Popcorn Software Suite (PSS)

With Butter sketched out as an broader SDK rather than a library with a struggling identity, the Popcorn software suite unfolds like this for 2012:

• Butter (SDK) - The SDK which will allow developers to build apps, including Popcorn Maker. Its library will reside inside of templates which enable Butter’s tools in a customizable fashion. It includes the usual UI pieces – a timeline, a plugin list, editors, and popups – all of which are programmable with API, and have management systems to govern them.
• Cornfield (Server) - The server component in the Popcorn software suite, allowing users to store their work, share templates, fork projects, and manage video content.
• Popcorn Maker (Site) - A site which encompasses Butter and Cornfield with a well-designed entry-point and fancy UI. This is where content galleries, ratings, profiles, and tutorials live, and will be as accessible as possible directly from our public-facing websites.

I’m particularly excited about being able to offer Cornfield, and specifically its Video Transcoding feature. This will let users upload their videos, and have them automatically cross-browser compatible (mp4, ogv, webm), which makes creating and distributing a project very simple.

Also, there is a focus on making each component easy to use and install. In general we want to use npm as much as possible to make Cornfield and Popcorn Maker installable packages with setup scripts (or web pages, like Wordpress) to initialize them.

Technical Roadmap

Aside from Butter, there is a lot of software to imagine, design, write and maintain this year in the Popcorn project alone. In an attempt to organize the team, I created a document which illustrates the features we need to complete, categorized by milestone and project.

Here’s an excerpt:

I really tried to stay away from assigning time to features, since I could only estimate from general experience how long each would take. Instead of spending time filing down a time estimate to precision, I attempted to give each feature a reasonable rating of effort. For example, the first top-left green block represents the Droppable Regions feature. It received a rating of 3 because I considered the amount of CSS detailing, the jquery-ui interfacing, and Butter-specific scripting we would have to do to complete it as a non-trivial amount of effort.

As you might have already noticed, features don’t necessarily exist in only one milestone; they can span milestones with varying degrees of effort, displaying three important areas in the lifetime of a feature:

1. Research and Design
2. Implementation
3. Bugs

The first two are sometimes lumped into the same milestone, but often there is special consideration for the bugs that are a result of the implementation of a feature. These bugs are separate from Bugs in general which have their own colour and path through the graph.

My favourite part of the document is the Summary graph:

I think it’s particularly interesting to see the shape of work as the year progresses. I wasn’t surprised to see a rough bell-curve, but its height in the beginning of the year is concerning. Either estimates are wrong and will be adjusted to reshape the curve (likely), bugs will be much more significant with respect to effort than anticipated (pretty likely), or we’ll just be working very, very hard the entire year (very likely).

Note that no graph takes into consideration the number of people working on the project, so, as more people contribute, the larger the spread of the effort in each milestone, which yields higher relaxation times and lower stress levels for engineers :).

Of course, by no means is this meant to be a perfect description of how the year will occur. There are bound to be features which slide into subsequent releases or get dropped altogether. There are also certainly some estimates I have made which will prove to be completely incorrect, either negatively or positively. The document is intended to be a living one, so throughout the year I will update it to keep track of progress and to hone feature estimates – for this project and for future ones.

You can find the document, in all of its estimated glory, here.