This week, the Vox Product team released a brand new video browser on Polygon. Response has been positive thus far, and I reached out to some of our Polygon team members to learn a bit more about the effort and process from design to development to testing for this great new feature. I asked developer Jake Lear, support manager Cory Williams, and designer Tyson Whiting a few questions, and their responses give a great insight into working on Vox Product.
What was the overall process from getting the video browser from thought to on the site?
Jake Lear: For Polygon in 2013, one of the things that the editorial team wants to focus on is highlighting the incredible content that our video team puts out. Polygon is rapidly ramping up video reviews, as well as video series such as “Today I Played” — getting these videos in front of more users is top priority.
The product team took that requirement (among others) and began thinking about solutions. Eventually, we will build a full scale video hub for Polygon as a place users can look to find all of the amazing video content, but as a short term solution, we came up with the idea of a compact video browser that could feature many videos in a low-impact way on the homepage.
After we established that idea, we cut Tyson loose on what would be his first major feature as a Polygon designer. Over the course of a few days, he developed a visual design with feedback from creative director Ted Irvine and designer Warren Schultheis. After a few rounds of feedback from the editorial team, we reached a design that everyone was happy with and started the development.
Tyson Whiting: The team and I spent a lot of time really thinking about the functionality; The functionality ultimately ended up driving design. We talked a lot about what makes a good video player, what makes a bad one, and what makes a confusing one. We wanted something that was easy to navigate and simple. “Here watch a sweet video” … ‘nuff said. I did sketches ‘til my fingers were bloody and eventually convinced myself I had an idea that met the criteria and could potentially look really badass.
Then we moved onto actually getting Polygon’s content in there and started moving things around. Things would start to look pretty good, and then I would show Jake, DZ [David Zhou] or Warren a mock or two and they would tell me I’m crazy. I would tweak a few things and share mocks again. There were a lot of rounds of making sure the functionality was fluid, or that it met the look and feel of Polygon’s brand. From a design standpoint I wanted to really make something that was special to Polygon. I utilized that corner notch and color overlays to make a video player that you’ll never find anywhere else. It was a blast to work on, and people really seem to enjoy it.
How did you ensure that the design was reproduced on the site as closely as possible and were there any major obstacles to that goal?
JL: We have a fairly robust visual library on Polygon that allows us to quickly develop new features without worrying too much about betraying the soul of the site’s visual design. Tyson, Ted, and Warren worked tirelessly to ensure that the visual design fit successfully into the Polygon aesthetic, and we wanted to give that effort the respect it deserved in the development of the feature.
Tyson and I worked closely together during development, reproducing the design as closely as possible. During the design phase, Tyson had not fully explored how the video browser would respond at smaller browser sizes, such as tablets and mobile, so together we fleshed out ideas in markup and CSS to make the feature fully responsive.
What is the most interesting part of the video browser from a design standpoint? A technical standpoint?
Cory Williams: I think that creating a brand new addition to the front page of your site is a rare opportunity. Tyson and the design team were able to create a look that fit naturally into the Polygon front page, while standing out as a fresh new piece of the Poly puzzle.
From a technical standpoint, we had to figure out the best way to curate the content that feeds into the browser, which came with its own challenges. Fortunately, we were able to overcome the issues and deliver a quality product.
JL: Shortly before the Polygon team launched the video browser, The Verge team implemented the concept of video channels into our modern media stack, Chorus. It turned out to be the perfect tool for driving Polygon’s video browser.
This collaboration is a perfect example of the benefits of having a custom media stack driving our networks. The product team is broken up into small vertical-specific teams, but there are often times like this where one team can leverage the efforts and features that another is building. Additionally, developer and drink enthusiast Dusty Matthews had, just weeks before, completely overhauled the video pipeline within Chorus, allowing us to much more easily implement quick loading of all the videos without needing to have dozens of flash (or HTML5) players on the page at one time.
TW: I think one of the coolest parts of the design is that it acts as one cohesive unit. There aren’t really a lot of players out there that play this well with their video library. The relationship between the video that is playing and other video to watch on the left is a good balance, which looks great. Also the responsiveness of the player is awesome.
What was the testing process like for this project?
CW: I grabbed every device available to me and set down to work on a sandbox environment of Polygon. After populating the video browser with content, I began by playing with it in Chrome on my MacBook. You check to make sure videos play without crashing, that clicking another video seamlessly works, that hover states are consistent, and that the carousel arrows work.
After that, I tried other browsers, including Safari and Firefox, all the while logging weird bugs in FogBugz for Jake to fix. From there, it’s onto a Windows 7 PC, where Internet Explorer awaits, like Shredder at the end of the original Teenage Mutant Ninja Turtles arcade game.
Of course, you also want to ensure that tablet experience is up to scratch - that’s why a Nexus 7 and an iPad are you best friends for testing. Fortunately, David and Jake did a great job of developing the browser so there were not too many bugs to iron out.
In the end, the final result turned out great! Check out the final version on the front page of Polygon.
We’re building great things, and we need your talent! Check out jobs.voxmedia.com for our current job listings.
Scott Kellum, Designer Name: Mr. Pickles What kind of animal is this?!: Cat?! Age: 4 Location: Brooklyn, NY Fake Job Title: Seat warmer (he is passionate about his job, if you get up he will take your seat) Favorite Memory: At the adoption show he was under the table refusing to leave his carrier. When we got him home and he finally left his carrier he purred continuously for hours and wouldn’t let us stop petting him.
Constance Watkins, Designer Name: Sir Tiberius Rex of Birdington, aka Rex What kind of animal is this?!: Bird! (Cockatiel) Age: 3 Location: New York, NY Fake Job Title: CFO (Chief Feather Officer) Favorite Memory: Moving Rex to Manhattan was an adventure. At one point during the trip I was on the subway with him and had someone ask me, “But what does he do?! What does he eat?!” Answer: Bird stuff, and bird food (respectively).
Guillermo Esteves, Developer Name: George What kind of animal is this?!: Cat (Felis Catus) Age: 14 Location: Washington, DC Fake Job Title: Curmudgeon in Chief Favorite Memory: He runs into things while chasing the red laser dot. It is quite amusing.
Jesse Young, Developer Name: Hanna What kind of animal is this?!: Cat Age: 8 Location: San Diego, CA Fake Job Title: CFO (Chief Fluffy Officer) Favorite Memory: Exposing her belly and purring is her natural state.
Jake Lear, Developer Name: Gracie Breed: English Springer Spaniel Age: 13 Location: Paris, VA Job Title: Vice President of Snuggle Division Favorite Memory: All of them
Names: Samson and Delilah Breed: Great(est) Danes Age: 3 Location: Paris, VA Job Title: Security Detail Favorite Memory: When they were smaller than Gracie
Joe Grossberg, Developer Names: Miju and Peeps Breeds: Domestic longhair, domestic shorthair Ages: 13, 14 Job Title:Existential philosophers Location: Boston, MA (but Washingtonians at heart) Memory: How they helped me win over my wife; nice assist, guys.
Ted Irvine, Director of Design Name: Noche! Breed: Boston Terrier Age: 7 years old Job Title: Company therapist Location: Arlington, VA Favorite memory: Best dog to have a hangover with
Not too long ago, the product team at Vox Media was a single, small group of folks collaboratively doing all the things. Today our situation is much different. In the last year alone the product team has grown by nearly 200%, and even 18 months ago both The Verge and Polygon were just twinkles in our eyes. Since then, we’ve launched both sites successfully, and gone through a major redesign and rebrand of SB Nation and its 311 communities. We’ve had to quickly adjust and scale our operation in order to meet the demands of a growing company with many concurrent projects across many teams.
Today we find ourselves nearly 40 people deep, including developers, designers, operations engineers, support, product management, and interns. Those 40 people (and growing) are broken up into six cross-functional teams: one for each of our core brands — SB Nation (which itself is broken up into over 300 individual brands), The Verge, and Polygon — along with a platform team to focus on Chorus (our modern media stack), a (technical) operations team, and an advertising products team. Each one of these teams has resources dedicated to help them achieve their goals, keep the sites running smoothly, and innovate with new features.
Even though we’re organized as separate teams, each is deeply collaborative with one another. Not only is it in our DNA to be this way, it’s an essential requirement as we all share the same platform, and things developed on one of our brands is often rolled out to others as they become available.
To keep things running smoothly in this type of environment, using the right tools is important. Over the years we have tried a number of them: FogBugz, Trello, Agile Zen, Sprintly, Scrummage, BugWire (our first Rails project ever, circa 2004), Google Docs, and likely many others lost from recent memory.
How we came about using (and creating) the tools we settled on and use today has been an organic process; over the last several years we have spent time evaluating and discarding various softwares, taking note of things we like and dislike from each. In the end we found ourselves using a combination of both Trello and FogBugz, along with Beacon — a custom tool we created to organize our sprints, bug queue and production deploys.
Trello for product management
Trello is where ideas begin and grow. Often the best ideas are imagined and brainstormed while not in front of project management software — a conversation might happen while passing someone in the hall, or during a happy hour, over instant message or email. Trello makes it easy to get those ideas into a backlog and keep them organized and prioritized without much effort.
Further, ideas are rarely fully fleshed out at inception — they take time to incubate and grow to become the polished features they are when they hit production. Trello is where those ideas are built upon collaboratively, with stakeholders of all kinds adding to the requirements, brainstorming concepts, attaching wireframes, and helping to bring the idea to fruition.
Most importantly, Trello is easy to use and understand. It’s not a complex bug tracker or sprint planner. It’s interface is logical and simple to modify.
Our structure is pretty simple: we have a product-related Trello board for each one of our teams. Trello is fluid enough to let each team use their own lane structure and workflow for requirements gathering and prioritization. In a world with wildly different editorial teams, forcing everyone to use the same rigid structure for product management would be difficult. Trello let’s us organize ourselves in specific ways that are important to each individual team.
We don’t do project management in Trello, however. That is, when something is ready to be worked on by a designer or a developer, our product managers take the cards from Trello and write out user stories and tasks in FogBugz for development.
Fogbugz for project management and bug tracking
FogBugz is where shit gets done.
Why not use Trello to track the project development as well? We switch to FogBugz as it allows us to group user stories and tasks into explicit objects which can be assigned to individuals and milestones. These user stories have tasks that can be given independent status updates and tracked — something Trello doesn’t do with as much granularity or with a fixed workflow. Even though Trello has a variation of many of these features, any project of notable size or complexity can get messy in the lane and card-based system that makes it so easy to use in other cases. Out of all the tools we’ve used over time FogBugz made the most sense for large projects or otherwise intricate sprint work.
FogBugz also makes it easier to organize our particular project methodology. Generally speaking, we begin large projects by writing epic user stories to communicate the big picture, which are then broken up into smaller, discrete chunks of work. Those smaller chunks are further diced into individual tasks and taken up in priority order. While it would be possible to handle this workflow in Trello, our attempts at staging the work there have been messier and harder to organize than FogBugz.
Finally, we use FogBugz to track bugs and handle our incoming support queue — something Trello isn’t really designed to handle. Bugs come in through email and are handled by our support managers, who communicate back to the submitter and eventually file it away into the appropriate queue to be squashed.
As powerful as FogBugz is, it’s not all roses and unicorns. Its biggest negative (and, I suppose, positive) is its complexity. (For example, Fog Creek offers FogBugz training for $250 an hour.) It’s built to manage large, complicated projects (and track bugs!) and it’s not well suited for communicating the status of a project to people who aren’t a part of the product team. In fact, we found FogBugz so unfriendly in that respect that we decided to spend time building a friendly layer above FogBugz that (among other thing) simplifies the interface and gives a stakeholder a big picture view of what all teams are working on without having to dive into the intricacies of FogBugz. Enter Beacon.
Beacon for transparency and organization
Beacon is a custom internal tool (built at VAX ‘13 by our Director of Engineering, Michael Lovitt, and myself) that serves many purposes.
First, it’s integrated with the FogBugz API to provide insight into all past, present, and future sprints across all of our teams at Vox. It lets the stakeholder get a glimpse of what each team is currently working on, what the overall progress of each sprint is, how many tasks remain, and when it will be released into production — all without needing to dive into FogBugz.
Second, it’s a deploy scheduler. Our developers use it to schedule deploys to production, associate deploys with sprints, and otherwise stay organized when there are five teams deploying hundreds of lines of code to the same application every day. (In the future, we very well may use it to actually deploy, but for now that’s done via Capistrano at the command line.)
Finally, it’s bug tracker. All of our support requests for each of our properties (from both external users and internal staff) land in FogBugz, where they’re dealt with by our support managers. If the incoming request is indeed a bug that needs to be fixed, it gets filtered into the appropriate FogBugz milestone, which Beacon is configured to associate with the proper site. So our staff is able to check and make sure bugs they have submitted are either in the queue to be fixed, or that they’ve already been fixed and are either waiting to be deployed or already in production — all without logging into FogBugz.
This is what we use today, but who knows what the future holds. As we continue to grow and refine our processes, it’s likely our tools will evolve as well.
VAX ‘13 wrapped up two weeks ago on a sunny Friday afternoon in Austin, Texas, and our product team presented their proof-of-concept work in front of the entire company.
In a Google Hangout, editorial and sales staff from across the country watched as over a dozen exciting new projects were presented in two hours. Niv Shah and I spent those days following our coworkers around, filming their hard work and developing a documentary chronicling the process.
Now, it’s your turn to see how the projects that the Vox Media product team worked on during VAX turned out. Click play to begin!
We’re building great things, and we need your talent! Check out jobs.voxmedia.com for our current job listings.
Our first ever VAX wrapped up today, and we will recap it early next week (with video!), but for now you should check out some recent photos on our team’s flickr!
Well, that’s enough for today. Off to eat some more brisket on our final night in Texas.
Hello, we are the Vox Media product team. We are designers, developers, operations engineers, and product and community managers, based in Washington, DC, New York, and Austin, and distributed remotely in cities from Santa Barbara, California to Springfield, Missouri.
Scott Kellum, Designer
Constance Watkins, Designer
Guillermo Esteves, Developer
Jesse Young, Developer
Jake Lear, Developer
Names: Samson and Delilah
Joe Grossberg, Developer
Ted Irvine, Director of Design
