Why we don’t use popcorn.js even though we love it

Playing with popcorn.js by Mozilla lately, I was musing at length whether and how it could be a component of our video strategy at Zeit Online. To come straight to the point – I don’t think it makes sense for us, at least not now. I’ll explain in a moment.

But first let me say that popcorn.js is lovely. If you browse the demo section, you’ll stumble over very interesting projects. Popcorn.js, even at its early stage, is a fascinating playground and I’m eager to see it grow.

So why do I think it doesn’t work for us? Two reasons.

1) Not everything that’s fun to play with fulfils an actual demand

Looking at the variety of popcorn.js demos, I’m torn between being impressed and scratching my head. While I admire the developing skills behind those projects, I doubt that real life user behaviour played a role in the creation process. From a video perspective, many of these projects will simply sink in user testing.

Watching an elaborately edited video piece with dense narration while being distracted by emerging maps, wikipedia content or rapidly displayed weblinks is painful. Human attention is limited by nature. That’s why we’re so bad at multi-tasking. It’s not helpful to demand more from viewers than they could possibly accomplish; even more – you’ll risk lowering the impact of your core story being told by video.

Two important additions here. First, audio is a different story. Check out Soundcloud and how they display comments for single tracks. As long as there aren’t too many of them, comments on the timeline can be fun to watch. There’s no other visual stimulus around, so no competing for attention.

Second, don’t confuse what popcorn.js is doing with the idea of a second screen for live tv/video events. Olympics, Red Bull space jump or US election night have one thing in common: People can afford to let go of focused watching for a moment and check Twitter, Facebook, apps, whatever. Even more – they’re thankful for distractions as soon as a lengthy live broadcast has its less exciting moments.

2) Don’t confuse our audience with people watching video on our site in a desktop setting

If you haven’t done it yet I’d encourage you to check out the popcorn.js demo projects with an iPhone. You will see that mobile is not a top priority for the popcorn.js dev community. No surprise here.

Popcorn.js is a powerful tool for building interactive stages and experiences around video – it needs room to unfold. That’s why the desktop browser is its natural home (at least that’s how most developers use popcorn.js so far). There’s nothing wrong with that, of course, at least as long as you’re not aiming for maximum reach. If you do, everything that’s not happening within the video is a problem.

Don’t get me wrong – from a theoretical perspective I love the idea of unbundling elements like text, subtitles, maps etc. from a video. Reality, however, is a beast. We’re delivering video (with dynamic ads) on our desktop website, with flash and HTML5 players from Brightcove depending on your browser choice; we’re additionally delivering video to mobile and tablet browsers, to our iPhone app and to our YouTube Channel.

Even this straightforward delivery with nothing but video files is technically challenging at times; we’re not satisfying every of our users on every device and we’ve still got a long way to go. Would we put future resources in a technology that doesn’t fully work on all of our delivery channels and doesn’t speak with the platform we’re monetizing with? I doubt it.

You might see popcorn.js at Zeit Online at some point, however, since we like to experiment. But I don’t see it in projects where we strive for seamless, maximum impact.

I’d love to hear your thoughts about popcorn.js and whether you agree or you don’t. I think the fundamental idea behind popcorn.js is smart and forward-looking, so do me a favor and debunk this post. If you reply to this tweet or to this post on app.net, I will gladly quote you here.