How Tinder Solves Complex Lottie Localizations with Server Driven UI

Author: Jason Picallos

At Tinder, we enjoy delivering global-wide experiences to our members. As such, we deploy visually-rich content all around the world, and localization plays a huge role. To accomplish this, the engagement team uses dynamic content that sends down information to the client where translations are happening from the backend. While leveraging rich and robust animations through Lottie, there was still a fair amount of manual work to achieve localization. In order to localize the content, the team had to customize each animation for every locale. This meant that the team would have to update each animation to change the language for every new campaign locale, which was not scalable or sustainable. This led us to find a long-term solution that would better serve Tinder.

What we built

After some trial and error, we found a viable solution by drilling down on the Lottie framework properties. For context, Lottie is a framework that allows mobile clients to render highly graphic and complex animations efficiently. Using Lottie for these complex animations, introduced the problem of localization if the animation was rendered as a graphic rather than separated text layers. To amend this, we had our AfterEffects engineers build specific dynamic text layers. This allowed us to override text within the animation body to be localized. So rather than having the team manually change the content, we can now use the same animation, while localizing just one animation’s dynamic text layers.

The 4 platforms that need to be in agreement

• After Effects — They’re the first in the pipeline, creating an After Effects JSON-specific text layer naming convention. In addition to the text layer naming itself, it has to be its own layer and it cannot be rendered as one graphic layer. The naming convention is one in which all platforms must agree upon as this is what is used for mapping and overriding the proper text that needs to be localized.
• Insendio — Tinder’s in-house platform for delivering dynamic content. For this part of the solution, Insendio is leveraged for the campaign creator to specify which text values in the animation should be localized. In the example above, the campaign creator would enter values for textLayer1 and textLayer2 to be localized.
• Backend — The backend receives a localized version of the text which allows it to remain lightweight as it just needed to receive new values just as it would have any other new dynamic content fields and then pass that down to the client.
• Client — Clients also remain lightweight as it receives the new dynamic content and simply overrides the Lottie animations text layers using the textProvider from the SDK.

Not only was this a win for the team, but it’s also a solution that we can use for design content org-wide. As excited as we are to have solved this challenge, it was equally as enjoyable to test and brainstorm various options.

Experimenting to solve the challenge

We didn’t solve the problem with the first idea we had. In fact, there were a few hypotheses and conceptions thrown around before we actually tested. One of our first attempts involved creating different campaigns. We exercised the idea of creating a new animation for every new campaign locale which would require an After Effects engineer to create 40 different animations in different languages. While that technically worked, the manpower and manual processes made it difficult to scale. Thus the solution to solve for scalability required a bit of algorithmic ingenuity by way leveraging the concepts of Time Complexity for our assessments. ¹

Time complexity in the real world

One of the ways we can determine the scalability of an algorithm is by that time complexity. While this is optimal from a computer science standpoint, it can also be somewhat transcribed into problem-solving approaches towards scalability in the real world. In the brainstorming session, we did so for possible solutions to this problem, looking at time complexity as if it were applied to our actual physical requirements. A clear example of this is the first approach we thought of, which consisted of having an After Effects engineer create a new Lottie for every single campaign locale. We then looked at the time complexity of this as if it were an algorithm.

Specifically, if this solution was chosen, that would mean for every input (in this case campaign locale) we would have to push out the same number of animations to support that specific region. This yields a time complexity of O(n) (purple line), essentially stating that for every new locale, we have a proportional amount of output, or animations needed. This compared to our best solution is drastic in scalability improvements. The solution in which we arrived at allows us to have 1 animation for (n) number of campaign locales/campaigns. This time complexity is 0(1) (blue line), essentially stating that irrespective of the number of inputs (campaign locales) , we only have to leverage 1 animation or output. While this analogy is not directly applicable as it would be towards an algorithm from a computer science perspective, it still provides a logical blueprint for constructive brainstorming and problem-solving which allowed us to arrive at the very best solution we could. Now a single animation can provide an infinite number of localized assets.

The value of investing in problem-solving

Perhaps one of the most satisfying aspects of this project was the freedom to holistically find a viable solution. We were given the opportunity to take our time and work together to solve the challenge. Our team was presented with a problem but not a deadline. The first thing that happened was brainstorming as a team. We also collaborated with our entire Pod– consisting of design, engineering, and product– creating presentations, showcasing our potential solutions. It is because of that collaboration between design, engineering, and product, that we were able to come up with a solution that encompassed all three disciplines. Each department has its particular needs and restrictions. This cross-functional approach led us to design a solution that addressed each function’s constraints while delivering a result that benefited all parties involved. Rather than quickly spinning up a short-term fix, we designed a solution that will be used for years to come.

Maximizing solutions through creativity

Creating best-in-class solutions requires an iterative process and mindset. It also requires a degree of creative freedom and autonomy. We try to approach our work with the understanding that processes can always be improved. For me, it’s also one of the joys of the work.

If you’re interested in joining a fun, creative, and challenging environment, we’re hiring.

Special thanks go to Juzheng Li, Joanna Chan, Gefei Zhou, Nhu Luong, Marianne Leoncio, Emmy Buckman, Vikram Reddy Kadi, Fang Chen, Greg Giacovelli, Devin Entmacher, Joon Park, Cesar Diez Sanchez, Trystan Johnson, Andrew Harris, and Devon Strawn. Without their contributions, this work would not have been possible.

¹ To be clear when referencing Time Complexity, it’s not relative to the code itself, but rather the metric we used to determine the most elegant solution using all of our real-world resources.