Honestly about Rive, with some ideas
Rive offers powerful realtime vector design and animation for app and game designers alike.
Introduction
Many of you start using Flutter and are looking for ways to make cool animations there, and your path leads to https://rive.app since, I will be honest — these guys have no serious competition, on the field of the Flutter animations. I have been using this tool for almost half a year (then it was called Flare), almost every day and I’ve spoken with a member of the Rive team, who inspired me to write this article. Here I will not consider the use of the Rive as such, but try to describe the pros and cons of this tool, with some ideas from my side.
Firstly, I want to congratulate all of you who have just started to study Rive now — you are like Hercules with a calf on his back. Rive will grow faster than you, and after a while, not noticeable for yourself, you will already carry a bull on your back. Imagine what it will be for beginners, in a couple of years — Rive will be a sophisticated tool with an insane amount of functions that will need to be studied from scratch. But you will master them gradually, with the time of their appearance (say “hello!” to the shadows, glow, and blur).
Cons:
Let’s start with the obvious disadvantages associated with this, at the moment (so that you would not write, that Rive paid me for this):
- The tool is still not polished to perfect condition, Design Editor, for example. If you saw “How it’s made — Steampunk #FlutterClock” video (which I recorded while preparing animations for my Flutter Clock), then you might notice that I didn’t prepare the assets in Rive, since I would have worked on this much longer there.
- The documentation does not manage to be updated fast — documentation seems to exist, but for example, when I needed to cache animations in the Flutter package version 2.0.1, which solved problems with shadows I’ve had — there were about less than a couple of days before the Flutter Clock deadline. The syntax for caching has also changed, in this version, but there was no new information on the Flare-Flutter caching strategy documentation. Imagine my frustration as a beginner, without a development background, that delved into the source code, to understand how to do it in a new way…
- Here you can still see the popup “You found a bug”, from time to time, but watch my time-lapse video yourself — it crawled out sometimes, without any special logical reasons for me. Also, SVG imports are still buggy if you have non-trivial gradients.
- Recently I saw a video — their team in New York spreads 2D layers into 3D, adding depth, right in the code. Um, so it was possible? I did not know this, and I do not know many other features that are just waiting for publication, although it was possible to do this for a long time. This is connected with paragraph two, probably. Luckily, they’ve just recently started releasing short instructional videos.
Pros:
The disadvantages end here, at least for me and the pros begin. The main plus, IMHO, is unlimitedness — here you can create almost everything you can imagine. Your imagination is the only limitation. So:
- It’s free.
- It’s open-source.
- There is a bunch of runtimes.
- No need to install anything (you can create animations even on a netbook).
- The design looks the same as on the device (due to the same Skia engine).
- Each pixel, if desired, can be moved directly through in code.
And much more, just look at the info in their landing page, it’s all true.
UX/UI Part
It would not be right to criticize Rive Team, for their shortcomings, without providing solutions on how to fix this. Therefore, I decided to make (including on the advice of Umberto Sonnino) a small redesign concept for Rive Design Editor, which can be viewed here. Feel free to criticize:
https://www.behance.net/gallery/91690781/Rive-Editor-Redesign
Code Part
In addition to UX, I had ideas for optimizing exported FLR files based on the SVGO library (which I use on my assets before applying them in animations). I’ve noticed in JSON exports and in editor, that many coordinate values, etc. have very long decimal places. I think you will not find much difference between the coordinate of the object 0.11234423112456 and 0.112. This is one of the main principles of SVGO — rounding values. If it works there, I think a similar principle can be applied here too. To do this, I tried to round the values in my thermometer animation. The original FLR file was 237 kB in size, and the optimized file became 209 kB in size. That is almost 15% — not bad. I tried this on other animations, and it turns out about 12–18% on each file, depending on its complexity. The quality of animation and design has remained the same, at least for my eye, but now there are much fewer kilobytes in memory. Maybe you can reduce not only these values, but also other parameters, but I’m not a “rockstar” developer, and I’m not sure, if something like this happens in binary exports — nevertheless, maybe this will help someone. If you want to try it with your exports or just want to take a look — welcome to my repository on the GitHub, called FLRO.
I may be wrong somewhere, but this is not a recommendation article, and I’m just expressing my opinion on my favorite product. I will be glad to any response, for example, in the comments. Thanks for your attention!
