The GE Performance Machines interactive experience combines a large library of video recordings of three pro football players with interactivity in the form of 9 mini games putting man against different machines built by GE. ACNE Production created this experience in collaboration with BBDO New York and Dinahmoe and I was the technical and interactive director on the project. The site was made Site of the Day on theFWA.com March 13 2012.
Functional Requirements
The project launched around the Super Bowl and was expected to receive a lot of traffic around the time of the launch. Furthermore it was made very clear to us that the client wasn’t a big fan of loaders on websites. Since we were creating an interactive experience it was very important to find out what exactly that meant. Turns out she didn’t like having to wait a long time to get into the main part of a website, which to us is a perfectly understandable objection – our philosophy on loading is that the site should only load what it needs to get going – many interactive websites tend to load everything up front, even though it isn’t needed right away. I believe this is done because it’s easier from a development perspective than having to deal with dynamic loading later on in the interactive narrative. Well, sites aren’t built for developers, they’re built for users, so we do of course need to figure out a way to make the site feel light and the experience seamless to the user.
We were also asked to figure out how we wanted to deal with users on mobile platforms. It wasn’t a requirement that the experience should work on mobile, but in creating a brand experience it’s of course important to take all platforms into account, since lots of traffic comes from various handheld devices.
Interactive Experiences in the Cloud
These last couple of years have seen a lot of internet infrastructure being moved from dedicated hosting solutions to some kind of cloud hosting and cloud applications. The typical interactive experience has a fairly short life expectancy, but during that time it will receive a lot of traffic, making it a perfect candidate for being hosted in the cloud. This project was no exception. We were dealing with a lot of video files – in fact no less than 197 in three bandwidth versions for a total of 591 videos. The core functionality of the site is switching rapidly between these many different videos, depending on what the gameplay dictates. Furthermore several of the videos have to start playing not from the beginning, but from a specific point, again depending on the gameplay. One way of doing this is to preload all videos for a given game and storing them in memory for when they’re needed it in the game, but that would require us to load all videos up front, resulting in potentially a very long load time. There is also a limit to how much video, we can hold in memory, and that limit is quite low.
Fortunately Amazon Web Services have a very interesting product that we can use for just this kind of experience. Amazon Cloudfront is a Content Delivery Network (CDN), that among other things have Flash Media Server capabilities in it’s portfolio. The idea behind that is to allow content providers to serve video in a more traditional sense, where a user would watch videos in a video player. But it works perfectly for an interactive video experience like ours – It sits in the cloud and scales gracefully to meet our traffic needs, and the Flash Media Server lets us play any video on demand with very low latency. Cloudfront works perfectly with the industry standard for video player Open Source Media Framework (OSMF), which is the technology being the frontend video used in this project.
Creating a Seamless Experience
While the latency is very low, it’s still there – the result is that videos will occasionally take 0.2 to 0.5 seconds to start playing, which is something the human eye notices. To make this less apparent to the user we worked with our sound partner Dinahmoe on letting the music be the element that stitches the videos together. The music is not embedded in the videos but plays out as a separate element in the experience. This means that when the video stops playing for a second, the music is still playing, and that creates a very good illusion of a seamless experience.
The mobile site
One of the things we’re particularly proud of is the mobile site that supports this experience. The desktop site is the main focus of the campaign and that is what most of the effort went into, but we came up with a simple and fast solution for a mobile site that doesn’t feel watered down. As with any interactive experience we have buttons for social sharing on the desktop site that allows users to Like the site on Facebook, Tweet it on Twitter or +1 it on Google Plus. If I go through my social feed on my mobile device and decide to check out the link to the GE Performance Machines site posted by a friend of mine, I will be taken to a site tailored specifically for the mobile platform, but with the same deeplink that my friend shared. The mobile site features videos capturing the interactive action on the desktop features, but without the interactivity. In fact, the user always wins in the mobile version of the interactive features. If I later visit the same link on my desktop computer I will be taken to the full site.
Sprinting through the Waterfall
This project had a very short timeline and was completed in only 6 weeks. To accomplish this we had to work in an iterative process were all stakeholders were involved from the beginning. Traditionally interactive campaigns have taken a waterfall approach where the developers are handed a bunch of completed Photoshop files and assets and then locked into a basement for a month or two to build the experience. While most software development companies have probably buried the waterfall approach years ago, it still makes some sense in advertising, as it allows the creatives to fully visualize and finalize their design and concept before handing it over to the developers. Later when the developers are released from the basement, that design can be used as a very accurate guideline to review the finished product. Unfortunately this approach is very time consuming and expensive, and furthermore it creates a gap between the stakeholders in the project. That’s probably the reason why production and development people hate it.
Modern software development typically uses an iterative approach, SCRUM being one of the most popular and well-known of those. This approach breaks the project up into clearly defined phases with clearly defined roles, responsibilities and goals for each phase. Developers and other production people love this, because they love clearly defined goals. It’s also a lot more efficient and flexibile than the waterfall approach, since the later phases can be re-defined based on the outcomes of the phases before them. But in our experience an approach like this is too demanding on a lot of people, in particular creatives and the client, as it requires a very high level of abstraction to fully understand how the pieces come together in the end. Another thing that makes an approach like this challenging is the fact that we have a shoot very early in the project timeline. Everybody is locked into the result of this shoot, and we can’t be flexible in later phases to make up for the stuff that went wrong during the shoot or the stuff we didn’t think about at the time.
The timeline on this project demanded that we took an iterative approach, or we would have still been working on it now. Development happened alongside design, and as soon as the edits had been selected from the shoot, we started to mock up working prototypes where we could fit all the pieces together using raw edits and experiment with the gameplay. This allowed our creative people to start playing the game very early on, which again allowed them to create and tweak the design elements to support the gameplay perfectly. Furthermore our client could start playing the games very early on, which was a huge benefit to the project, as it allowed us plenty of time to set the gameplay parameters and the game difficulty to a level that everybody liked. As the CGI was added to the videos and the post work was done, we replaced the raw edits with final videos. As the game gauges were designed and rendered, they slowly replaced the green placeholder boxes in the game, and slowly everything came together and started looking like a real game.