New tools for a new streaming platform
Home
As a developer, you face hurdles with learning a new platform. Firebolt SDK is no exception to that rule, and if anything, it meets more of a challenge because it's new and built on RDK, which itself is relatively new. I led a design team to discover how to teach developers a new platform while avoiding other platforms' typical pitfalls. By the end of a year and a half engagement, my team launched four products in six-week agile sprint deployments.
A few years ago, Comcast and other large cable companies formed RDK, an open-source platform. Their goal was to install RDK on all of their new set-top devices and third party suppliers devices, then distribute the software to third-party publishers.
A problem arose when these devices' demand fell short and provided little incentive for popular applications to join the platform. Even worse, competitors like Google saw an opportunity to enter the market with a version of Andriod for TVs and set-top boxes.
It was clear that I had to first understand how developers learned and what methods were the most effective. Also, I needed a holistic overview of what was required and how to get there. The design team and I sat down with stakeholders, developers, and the product team to define goals. Our mandate was:
Now that we had goals, we first tackled the marketing website; next, we learned and built a lesson based system to onboard new developers.
The success of our first two products was paying off unexpectedly. Instead of the influx of independent developers we initially sought out, we were getting more corporate publishers. That led to more strain for our QA and Dev support teams. The developer testing application became our next priority.
Developers prefer a debugging experience with Git integration and regular updates.
We built Firebolt Developer, a marketplace-like app for companies to load, run, and debug their Firebolt SDK applications. Anyone creating an app can get real-time feedback if an application crashes with the ability to see runtime code errors like popular editors.
We didn't have to start entirely from scratch; There was a version of the application available and lacked most of what we were trying to achieve.
Our goals were to rapid prototype, iterate, and repeat until we felt like our solution achieved our goals:
Our hypothesis was developers who would use the app for the first time would want to see their app first. We imagined a scenario where developers could have several builds of their app and want a way to organize them.
All the features combined lacked hierarchy, which resulted in a disjointed experience.
I asked our QA team for help; I wanted to know if our assumption about the groups is warranted. Most teams work on a max of three builds, which is far under our hypothesis. Dropping that opened up the possibility to focus on functions: Start and Stop.
The moment we realized we had an idea that met our goals and saw the clarity and hierarchy in place, we moved to test.
Paper Prototyping was the most agile and reliable way to test a set-top box application. Our testers were split between high and low domain knowledge. Early tests revealed:
- 3 of the 4 participants could not figure out how to access the shortcut controls.
- General dissatisfaction and frustration due to lack of navigational clarity.
Note: Two of the participants noted that the low-quality keyboard impacted their experience.
In the first round, our testers were asked to open an application then stop it.
To prove that we had solved the navigational problems, we asked the next round of testers to perform the first test. To advance the experience, we asked them to perform a secondary task: Open an application, then suspend it.
- The navigational elements proved to be more intuitive, but one tester asked for help.
- We thought a second drawer with large buttons would add clarity. The impact was not as helpful as we expected, and if anything, complicated the interaction.
Our iteration included changing from Options to Controls to help clarify the shortcut commands drawer. We also added toasts, which showed the command they used after using it, and removed the second drawer option.
- We solved the problem of testers asking for help while using shortcuts.
- The toasts helped by clarifying actions and boosted the testers' confidence.
Testing version three came later during our run-up to deployment for version six. We added more screens and toasts to the test to show participants feedback per their actions. In addition to that, we added an Xfinity remote. The task was to use the keyboard or remote to open, suspend, then return home.
Conceptualizing the initial design, I kept a couple of thoughts in mind. Refer to what we learned from testing and work within these constraints:
This app was new territory for the team. We needed icons and typography that worked together. Our answer was with Xfinity's TV design system icons and font.
Primary Blue indicates any action. Primary Orange was initially used as a secondary action until we moved it to the primary validation action for simplicity and clarification.
RGB(41, 41, 41) RGB (118, 118, 118)
RGB(0, 0, 0, 90)
RGB(0, 169, 157)
RGB(255, 127, 80))
Segeo, a monospace font, was selected due to its familiarity with the debugging interface.
Version two was to include:
One unforeseen problem was with SVG's. Scaling became a problem from 720p to 1080p. The drawer wasn't scaling correctly; it showed too much horizontal white space. We solved it by including a second SVG but exposed a long term problem for other resolutions.
Version three was updated for internal teams but not distributed to our partners. Version four was updated and deployed.
Version five was updated for internal teams. Version six was updated and deployed.
Working with an international team of both designers and developers was a real delight. Everyone was fun to work with and had the same drive to deliver results. Timezones did pose a challenge at first but was easy to overcome. Our team "snack breaks" via a Slack or Team call was a blast.
The most significant impact was felt by the internal teams, who no longer had to work each step of the way with developers. Cost-saving estimated over $1M a year.Return to the Comcast Bio