Building the Perfect FireTV App
By: Tribalscale Inc.
Tags: OTT, Agile, Amazon Fire Tv, Entertainment And Media, Development

Building the Perfect FireTV App

Part 4 of our OTT series

By Zeinab Bagheri, Kevin Chow, and Jon Holtan

This is the fourth part of our OTT series. The first two blogs focus on the challenges of building on Roku, offer solutions, and introduce the Roku App Kit. The third turns to tvOS, and now, we give the rundown on FireTV.

On Product

FireTV is one of the top competitors in the OTT space. The first device was released in 2014 and since, Amazon has been constantly iterating, adding new features, and releasing new devices. We’ve been working closely with a leading digital streaming service and recently built and released a FireTV app; the app allows users to browse, search, and stream thousands of media content.

To start the project, we engaged in platform discovery. We had a hard time finding clear documentation on how an app should react with the FireTV Operating System (OS)/Amazon. We created our own documentation of dos and don’ts, which was based off live FireTV apps. However, we found that nearly every app is different in terms of guidelines and requirements for app-OS interaction. This was an added challenge that made it difficult to really understand what the final requirements should be for our app.

Fast forward a few weeks later, and we were ready to submit our app… It was rejected. The rejection came as a huge surprise to us and meant we needed to pivot quickly and re-release. But, it wasn’t all bad news and the rejection actually signified a strength: Our app was evaluated against particularly strict acceptance criteria due to the reputation of being a leading developer. In the end, we successfully changed our implementation and the app passed through the criteria.

In sum, when developing for FireTV, keep in mind the following high-level product pointers:

No app works with FireTV OS the same way. Do your research. Consider the sheer volume of FireTV devices on market. Test widely. Stay up to date with all FireTV devices, their technologies, and the OS. Deliver a product that leverages the technology to the fullest.

Designing for FireTV

When designing, always keep your audience in mind, understand them, and make sure you’re designing for their behaviours and attitudes. Without understanding who your target audience is, it’s much harder to effectively design for them. When we started this engagement, we knew the audience we were targeting was aged 45–60. It was then much easier to design an interface that would target and meet their needs and interests. For example, given the audience’s age demographic, we decided to make the font sizes more legible, and to design icons and buttons that would be clear and easy to see.

In our app, the player view is the portion in red.

The player view (see above image) posed a challenge as there are many states needed for the buttons (i.e.: highlighting a button to illustrate that it has been selected, or changing the colour of a button to indicate that it’s active). We needed to make sure each state was clearly identifiable and distinguishable, that way, our users could easily understand how to use the player.

A further design consideration was designing a player that’s always on screen, without compromising usability and a user’s ability to navigate through other content on the app. It was important to our client that the player was on screen throughout use, while having easily accessible content. To manage both, we struck a careful balance between condensing and including as much content as possible and legibility of this content.

Engineering for FireTV

When building an app, developers usually focus on the available library toolset. In our case, building for FireTV, that was the Leanback library. Leanback is the defacto TV framework that provides software engineers with a starting point for development. It has a standardized set of User Interface (UI) components which work pretty well if you use them as they were intended.

However, there are some limitations to the Leanback library, particularly when you want or need to modify any of the pre-specified functionalities. This is where we found ourselves at a fork in the road: we wanted to build a quality application that would meet our client’s needs but we were unable to use the existing Leanback settings fragment. So we found ourselves needing to build our own components instead of using what was provided by the Leanback library. By building our own components, we were able to meet the client’s desires. In short, engineers should use the Leanback library to enhance development, not drive it, and to always keep the focus on the client’s needs.

Our client wanted to have a cool wave animation that would play when the user was listening to music. Originally, we tried to have the animation match the music but this proved to be pretty difficult, especially in maintaining smoothness. Instead of getting lost in the weeds of perfectly matching the animation to the music, we felt it would be best if we created an elegant yet pleasing wave animation. In order to do this, we used Lottie. Lottie is a powerful library that allows developers to import the crazy cool artwork made by designers in Adobe After Effects into their apps. The Lottie After Effects plugin exports a minified JSON file into the app project. The animation can then be rendered onto the device through the Lottie library. Using Lottie allowed us to iterate on the animation quickly and effectively. Without Lottie, it would have been much harder to craft elegance into our app.

Test Driven Development (TDD) is the current hottest trend in the development world. Why? Because it allows developers to essentially prove that the code will do X, X being the functionality that they are trying to write. By using TDD, when building applications, bugs can be found and fixed even before the application is run on a device. It also gives developers a safety net when they go to refactor code or implement new features that have the potential of breaking any pre-existing code. The flow of TDD is: write a failing test, write some code to pass the test, refactor, and repeat. During the development of our FireTV app, we utilized TDD when structuring the flow for retrieving data from the network. This helped us organize our data flow and iron out any bugs that could have caused issues later in development. We highly encourage developers to use TDD when building applications as it can save you from headaches and will allow you to build the best app.