Bad films are bad

New profile pages & Netflix giveaway

2012-12-05T12:00:00+11:00

Everyone’s profile page just got a massive overhaul. Check out the team’s profiles at John, Glen and Charlie for an example.

You now have a personalised ratings graph to share with friends, a list of your favourite and worst films and a public queue of movies you’re itching to see.

As an extra sweetener we’re giving away three 6 month Netflix memberships throughout December. That should help get you through your queued backlog of films.

How to Enter

Simply share your profile page to Facebook and you’re done. Just sign into Goodfilms, go to your profile page, and click the share link.

We’ll be announcing winners on the 22nd December.

Good luck!

Goodfilms

Goodfilms is a way to share the movies you watch with your friends. We rate movies on two criteria - ‘quality’ and ‘rewatchability’, so you can admit to your guilty pleasures and properly capture the feeling you get when a film leaves you exhausted. Sign up now and keep track of the films you love, and find great, challenging or silly new ones to watch.

Goodfilms & Hopscotch Movie Pass Giveaway

2012-10-12T16:00:00+11:00

Thanks to the generosity of Australian film distributor Hopscotch we’ve got 5 double passes to To Rome With Love and 5 double passes to Seven Psychopaths to give away to some of our lucky Australian users.

How to Enter

To go in to the running, just add To Rome With Love or Seven Psychopaths to your queue before 5pm Thursday the 18th Melbourne time.

For an even bigger chance to win, we re-enter you in the draw every time you get a friend to sign up to Goodfilms between now and the end of the contest.

Goodfilms

The Minimum Viable Rails stack, now Reddit frontpage approved.

2012-09-15T13:00:00+10:00

This week we hit a bit of a StumbleUpon bonanza, landed on the Reddit front page, and got featured on Lifehacker. These three things threw quite a bit of traffic our way, and we got through it all with around 3 hours of degraded performance, and patches of intermittent bad gateway errors. Not too shabby.

With alarmingly serendipitous timing, two weeks ago I did a presentation at the Melbourne Ruby group on Scaling Rails. I posted the talk and my explanatory notes on my personal tumblr for two reasons. The first is that it includes a bit of my personal, subjective, and somewhat unsubstantiated ideas on developer types and ops, and I prefer to keep those kinds of musings off the team blog.

The second was that while I’d promoted the idea of the “minimum viable stack” which, while I thought pretty sound (and bet Goodfilms’ tech direction on), was untested. This week we gave it a solid thrashing, so it’s time to promote it as “official Goodfilms policy”.

The TL; DR is that it worked, Mostly and I’m now even more comfortable recommending the stack as a good starting point.

The “Minimum Viable Stack” for your just-past “Minimum Viable Product”

In my presentation I suggested that the “golden stack” for a rails app just out of its’ MVP stage is roughly:

Deployed to a cloud provider like Amazon or Rackspace
Uses MySQL or Postgres as the datastore, deployed to a single instance, with frequent data backups to cloud storage
Has two “app instances”, which host both your web processes and delayed job workers. Each instance should be capable of holding all your regular traffic
Load balances web requests between the two app servers (with health checks enabled) using whichever magic load balancer your cloud provider gives you
Performance monitored using either Scout or NewRelic, or both if you like

There’s more detail over on my original post, but the key inputs into that design is were:

Low chance of “off the air” downtime, despite cloud servers being notoriously “ephemeral”
Lowest operational cost, except where it grossly impacts the above point
Favouring simplicity, except where it grossly impacts the above two points
Favouring traditional SQL databases as it’s the storage paradigm Rails “grew up with”, so has the best tooling and knowledge in the community
Favouring SQL again as if it becomes the bottleneck you can vertically scale it just long enough to get you out of trouble, and easy to hire experts to help
Avoiding vendor lock in where possible

The Goodfilms Stack

Goodfilms’ setup is almost exactly what I listed above. We run Rails 3.2, use Postgres as our datastore, host on Rackspace cloud using both their load balancers and cloud storage/cdn on top of regular cloud servers, and monitoring the whole setup using NewRelic.

The only departure from the stack listed above is that we have a third server setup as a general utility box. It has two main jobs: import catalog data from Netflix, iTunes, and the Movie DB, and also to run our elaborate taste comparison engine codenamed “Project Ingen”

So, that’s the background, lets talk about what happened, what worked well for us with the stack, and what didn’t

What Happened?

I’m just going to focus on the Reddit front page part of the story, because that’s where the interesting things happened.

For a long time, we’ve thought that there a lot of people who want to pay for film content, and that one of the things Goodfilms can do is help those people find the best things to watch that are available legally. To test that assumption, we did a couple of MVP (minimum viable product pages) for both iTunes and Netflix.

If you look at the iTunes page, you can see how minimal our minimum is, as we’ve not yet upgraded that page. Seeing that the Netflix page was pulling in enough organic search, we tasked our talented new designer Charlie with taking the Netflix page to the next level and see how far we can take it.

Once Charlie was done with it, it looked like we had a winner. Realising that a lot of people might want to use the page, I took a full day to double check all the performance of the queries in the page and fix up what I could.

NewRelic had shown us that the MVP page was only just scraping through performance wise, which is fine for a proof of concept, but not fine for a page you want to load. Once everything was looking OK in the front and back end, I gave the thumbs up to Glen to “throw as many people at it as he can find”.

There are quite a few people on Reddit, and Glen found them, and got a good section of them to come and use it.

What might not be immediately obvious is that we’re based in Australia. The bulk of the Redditing happened in the middle of the night, and so Glen rang me up, pulled me out of bed, and we babysat the servers.

A few hours later we both went back to bed, confident that the site was going to stay up, and very pleased with the influx of new users. In those hours, we added a couple more app servers, and set up full page caching for signed out users.

What went well?

The first thing that went well was taking the time to look at the performance of our new features, doing some work, but not overdoing it.

Defining “good enough” performance for as yet unproven features is tricky, especially when taking into account the opportunity cost of the dev time that can go into other features.

In this case, we got the balance right. I spent about a day getting performance to OK, and it was good enough to degrade gracefully under load, rather than explode. That gave us the breathing room to do the rest of our work in the middle of the night, without having wasted too much time beforehand when we were unsure of it’s success.

The other thing that worked really well was a direct result of three stack decisions that interrelated: host on the cloud, and split your app servers early, and monitor performance using NewRelic.

When traffic started climbing, we quickly switched our NewRelic subscription up to the pro level. We can’t afford to run it all the time, but it’s easy to turn it up when you do need it.

Under heavy load, there are generally only two things I want to look at in NewRelic: is there any page that is ridiculously broken from a performance perspective, and do we have enough capacity. If performance is broken somewhere, fix it. If you don’t have capacity, add it.

This time, all the pages were OK (because of the small upfront investment of work), but we did have a capacity problem. This did not take us long to figure out, because this is what NewRelic is good at. First design decision validated.

To add capacity, we just took a snapshot image of one of our app servers, and then spun up new servers directly from the image. This was pretty easy, but if we weren’t on commodity cloud hosting, it couldn’t have happened and we would have been boned. Second design decision validated.

Cloning the servers “just worked” because by keeping the database away from the app servers made sure there wasn’t any hidden coupling there. Moving to two app servers early made sure we weren’t accidentally relying on shared state. It’s the old programming truism about there only being three numbers in computing: zero, one, and many. Once you have “many” servers, adding new ones is no stress.

The final thing that worked well was following the idea of stack simplicity. I had worked a long day polishing the Netflix page code, then had my final game of indoor soccer for the season (with a win), and then went to the pub to celebrate with my team.

The only things that made working with the stack tricky that night were personal, not technical: I was tired, and not 100% sober. If simplicity wasn’t a core tenet of the stack, we could have kissed that uptime goodbye.

What went poorly?

In the presentation to the Ruby group, I stressed that you really needed to understand what the workload for your app is, and find the best bang for buck scaling strategy and use that.

Until this week, I’d been treating Goodfilms purely as a social network, and picked all our strategies to match that. The realisation that we’ve had as a team lately is that Goodfilms really is two sites living side by side: a community site/social network for films, and a rich content site for browsing for films.

With content based sites, full HTML page caches are your most cost effective technique for dealing with load. We didn’t have any page caching in place at all.

Glen’s flatmate Ben, de-facto ops guy for theconversation.edu.au and expert in content based sites chipped in and got us our first cut of page caching in place. This got load under control, but meant that signed in users weren’t getting the proper experience for that page.

The next step was to set things up so we could do signed in vs. signed out caches on demand. This was a little tricky half asleep, but we got there in the end. If you’re interested in how it works, you can check out the specific nginx config and capistrano task I wrote here and it might help you out of a jam.

The “frequent database backups” policy caused us a few headaches. Doing a full dump of a growing database while it’s under load isn’t what I would call “ideal”. That said, I’d rather have a periodical couple of bad gateway errors than risk data loss, so I’d still do it the exact same way again.

If I come up with a better balance of low cost/good uptime/good performance I’ll refine my suggestion for the datastore, but for the mean time I’m sticking with it, but flagging it as an explicit trade off you’ll be making if you follow our stack suggestions.

Final thoughts

I can’t say we’re 100% web scale. Staying up half the night with your servers means you’re not there yet. I think this is OK for where we’re at as a business. We’re still feeling our way through to the final feature set of the product, and learning what our market is like. Too much engineering now would be premature.

I strongly believe that there are no “right” answers in scaling a web app, but after giving this stack a solid thrashing, I feel very comfortable putting it forward as a good starting point. It’s a solid base from which you can respond to growth, and evolve it to match your situation well.

Make sure you put the machinery in place for page caching early, even if you’re not using it. The code is easy to write when you’re relaxed in the middle of the day, and a royal pain in the ass in the middle of the night.

Updated: If you found this useful please discuss or upvote over on Hacker News

Goodfilms

Why ratings systems don’t work

2012-08-22T14:00:00+10:00

Today’s XKCD reminded us of a problem we’ve known about for a while:

A little over a year ago, we started building a movie site with this exact problem in our sights - how could we make film ratings more useful? Bad ratings are all over the internet, and as someone who’s tried to make an improvement, I thought it was worth responding.

The problem with average ratings

Average ratings are, in their essence, an attempt to distil the entire set of ratings about an object (in our case, films), down to a single number. Which seems useful - after all, it saves you so much time deciding whether something’s any good. The problem is that that’s all it’s good for - telling you whether something’s good or not.

If you come across a film and see it has a 7.5+ average rating on IMDB, it’s a sure bet it’s going to be well made, and plenty of people must like it (whether you will, or not, is another matter). If the rating is below a 6.5, you should probably be wary. The rating scale might have 100 points on it, but all the useful ratings are crammed into the top third, and suddenly things are looking like XKCD’s example above. This is the same situation for Rotten Tomatoes ratings, too - great for the ‘is it decent/is it awful’ discussion, but without any depth.

Histograms are even worse

So, if a single average rating isn’t enough, maybe it’s valuable to show the spread of people’s opinions, to try to give a bit of ‘colour’ to the ratings. After all, if something was polarizing, there’s a chance you’ll hate it. The problem is, histograms are just. awful. Let’s look at some real world examples:

Starship Troopers

Fifth Element

Blade Runner

I don’t know how this is supposed to help you beyond telling you ‘these are all 3.5 to 4.5 star films’, which you probably already knew. After all, these movies are superficially similar (well-known science fiction films), but anyone who has seen all three would agree that they have a vastly different character, and appeal to different kinds of people. The histograms aren’t enough to capture that, they end up just adding confusion.

See patterns, not averages

Within Goodfilms, films are rated on two axes - first there’s quality, which is the 5-star system everyone’s used to; and then there’s rewatchability, how much you’d enjoy watching that film again. It means we can display ratings on a graph, instead of a line, and it’s able to convey a lot more information. It takes a little getting used to, but it can capture both the ‘good or not’ question of an average rating, as well as an understanding of the kind of film it might be. The key is that people are really good at seeing patterns, and a scatter plot caters to that. Let’s compare the examples from before:

Starship Troopers

Now, the top of the graph is ‘highly rewatchable’, and the right of the graph is ‘high quality’. So, these ratings say that there’s a lot of disagreement over whether it’s high quality of not, but generally this scores high-rewatchability. So, maybe not the most intelligent movie, but good fun.

Fifth Element

Here we have a cluster in the top right of the graph around 4/5 quality and 4/5 rewatchability. But more interestingly, almost nobody thinks this film is worse than 3/5 in either dimension. Which is great - it means you’re likely to enjoy this movie.

Blade Runner

Blade Runner clearly has the highest quality film of the three, but doesn’t have as many high-rewatchability scores as Fifth Element. This happens with a lot of classics (which Blade Runner is, without a doubt) - they’re very interesting and rewarding to watch, but you wouldn’t rush out to see it again. So, watch this if you’re in the mood for something really good.

We’ve done better

The point of this is we can do better than a 5-star ratings system, and at Goodfilms we think that two ratings, quality and rewatchability, is the right one for films. We’d love to know if you agree, and we would really love to hear about other people who are trying their own novel ratings systems for their own domains. Let’s move past the simple 5-star system, shall we?

Goodfilms

AngularJS and the Goodfilms mobile site - Part 1

2012-08-13T14:00:00+10:00

Following on from the release of the Goodfilms mobile site, we received a lot of requests for a more detailed post on how we used AngularJS, and what we thought of it. In this Part 1 we’ll talk about how we use Directives to isolate some mobile-specific logic and keep them maintainable.

Before we get started, let’s take a look at what the mobile site looks like:

Choosing AngularJS

We evaluated Backbone, BatmanJS and EmberJS before settling on AngularJS. Once we found Angular we stopped looking at alternatives - even after the first few experiments we found it to be way out in front in the client-side framework arms race.

The most immediate difference was that your application is fundamentally described in the HTML. Rather than defining an application as a hierarchy of JS ‘classes’, then an implicit or explicit render step to populate the DOM, you describe a great deal of the functionality of the site in HTML. This was a little jarring, and almost reminiscent of adding ugly snippets like onclick=’callGlobalFunction(); return false;’ to your <a> tags. But in practice, it has none of the nastiness that approach leads to, due to the cleverness of coupling Controllers to sections of the DOM, and the genius of Directives.

If you are interested in learning more about the concepts in AngularJS, the documentation and examples on the official site are excellent. You could also check out the presentation I gave to the Melbourne Rails meetup, which is itself an Angular app (source here).

Controllers - your neatly scoped friend

The golden rule of Controllers is to keep DOM manipulation out of them. Instead, you update a $scope object and Angular propagates those changes to the DOM. In practice, Controllers map really well to the functional components of your application - in Goodfilms mobile, there are six,1 three of which are visible here:

The other three are FilmDetail, Search and Queue. You can see them in action in the video at the top. We’ll be mostly focussing on the top level of the application in this part - the FrameController:

The app structure

<body ng-controller="FrameController">

  <header ng-class="{menuopen: menuopen}">
    <div id="header"> … </div>
    <nav id="menu"> … </nav>
  </header>

  <div id="main" ng-class="{menuopen: menuopen}">
    <div id="stage" ng-view>
  </div>

  <script type="text/ng-template" id="/views/feed.html"> … </script>
  <script type="text/ng-template" id="/views/film.html"> … </script>
  <script type="text/ng-template" id="/views/list.html"> … </script>

</body>

The FrameController is scoped to this section of the DOM, but not to any domain objects yet, which means its only job really is to update its $scope. Let’s look at a simple task - showing/hiding the left menu drawer.

In the HTML above, we add the ng-class="{menuopen: menuopen}" declaration to a couple of elements, and Angular ensures that if variable ‘menuopen’ is truthy, the class ‘menuopen’ will be set on the header and main. So, with the following controller code and css:

frame_controller.js

function FrameController($scope) = {
  $scope.toggleMenu = function() {
    $scope.menuopen = !$scope.menuopen;
  };
};

frame.css

body >header, #main {
  -webkit-transition: 0.3s -webkit-transform;
}
.menuopen {
  -webkit-transform: translate3d(280px,0,0);
}

We have a nice way to slide the menu (part of the header tag) in from the left, and slide the main content away. But we need a way to call toggleMenu() from the DOM. This is where AngularJS really shines.

Tapping vs Clicking

One of the most commonly-encountered differences between desktop and mobile is the handling of click events. We’re primarily targeting iOS Safari, which will send three events on a simple tap. These are ‘touchstart’ and ‘touchend’, which fire immediately as you, well, start and stop touching. Then, Safari waits 300ms to see if you’re double tapping, and if not, sends a ‘click’ event. If you only use click events, the user experience is a 300ms pause before the app responds to every tap. It’s a big contributor to the sense of ‘non-nativeness’ that mobile web apps can have, and we can do better.

How does this look in an Angular app? Well, the normal, desktop way of toggling our menu would be to use ng-click:

<div class="icon menu" ng-click='toggleMenu()'></div>

Clicking on this icon will fire the toggleMenu() action on the controller and AngularJS will set the classes on our elements. And the CSS transition will neatly slide the elements into place. But this is for a click event - Angular provides no built-in way of handling touch events. Oh gnoes! What are we to do? Oh wait, it’s unbelievably easy.

Directives - DOM magic begone!

Well, the DOM magic is still there, it’s just beautifully isolated. Let’s start with the naïve example, where you just bind to touchstart. This will at least get us around the 300ms delay:

Your first Directive

app.directive('gfTap', function() {
  return function(scope, element, attrs) {
    element.bind('touchstart', function() {
      scope.$apply(attrs['gfTap']);
    });
  };
});

In the above, app is the Angular app object, though it could just as easily be a service you mix in to your Controller if you want to isolate it. The signature return function(scope, element, attrs) {…}; is the simplest-possible directive syntax, very useful when all you want to do is bind an event.

Before going on, I’ll present the same code in Coffeescript, since that’s how the Goodfilms app is written, and because I think the two work together so well. I disliked BatmanJS because it forced you to go full-coffeescript, and I appreciate that Angular has made an effort to make a beautiful Javascript library, which simply gets more concise by switching to coffeescript. Here’s the same, naïve example:

Your first Directive, in Coffee

app.directive 'gfTap', ->
  (scope, element, attrs) ->
    element.bind 'touchstart', -> scope.$apply(attrs['gfTap'])

This, I think, is easier to understand, and it says that the ‘gfTap’ directive means execute scope.$apply(attrs[‘gfTap’]) on ‘touchstart’. That snippet is how Angular internally calls a Controller function - it’s the same for ng-click. We can update our HTML to use our directive:

Using our directive

<div class="icon menu" gf-tap='toggleMenu()'></div>

Now our toggleMenu() method is being called but without waiting for a click event. In fact, anywhere you were going to use an ng-click you can now use a gf-tap, and you’ve beaten the 300ms delay on mobile without complicating your HTML or your Controller. Boom!

Directives isolate complexity

There’s a problem with our naïve gf-tap directive, however, which is that when scrolling or swiping, the ‘touchstart’ event is still triggered, but it isn’t a tap. Safari will actually send a ‘touchmove’ event in these cases, so we should prevent the Controller action from being fired if we detect one:

A smarter gf-tap

app.directive 'gfTap', ->
  (scope, element, attrs) ->
    tapping = false
    element.bind 'touchstart', -> tapping = true
    element.bind 'touchmove', -> tapping = false
    element.bind 'touchend', -> scope.$apply(attrs['gfTap']) if tapping

What we’ve done here is a fixed a bug in our javascript by making our gf-tap directive more sophisticated, but we didn’t need to change anything else. That’s a sign of clean, maintainable code, and I love that Angular makes it so easy.

Once-off Directives

Directives aren’t just for reusable event logic such as gf-tap above, they’re also ideal for interfacing with third-party libraries. We use Zepto.js and its plugin Flickable.js for the swiping of movie posters in the feed, and use a directive to wire it up. This is how it looks:

gf-flickable.js

flickable = angular.module("flickable", [])
flickable.directive 'gfFlickable', ->
  (scope, element, attrs) ->
    el = $(element[0]) # get a Zepto element

    # initial state - the first is selected
    scope.selectedIndex = 0
    selectedEl = -> $(el.children()[scope.selectedIndex])

    tapping = false
    el.flickable
      segmentPx: 245

      # Once again, we detect a tap event and show/hide the buttons
      onStart: -> tapping = true
      onMove: -> tapping = false
      onEnd: -> selectedEl().toggleClass('showbuttons') if tapping

      # If we're moving to a new element, update everything
      onScroll: (eventData, newSelectedIndex) ->
        # Hide the buttons on the old one
        selectedEl().removeClass('selected showbuttons')

        # Show the buttons on the new one
        scope.selectedIndex = newSelectedIndex
        selectedEl().addClass('selected showbuttons')

        # Tell the rest of our app
        scope.didFlick()
        scope.$apply()

feed.html

<ul id="feed" gf-flickable>
  <li class="event" ng-repeat="event in events">
    …
  </li>
</ul>

The key here is that all the DOM manipulation is one place, and the controller action didFlick() can do important stuff (in Goodfilms it lazily loads the next image to be displayed and fetches more events if you’re near the end of the list) but the two don’t overlap.

This example is good, I feel, because the code within gf-flickable.js is pretty similar to code you might be writing already, but Angular lets you encapsulate it in a directive, making your app more maintainable with hardly any effort. It means that the id of ‘feed’ on your ul isn’t both used to attach events and styles, too, which is a bonus.

Wrap-up

We got a big benefit from Angular - it helped us focus on dealing with the various challenges of mobile touch interactions separately from modelling our domain logic and separately from our presentation. Those goals can certainly be met with any good JS framework, or even with disciplined framework-free JS, but we found Angular repeatedly led us to good solutions quickly, and with minimal code.

Next time, we’ll start by talking about what happens when the AngularJS abstraction breaks down, and we have to break our golden rule. Until then, please let us know your feedback, and if you haven’t done so already, sign up to Goodfilms!

Goodfilms

Goodfilms goes mobile

2012-08-09T14:00:00+10:00

We’re excited to announce the beta version of the Goodfilms mobile site! We’d like to talk a bit about the goals for building this, and some of the design inspiration behind it. We’ll also talk a little about how its put together using the absolutely excellent AngularJS.

The site’s optimised to give existing users of our site access to their Queue whenever they need it and the ability to rate a film when they’ve just seen it. And, of course, to help them keep up with what movies their friends have been watching, or want to go see.

The process

We asked our users what they most wanted out of a mobile version of Goodfilms, and we came up with the following three use cases:

I want to search for and rate a film I’ve just seen (while walking out of a cinema)

I want to see what’s in my queue (while at the video shop or at a friend’s house)

I want to see what my friends have been watching or queueing up, to give me ideas.

From this, we decided we’d need 4 main elements:

A list of films, whether search results or those films in your queue.
A detail view of a film.
Navigation menu with search field
The ‘feed’, much like the current Goodfilms home page.

Of these, the Feed presented the most variety of options, and the most challenges.

The Feed

As the main page in the desktop site, the Feed lets you follow which movies your friends are watching or plan to watch, and we wanted to maintain that as our users log in from their phone. This is what the feed looks like now:

We love that the posters are the dominant visual element, and we wanted to carry that over to the mobile site. Layouts like Facebook work well for irregular information and conversations, but not necessarily posters.

Instagram, on the other hand, because each activity is based around a square image, devotes an entire screen to each update, placing the image right in the middle.

We adopted a one-activity-on-screen approach, but because movie posters are taller than they are wide, we went with a sideways swipe to see the next film:

The Platform

The site is built with AngularJS, which saved us an incredible amount of time. It allows us to express our interactive components very naturally. We’ll be blogging in more detail about the build, but we thought we’d show a quick example of how that works.

The corresponding HTML:

The clear mapping between interactive elements and the subsection of the HTML that it applies to makes it far easier to decompose an interactive application into managable parts.

Goodfilms

New Feature: Get Notified When Friends Rate & Queue Films Based on Your Activity

2012-07-20T14:00:00+10:00

Here at Goodfilms, we’ve always believed a couple of things about films ratings. The first, the obvious one, is that ordinary rating scales are broken. The second, which is just as big an influence on us, but that we write about less often, is that how you hear about a film (and from whom) matters a lot.

We’ve been recording the way people interact with films after their friends for a little while now, and it’s been amazing to watch. We can draw little “family trees” of who originally reviewed a film, then which of their friends rated it next, and then which of their friends rate it. It’s like watching our own little zombie outbreak inside the computers. Once we’ve collated a bit more data, we’ll write a blog post about some of the interesting ways different films move through social groups.

In the mean time, we thought we’d set something up so you can know when you’re influencing your friends’ behaivour on the site with a set of emails that look a bit like this:

These emails trigger when anyone directly interacts with one of your ratings, or films in your queue. We’ve set it up with some time blocking code, so don’t worry about getting spammed with heaps of these emails if a friend goes and rates 100 films straight from your activity page. We’ve had these emails set up for us on the team and our friends for a while now, and it’s a lot of fun knowing who is doing things on the site directly because of your activity.

We’ll be turning these on gradually for everyone in small blocks over the next few days. In conjunction with these new emails, we’ve put together a more detailed user settings page which will allow you to opt out of emails with more granularity. You’ll find it under the “Me” menu when you’re logged in, and the email bit will look a bit like this:

We hope you all have as much fun with these emails as we’ve been having. What would you guys think if we put together a leaderboard of who was most influential amongst your group of friends? Good idea, or would you all get too competitive?

Netflix Quietly Smothers 3rd Party App Ecosystem (updated)

2012-06-18T12:00:00+10:00

Update: We’ve received word that the new API Terms of Use aren’t as sinister as on first glance. From VentureBeat:

We are not prohibiting sites from showing competing services, however we do not want anyone to use Netflix content such as titles and descriptions to advertise a competing service.

We’re not prohibiting developers from monetizing their applications by selling them directly to consumers. We will not, however, permit resale of our information in a business-to-business fashion.

This definitely goes a long way to remove the uncertainty around the new API Terms. We feel that the inability for users to retrieve their viewing history and ratings remains an issue, but we’re glad to learn that existing, mutually-beneficial uses of the API (such as ours) appear to be still valid.

Update 2: TechCrunch and TheNextWeb have now confirmed this. I wouldn’t be surprised if we see an updated Terms of Use from Netflix in the near future to put the issue beyond doubt. We’ll update here again if that occurs.

On Friday afternoon, Netflix published a blog post announcing a breaking change to their API, and dedicated a small paragraph to the fact that their API terms of use had been updated. On a technical level, these changes will cripple many apps currently integrating with Netflix, but the legal changes may be even more significant. Netflix customers should be aware of not only the upcoming changes to any 3rd party apps they might use, but what this says about Netflix as a business.

You can find the announcement on their developer blog. What they are announcing is that from September 15th you will no longer be able to export your viewing history and associated ratings through their API. All API endpoints that expose rental history, and other parts of the API that tangentially supply that information will be removed. All they’ve said regarding motivation for that change is that they are changing their API so that it “is aligned with our broader objectives”. It appears Netflix considers what films you’ve watched and what you thought of them as their data, not yours.

More significant are the changes to the API terms of use, softly mentioned in the post as: “The Terms of Use has been updated […]. To view the revised Terms of Use, go to http://developer.netflix.com/page/Api_terms_of_use.” Checking the latest version against the google cache, we noticed several significant additions under section 1.9

Under the new terms, the following are no longer allowed (Update: Netflix clarification indicates that these are not targeting consumer-facing applications - see update at top of post):

distribute Content to any third party other than directly to end users through your own Application;
charge, directly or indirectly, any fee (including any unique, specific, or premium charges) for access to the Content or your integration of the APIs in your Application, or use the APIs to build an enterprise application (e.g., that you distribute to other companies);
use or display Titles in an Application for search and discovery of content linking to competing services;
use or display Title Metadata in an Application unless it is used solely to facilitate or enable the search and discovery of Netflix services. For example, if your Application enables users to search for the availability of a movie or TV show from Netflix as well as from other services, you may only display Title Metadata in association with the availability of the movie or TV show from Netflix, not the other services;

The first implication of these additions: if you decide you just want to create a “Netflix” app, and add significant value on top of the Netflix service, you cannot charge your users for that value. You can do something positive for Netflix, but not for yourself. There is no incentive for you to build something useful for Netflix customers, and if you’ve already built your app, you have three months left.

The second implication of these additions: if you want to play with Netflix, you must close your eyes and pretend that no other online streaming services exist, or might have films your users want to see. We know that a lot of our users are Netflix customers, but we also understand that they don’t only use Netflix. So we integrated with Netflix to help people find the best films to watch in whichever way best suits them. We think that’s of mutual benefit to Netflix and our users.

This looks to us like a play to keep users from moving their viewing history onto competing services, and to stop their users from seeing gaps in their content library that may be available for purchase elsewhere. While this might be in their short term interest, in the longer term, making it harder for people who want to spend money watching films legally online cannot be a good business decision.

In an industry as fragmented and combative as online streaming, the consumer’s experience is, sadly, often the first to be compromised. Please let us know your thoughts in the comments.

Iphone Sneak Peek

2012-06-07T16:12:00+10:00

We’ve put together a short video with a sneak peek of how the iPhone-optimised site is shaping up. We’re really excited about the different possibilities a touchscreen gives us.

We love feedback, so please tell us what you think in the comments.

And of course, if you’re not signed up already, do so now:

May Roundup

2012-06-04T16:12:00+10:00

Wow, what an exciting month May was. Heaps of new users and plenty of activity on the site, and a lot of new features to talk about. Here’s a bit of a summary:

Netflix integration

You can connect your Netflix account to Goodfilms now:

Now, your Goodfilms and Netflix queues will stay in sync (for films available on Netflix Instant). There’s also:

A list of all the movies to watch on Netflix, sorted by popularity.
The films in your queue that are on Netflix

We hope that helps you get more out of your Netflix subscription each month. It certainly has done for us!

Mobile site

We’ve been working hard on a mobile-accessible version of the site, so you can rate a film as soon as you walk out of a cinema, or access your queue from the couch or in the video store. It’s been really fun to experiment with different designs that work on a touchscreen. Here’s a sneak preview:

Expect more on this in the coming weeks.

A great review on AppStorm

We were lucky enough to get featured on Web.Appstorm that goes into an impressive amount of detail about our rating system and how the site works, and we’re extremely humbled by the 10/10 score we were given.

We were also interviewed by the Appstorm guys a little earlier, so if you’d like to read about how two guys from Melbourne, Australia are trying to change the way films are rated and shared, you can read the full interview here.

International users

Buoyed by coverage by wwhat’s new, Tecno Bita and Café Colao in Spain and Lifehacker Japan last month, we’ve seen a huge influx in non-English-speaking users.

It’s been great to see so many users from around the world, and it’s made us realise how important it is to translate Goodfilms into different languages. We’re also planning to support localised movie posters and titles. Unfortunately we can’t promise that this will be live soon, but we want everyone to know we’re working on it!

That’s it for the wrap-up this month. Expect many new exciting things in the months to come. And, of course, if you haven’t already, sign up for Goodfilms now:

Netflix vs iTunes for Movies You’d Actually Watch

2012-05-16T09:49:00+10:00

We only recently started using Netflix to stream movies here at Goodfilms HQ, and we were surprised just how hard it is to find something decent to watch. When you do find one, the experience is excellent, but the number of movies that don’t interest me got me thinking - how much of their library is stuff I’d want to watch?

Goodfilms already integrates with iTunes to tell you what’s available for streaming, and at what price, so we thought we’d do a bit of a head to head. For those of you not familiar with our rating system, we have two axes: Quality and Rewatchability. A classic film (e.g. The Godfather) rates highly in both so will be up in the top-right, something fun but not particularly clever (e.g. Zoolander) will be up around the top, and something well-made but harrowing (e.g. Black Swan) will tend to be along the right hand side.

Click through to the graph at goodfil.ms/graph to explore.

Here you see the average ratings of the most popular films on Goodfilms (~1150 films at the time of writing), and you can filter down by whether they’re available on iTunes or Netflix. Click on the posters for links to start streaming them. Note: we’re only looking at the Netflix library in the US for now, but the data for iTunes should be for your region’s store.

The numbers

At the time of writing, Netflix has around 9300 films currently available for streaming in the US, but less than 150 of them appear on the graph. What that means is, for films that are popular on Goodfilms, there’s only a 12% chance they’re available on Netflix Instant. Or, to put in another way, people are watching only 1.5% of the films on Netflix Instant.

Contrast that to iTunes, which in the US has 730 films in the popular set - almost two-thirds! That gives it 5 times more films that most people are watching. According to our data, it has a similarly-sized total film count to Netflix, weighing in at over 11000. Flipping the calculation as we did previously, our users are watching just over 6% of iTunes’ offering. Still lower than we were expecting, but significantly higher than Netflix.

Caveats

We want to be clear that we’re not calling Netflix or iTunes out for the quality of their offerings. They have entirely different business models and constraints to consider. We just wanted to present some data to show the massive gulf in what’s available between the biggest transactional and subscription video-on-demand offerings right now.

As the Goodfilms dataset grows, there’ll be more activity in the ‘long tail’ of content, so these percentages will increase. And we’ll be keeping on top of new films being released by each service, as well as integrating more services like Hulu Plus and Amazon in the future. You can always get an up-to-date view on the situation at goodfil.ms/explore.

Choose something to watch

The point of all this is to find something decent to watch, of course, so we built a couple of things to help. To get a full list of the films on Netflix, ranked by popularity, go to goodfil.ms/films/on_netflix. For the same on iTunes, hit goodfil.ms/films/on_itunes.

If you’re a Goodfilms user already, you can filter what’s in your queue by Netflix (goodfil.ms/queue/netflix) or iTunes (goodfil.ms/queue/itunes).

We hope this helps you avoid the duds and find films you’ll enjoy.

Project InGen

2012-04-20T16:12:00+10:00

Here at Goodfilms, we’re all about doing interesting things with film ratings data. We’ve developed a new way of rating movies that lets you express your opinions in a much more meaningful way, and we’d like to introduce how we’re using it.

We’re calling this project InGen after the corporation from Jurassic Park (one of our favourite films here at Goodfilm HQ). We admire the innovation and ambition of InGen from the film, and think that as long as we don’t breed velociraptors, we’ll be ok.

Ranking your friends

The first project to come out of InGen is about putting you and your friends’ tastes head-to-head, to see how similar you are. And, by extension, figuring out who is the most and least similar to you, so you know who to go to the cinemas with, and who to make fun of.

Comparing films

Because all of the ratings on Goodfilms are based on two separate criteria (quality and rewatchability), we can plot them on a graph (see goodfil.ms/graph).

We realised that placing the films on a graph makes it really clear where two films sit in relation to each other, so we decided to classify every pair of films in one of 9 ways, which we call a Vector Victor (again, after one of our favourite films ). For example, Goodfilms users think the film Anchorman is more rewatchable but of lower quality than something like Black Swan. These are the 9 possible Vector Victors (hover for an example):

More rewatchable but lesser quality.	Same quality but more rewatchable.	Better in both respects.
Same rewatchability, lower quality.	Same in both dimensions.	Higher quality but same rewatchability.
Worse in both dimensions.	Same quality but less rewatchable.	Higher quality but less rewatchable.

This gives us quite a meaningful comparison of two films, but when we apply it to an individual’s ratings, it gets even more interesting.

Judging your friends

We realised that we have a nice way of comparing you and your friends:

For a pair of films, do you agree on their Vector Victor?

If you think that Black Swan is not higher quality than Anchorman, you and I don’t agree. And if you would enjoy rewatching a film about a ballet dancer’s descent into psychosis more than a light-hearted Will Ferrell movie, we’re not going to have a fun movie night.

What’s neat about this approach is that it the exact ratings don’t have to match for us to agree. Which works quite nicely because it doesn’t matter how harshly you or your friend rate films, as long as you agree on their relativity.

Also, since both quality and rewatchability are being considered, you are making quite a precise statement about how two films compare. The nine possible Vector Victors all represent something fairly specific, so the fact that you and a friend agree is quite meaningful.

The Result

This lists your friends in order of how close you align. The numbers on the right represent how many films you’ve both rated, and, more interestingly, how many films are in both your queues. Click on this and you have a great way to pick a film to watch with someone:

We hope you all find out something interesting about your friends with this. If you’re already a user, hop on over to goodfil.ms/people/friends and check it out. If not, head straight to goodfil.ms and sign up!

Footnotes

This is a work in progress. Things will change as we refine it.
This is not the only signal we are using to compare you and your friends, but it’s the most significant and the most original.
Two ratings (in either dimension) don’t need to be identical for us to consider them ‘the same’. We use a continuous rating system, so we account for a little noise in people’s ratings by using a certain tolerance in our calculations. At the moment, that tolerance is roughly a half-star or half-smiley wide.
We’d like to thank FlickChart for showing how informative it can be to directly compare two films.
Evan Miller’s blog post and the resulting Hacker News discussion also deserve thanks for helping to explain and recommend the Wilson interval for ranking algorithms like ours.
We love feedback. Comment here, post something on our feedback forum, or hit us on Twitter or Facebook.

Press Release - Goodfilms Raises Seed Funding

2012-02-27T15:32:00+11:00

Social movie reviews startup Goodfilms raises $150K. [PDF]

For any enquiries, please contact us on marketing@goodfil.ms

AngelCube: 4 Weeks In

2011-10-18T15:36:00+11:00

A little over six weeks ago, I found out that Goodfilms had been selected as one of the first round of startups to be selected for the AngelCube seed accelerator. Now, one-third of the way through the program I thought I’d take some time and reflect on a major lesson I’ve learned so far, and where Goodfilms is now.

We’ve had a variety of mentors sessions covering a range of topics, but I thought I’d focus on one of the common themes - that you should be measuring everything.

Measure Everything

When I started work at Envato last year, I couldn’t believe how easily and freely they deployed code to production. At the time we were serving over a quarter of a million users, tens of millions of pageviews a week, and yet we would usually push code several times a day. It was a little daunting at first, but everybody in the team understood the implications - if you wrote code that broke, ran slowly or disrupted someone’s workflow, it was on you. Nobody held your hand, everybody stepped up.

It took some getting used to, but suddenly everything made sense - the only real way to know if your code performed well enough, if the feature was useful, and that nothing fell over was to get the code into production [1]. But that relies on you and your team paying constant attention to performance, feedback and uptime. In other words, if you don’t measure your application well enough, you’ll never know when you’re doing badly.

From the mentoring sessions we’ve had as part of the AngelCube program, a similar principle has emerged - if you don’t know precisely how you’re doing, you won’t know when you’ve improved or regressed.

From online marketing sessions to working on our lean canvas to discussing how to convey traction in a slide deck, the principles of measuring, testing and verifying have been paramount. I’m a developer at heart, so my natural tendency is to build whatever’s cool, but the wider implications must be understood, and that means being able to measure the business or customer need. It’s the biggest departure from my comfort zone since moving from developing for a handful of users to hundreds of thousands.

[1] This topic is far more complex than this, so please excuse this oversimplification.

Measure What?

If I tried to distill the lesson behind the advice we’ve received so far, it is this - understand every way people get on to your site, and what they do once they’re there. ‘Conversion’ is the general term, I suppose, but I prefer to work in specifics: Measure the proportion of people interested enough to click an ad, the proportion of those who sign up, the proportion of people reading this blog (i.e. you!) and how many of those sign up for an account. Find out how many people don’t bother using their invitations. Find out how likely someone is to never rate a film, to rate 10 films, to rate 100 films. How many people invite friends? How many people leave feedback?

By measuring this we can determine whether our landing page is convincing, whether our blog content is interesting and whether the you’ve-been-invited email is confusing. We can deduce if people find Goodfilms useful without having any friends on the site yet, or if the first thing they want to do is get their friends on board. The better we can understand this, the better product we can build.

Looking forward

Measurement doesn’t happen for free, and like monitoring your code in production, adding each piece to the puzzle requires time and care, and that’s where Goodfilms is now. We’re working through what gives us a manageable amount of information, in the most straightforward way. And it needs to be as automatic as possible - any time spent collating measurements is time that can’t be spent on other things.

But it represents the clear value of participating in a seed accelerator like AngelCube - access to a range of mentors with differing experience and advise, but some common themes. Even after 4 weeks we’re seeing meaningful improvements to the quality of the Goodfilms website and strength of the business behind it, and we’re all looking forward to the next 2 months.

A Better Way to Rate Films

2011-10-07T10:11:00+11:00

Whereby I try to convince you that all other ratings systems are the lose, and Goodfilms’ is the win. Let’s begin.

First, an observation

Your favourite films probably didn’t win Best Picture.

In fact, I wonder how many Best Pictures you would happily watch over and over again? Critical acclaim doesn’t guarantee that you’ll love a film, and a film doesn’t have to be objectively brilliant for you to list it among your favourites.

Moreover, some films that were shocking or groundbreaking for their time might not seem that remarkabe now, and some that were panned when they were released may achieve popularity and recognition much later.

The point is this - your enjoyment of a film is different to its critical reception. There’s something else at work, and this post is about determining what that is.

5-star ratings systems don’t work

A few years ago, YouTube blogged about the ineffectiveness of their 5-star ratings system, referring to this graph:

The number of 5-star ratings greatly outnumbered all others, with 1-star a distant second. They decided to switch to a thumbs-up/thumbs-down system, which by all reports is working well. Amazon also uses a 5-star system and similarly skewed ratings are often seen. In fact, they now define 4+ stars as ‘favorable’ and 1-3 stars as ‘critical’. The reviews of Transformers 2 are a particularly good example:

For films, a yes/no ratings system, like that employed by Rotten Tomatoes, may be the best way to derive a single, aggregate score. But it relies on a huge number of anonymous ratings, and collects the least possible amount of information from each person.

I think this is a step in the wrong direction.

When considering your immediate friends, you want to know the detail and variety of their opinions. There’s a difference between your friend liking a movie and loving it, between not really caring for a film and actively warning you off it. Goodfilms focuses on these opinions, and so an aggregate score isn’t good enough. Mind you, that doesn’t mean we’re happy with the usual 5-star rating system. Oh my word no.

Continuous ratings

There’s another problem with the traditional star system - quantization. Considering the following graph of a staggering 10 million movie ratings from the Movie Lens project:

There’s a clear bias toward integer ratings here - only 20% of all ratings are half-stars. And there’s no clear reason why that should be the case - clearly the majority of ratings are 3 and 4 stars, why are there so few 3.5 star ratings?

There’s a great blog post by the guys at Steepster, talking about how their ratings system developed over time, settling on the following design:

Goodfilms adopts a similar approach, and it completely avoids the integer-bias observed in the MovieLens dataset:

A continuous scale might be an improvement, but we haven’t addressed the key problem - there’s more to rating films than objective quality. But what is it?

Going beyond ‘quality’

We’ve come up with a concept that we think captures this neatly: rewatchability.

Yes, I’ll admit that that’s not a real word. But it’s a good short-hand for the question we ask when you rate a film on Goodfilms:

If you were to watch it again, how much would you enjoy it?

Now, when grappling with what score to give a film like Transformers 2, you don’t have to decide between ‘Transformers Rock!’ and ‘I wish I could have transformed into a gun to shoot myself’, like the Amazon example above. Now you can freely admit that it’s a long, loud, confusing mess of a film and you like it anyway:

On the other end of the scale, I think Black Swan is a terrific film, but I’d sooner pull my nails out than watch it again.

Rewatchability turns out to be an excellent indicator of what films you’d recommend. What better recommendation than a movie you’d happily watch again and again? And would you really suggest a film to a friend if you yourself wouldn’t enjoy a repeat viewing?

We think this is a much better way to rate films, and from the first chunk of data we’re starting to see some fascinating results. Here’s a sneak peak at what we’ve got so far, displaying ‘quality’ along the x-axis and ‘rewatchability’ along the y:

As you can see, both axes have their outliers, and overall there’s a correlation between quality and rewatchability, which you’d expect. Some films are showing themselves to be deeply contradictory, with others showing a surprising consensus. And there’s a tendency toward rating higher-quality films in general, but rewatchability is more evenly distributed.

There’ll be much more detailed posts in the future, but for now - that’s our ratings system, and how we came to it. We think it’s the total win, and we hope you’ll agree. So sign up if you haven’t already, and get rating!

-glen.

Why Goodfilms?

2011-09-30T12:51:00+10:00

You may be asking yourself, why does Goodfilms exist? Aren’t there plenty of sites about movies already? Do we really need another one?

Well yes, there are quite a few already. But they’re all, at least a little bit, balls.

The problem

How do I choose something I’ll enjoy?

We’re already have ways of choosing what to watch. You might have a few critics or blogs who you find you have an affinity with, and you watch whatever they recommend. You might trust an aggregate score, believing that what works for most people will work for you. Or, you might watch trailers and base your decision on the number of explosions or how dramatic the voiceover guy is.

And that might be working well for you already. Or you could be regularly watching duds. Either way, I think Goodfilms can do better.

A laughable claim, Mr Bond.

I wonder if you’ve ever heard one of your friends say something like:

Wait, you’ve never seen The Usual Suspects? You have to. As in, take the afternoon off and watch it.

Don’t ever watch the Matrix sequels. In fact, they don’t even exist.

Transformers 3 was, without a doubt, the worst example of filmmaking I’ve ever witnessed. But, it’s got giant robots punching each other, so… you’d probably like it.

Yes? No? Well, maybe you have different friends to me. But that’s ok. In fact, that leads neatly into my point:

Want to know what you’ll like? Ask your friends.

And that’s why Goodfilms exists:

Goodfilms puts your friends’ opinions ahead of those of strangers. It lets you record which films were compelling and which were forgettable, lets you separate the inexplicably enjoyable from the intellectually insulting. And the result?

A better way to discover and remember films you’ll enjoy.

So sign up!

-glen.

My diary, by Arnold J. Rimmer

2011-09-29T18:14:00+10:00

There’s something about writing the first post on a new blog that brings to mind this bit from Red Dwarf ( I suppose I could have looked for a film reference rather than a TV one, but *shrug*). So, in order to not sound like a tool - I’ll simply say that this is where I’ll be explaining how Goodfilms is put together, and why.

Anyway, why don’t we skip over the ‘first post’ nerves and get right to it, hey?

Excellent.

-glen.