Master Plan

The why

I became a UI animation evangelist back in 2016. My path started with workshops, later there was the launch of a small UI animation course. And on every group there were several people who asked me, "Why is After Effects so complicated? When are they going to release a sketch for animation?". My answer was, "Adobe should be releasing some kind of software to make it easier to work with soon." But here we are in 2021, and not a single company has made a good analogue of AE for animating interfaces.

Technology changes every 5 years, and animation software hasn't received a major update since 1997. Developers add minor improvements and small features and we are still operating in the old paradigm of thinking about animation.

Since then, we've gotten great tools for creating and collabbing over static design. We can quickly create simple prototypes, but we always work separately on complex animations. Although every interface involves animation in one way or another.

I am delighted at how Figma has changed our perception of the work. It is a handy tool to start and further work on the design and design systems. But it doesn't cover the important step of work - animation.

A typical interface animation process is as follows: the designer imports final designs into After Effects using the AEUX script. The script is good, but it doesn't work perfectly, shifting layers, breaking the structure of texts and icons. The designer is forced to edit almost every design element. It's a chore that should be done by tools, not people. But after the designer has imported everything and made the animation, another very unpleasant process begins - the stage of preparing documentation for the developer. As I said before, AE works in the old paradigm of thinking, and all animation created in AE can't just be transferred to an interface. Whether it's a web application or a native application. The designer needs to interpret all the properties he animated into an understandable format for the developer. And this large amount of work takes up precious time that teams could spend on improving their products, rather than on the routine translation of one "language" to another.

The second very important problem is that the design, animation, and code exist in different places. If the design changes, you have to go through the process of animation and its preparation all over again. It's easier for the developer, he's not redoing from scratch what's already done, he's just making changes. Why then is it necessary to redo the animation from scratch every time? This contradicts the common notion of the agile process. The cost of updating old components is comparable to creating new ones. Instead of focusing on improving what's already there, small companies move forward, creating new features and shelving old ones. Technical debt is growing at a cosmic rate.

There's a rule of thumb in programming called cohesive. It tells related components to stick as close as possible. I believe that in an ideal world this should be the case. Designers create visuals: they design a component, indicate what can be changed in it, then they create animations and pass them to the developers. The developers, on top of that, are linking logic. Everyone is focused on his or her task, but everyone works together.

The third problem is that the discussion of interface animations is split among several applications. The design itself can be commented on in figma or invision. The code can be commented directly on github or gitlab. And where do you comment on the animation of the interfaces? There is http://frame.io, but it is more geared towards motion design and filming and has nothing to do with the current ecosystem.

And the last problem I want to solve is the ability to provide instant feedback to the teams. Design is a visual language, you do something and immediately see the result. It's a little more complicated with code. The feedback is a bit delayed, you have to change something, wait for a new compilation and only then watch. With integration of animation into the code in general a dark forest. You never know what the end result will be. Even if the designer will prepare everything perfectly and pass it on to development, there is a good chance that something will go wrong. And the longer it takes to get feedback, the longer it will take to develop and integrate.

To make it clearer, let's look at a small component as an example:

1. design - 2 hours;

2. import the design into AE - 1 hour;

3. make the animation in AE - 1 hour;

4. prepare documentation for the developer - 2 hours;

5. integrate the component into the code - 4 hours;

6. test the made component and write comments - 1 hour;

7. provide comments - 1 hour.

Total: 12 hours to create a simple component. And that's not even mentioning the fact that this component should be checked by the Q&A department. And what part of those 12 hours is useful? Only items 1, 3, 5, i.e. only 7 hours. The remaining 5 hours (almost half!) of work are taken up by tasks that shouldn't exist at all.

The how

When I started working on Aninix, I planned to create a simple tool for animating interfaces, which would help to get away from AE and make the work process more pleasant. But now I see that the problem is much bigger. And this tool will save time for the teams and allow them to focus on creating something new, get away from the routine and work on interesting tasks.

As a result, our future plan is to:

• Provide a tool to work on interface animations;

• expand the tool's capabilities to create maintainable motion-design systems;

• create a way to communicate and work together on motion-design components;

• create automatic export of animated components to code;

• and that's all inside the figma.

Written by Tony Pinkevych on July 29, 2021