For most of 2014 I worked with a small team¹ on Sup, an iPhone and Android application that let users explore the world through live video. Users could sup their friends, and recipients could accept those requests to open a one-way live video stream. The user watching, the subscriber could send instructions to the user filming, the publisher², such as “go forward”, “turn left”, “dance”, or “act sleepy”. Afterward, the publisher could choose to share an automatically-edited version of the videos.

The app was inspired directly by, and felt remarkably like, the 1999 movie Being John Malkovich³, in which a puppeteer and other characters take advantage of a mysterious portal to experience and control the life of actor John Malkovich. (Somehow there is not a single decent copy of this trailer on the Internet.)

Sup offered a novel communication experience and was a lot of fun. Because sups were initiated by the subscriber and not the publisher, users would receive and accept sups when they were doing everyday things like playing video games, walking home, or eating sandwiches with their coworkers. Sup offered users a glimpse into their friends’ lives that they would not otherwise have gotten; the content was interesting not because it was perfect, but because it was personal and authentic.

Most of my work was on the iPhone app, and I’ve documented the functionality of the different versions of the product below. The app was featured by Apple, and had a 4.5-star rating with 53 reviews. In addition to articles published on TechCrunch⁴, Mashable, and Business Insider, our CEO was invited to talk about Sup on CNN:

Sup 1.x — Launch Early and Iterate

We knew it was difficult for any video streaming app to get two specific users into the product and connected to each other at the same time. In many ways, the problems are similar to those of a phone call: if the callee doesn’t pick up, the caller has a bad experience.

To solve this, Sup used a flow in which the subscriber would, by sending a sup, essentially be saying “call me in the next five⁵ minutes”, at which point the publisher would accept, and then that would trigger a ring sequence on the subscriber’s device. It was like a phone call in reverse, and it felt like an improvement over the more traditional user flow.

We released the first version of Sup to the App Store on June 26th, and we eschewed non-essential features in order to test this synchronization solution as soon as possible. We iterated quickly, and as soon as a version of the app received approval from Apple, we submitted a new version for review. These short cycles added missing features such as contact search, profile photos, and a selfie mode that used the front-facing camera. Before long, Sup worked roughly like this:

Users gave feedback that they wanted some sense of whether the potential publisher was available for a sup, and they also wanted a way to tell other users to sup them. We integrated these needs and added a simple emoji status feature — users could select three emoji that would appear next to their name in the contact list. These statuses would trigger push notifications to the user’s friends, and they would disappear on their own after 90 minutes. If one thought of the sup itself as a movie, then perhaps the emoji status was the trailer for that movie.

Sup 2.0 — A Game-Like Social Product

While the sup experience itself was a lot of fun, we wanted to create a more compelling “single player mode” in case none of a user’s friends were available when she happened to open the app. In mid September, we brainstormed as a team and ultimately settled on a feature we called recaps: short, automatically edited video summaries of sups. Recaps would capture some sort of content exhaust from the best parts of Sup and re-use it as entertainment for others. Users would be able to view and like these looping recap videos in a standard feed, and optionally share them to other networks. When a user liked a recap, it would send a push notification to both the publisher and subscriber who had made it, and that would often prompt users to do even more sups; this closed an engagement loop that we had left open in Sup 1.x.

We prototyped the feature and found the recaps to be engaging, so we built the necessary components, made a handful of other UX improvements, switched to a brighter orange, and released Sup 2.0 on November 11th. The below video shows how the various features came together into a complete product, and our users shared many great sups.

Some of the improvements about which we were most excited were in the interface for the sup itself. We had always been cognizant of the video-game-like nature of the sup, since the subscriber directed the publisher as a sort of real-world avatar, but we had struggled to manifest this in the product. The on-screen D-pad in the video above was a breakthrough for us — it was not only more intuitive than the overly-clever swipe interface Sup had before, but it also highlighted the game-like nature of Sup as a communication medium. The fundamental asymmetry of the subscriber sending instructions and the publisher sharing video lent itself to a turn-based playfulness that made Sup feel fun and fresh.

Technical Notes

Sup was a native iPhone app that consisted of over 20k lines of Objective-C⁶, as well as a number of third-party libraries and frameworks. The most integral of those was the OpenTok WebRTC platform from TokBox, which powered Sup’s live video streaming.

We used storyboards and Auto Layout to arrange our interface elements. While it was a moderate headache when the time came to split the app into multiple storyboards, and while we never found a good way to write modular storyboards, Auto Layout still made it easy to handle the variety of device sizes and decreased the amount of code we had to maintain. Our designer used a wonderful product called PaintCode to generate styles and image methods that we could import directly into the project, and we used Heap for client-side analytics.

While instructions between clients during the video session (such as “act sleepy”) could be sent directly as signals in the OpenTok session, we needed our own server for session management, account management, and APNS notifications. The API used Node.js with Express running on Heroku and a Mongo database hosted by Compose, and the clients coordinated with them to guide the publisher and subscriber through the various pending->connecting->streaming->ending states. We used Codeship for continuous deployment, Papertrail for log archiving, and New Relic for performance debugging.

Our Android engineer wrote his own technical overview in three detailed parts, and at some point I hope to write something similar about our iOS-specific challenges and solutions.

---