I, for one, don't want this. At all. Taking a look at my screen right now, there are probably close to a hundred or so icons in various applications visible on my desktop. If all these icons were wiggling and dancing, distracting me in my peripheral vision, it would be infuriating. I already had to disable animation in Slack due to the constant barrage of animated emojis. Let's not just do this because we can.
Even within the article there's already one that's questionable from an accessibility standpoint - the speeding train makes me a bit nauseous to look at and might present difficulties to users with balance or ocular disorders.
Also, I can't agree with "Let's not just do this because we can." enough.
It's the same kind of distraction as autoplaying videos or picture-in-picture annoyances like YouTube's auto-minimizing window. The mechanism is the same. It's a thing moving in some part of the screen and being distracting, only in this case they provide even less value since they're nothing more than decorative doodads.
There isn't even an argument that doodads like these can placed on websites in an attempt to monetize users, like ads, where all the debate about sustainable sources of revenue and the ethics of adblocking come into play. They serve no material purpose at all except to be distracting.
Animations of any kind, even the ones that are finite in lifespan or simple page transitions, already annoy me greatly. If we lose this front, where random businesses start adding things like this only because the web platform has sufficiently advanced technologically to allow it, and a majority of users become desensitized into believing it is "cool" and shifting the the baseline of the web such that this majority now expects and might even want this kind of behavior, it would surely become another unnecessary annoyance. I feel like this has already happened with Metro/Flat design and the death of skeuomorphism (more or less), and also the overuse of animated GIFs in blogs.
But there's nothing making it outright illegal, so I'm not sure what would stop them from doing so at this point. We can't exactly go back to Web 1.0 (nor should we) - that kind of design is opt-in now.
Why? To tell the user where there mouse pointer is? Is that a problem?
Or are you forcing people to scrub over every element on the screen to "discover" instead of it being visible to begin with? That's annoying as hell and people are probably missing things because you chose to hide them by default.
Totally agreed. The author isn’t wrong about the workflow issues around svgs, but icons are not usually animated for good reason.
The human eye is very sensitive to motion. It can be a fun thing to add to loading screens (the gusto pig, for example), but icons are designed to live on a page for a long time and only take our attention when we are actively looking for them. Motion is not good for this purpose.
What about progress overlay icon? It should be animated. Or something like downloading a file. If icon represents a work in progress, it's a good idea to make it animated. Of course animation must not distract too much.
I agree there is a need to sell the need, and this page doesn't do a good job of doing that because while a looping animation is good for showing the animation, as you say, it isn't a good idea.
I can see animations like these working for when a user interacts with something, as an alternative to just highlighting or doing a material style ripple. The problem is that most of the time I'd want that, I'd also want to transition between two states, which—unless I'm missing it—isn't something this offers.
The killer app for animated svgs is not icons. It's graphics that are meant to be given attention to convey something important. We do that with raster graphics and it works okay, but low resolution rasters of yesteryear look bad.
And "low resolution" SVGs will look bad in the future too. It won't be as graphically apparent, but they will look barren and odd, because there's no detail as they were designed with a lower resolution in mind.
The detail level is a design choice. Even though you could have immensely intricate SVGs, you expect some graphics to take up a small portion of your view. Unfortunately the screens are the only things getting better over time, not the eyes.
Icons designed to be small have less detail and often rely more on the general shape, sometimes exaggerating certain features of the icon to make them stand out. Large icons or images can be filled with lots of rich detail. Scaling up a small icon often makes it look barren and generally out of proportion, and scaling down large, highly detailed icons/images makes the icon "noisy" and loses the essence of the icon.
This does not only apply to vector icons, by the way. Most highly polished icon sets will have an icon for different sizes. For example, in Windows, zoom the desktop icons in/out and compare.
I think they can add value as a response to user action. No a repeating animations, but a short animation upon validating data or handling interaction. I would be the first to find a way to disable these if they'd start autoplaying on every website I visit though.
An animated green check mark when showing a popup confirming that an action has succeeded, an animated red cross when showing an error, wheels of a car icon rolling when hovering over the car option in the menu, those kinds of animations can all aid design by showing the user that the site or application is responding to user feedback.
It makes the user flow just a tiny bit more interactive and polished without being too distracted. After all, if there's a popup, the intention is to direct the attention of the viewer to that spot already. Same with a menu icon.
That said, the animations shouldn't be too fast. Some examples, like the moving train, are way too fast to be comfortable to use in my opinion. Proper pacing is important.
SVGs in general seem to have had quite a poor adoption rate. Editors for them are fewer, paint can't open or edit them, and support for them is iffy with even google docs not supporting the format for importing an image.
> SVGs in general seem to have had quite a poor adoption rate
I don't know. I'm not sure what the real numbers are but in my experience SVGs are pretty commonly used for app and web icons because they are easily "themeable" (color changes etc.)
A lot of designers I know just keep a raw layered image and swap out themeing on a per-case basis. SVGs are easier to dynamically theme, but usually any theme variants get run by a designer anyways that will tweak color tones for the specific usage as needed.
Just to be clear though - I love SVGs and want them to get more momentum solely on the basis that they're just a way better way to store abstract line art and can yield proper image scaling... I just think a lot of the technical advantages we tend to think of aren't really that valued by designers and get lost in needing to be done manually anyways.
One big problem with SVG is that the specification is so large that everyone implements a subset, so interoperability suffers.
Lots of XML-based standards of a similar age seem to have suffered from this. There was an idea that there'd be a standard for everything, and each XML-based standard would refer to others when it made sense rather than re-inventing the wheel. But too often the result was that in order to implement standard A fully you needed to implement all of B and C and D which your users didn't really care about, so in practice you ended up with an undocumented de-facto usable subset.
(Though for SVG I think the worst problem is that they didn't specify a fixed subset of CSS that should be supported, which isn't an XML-world thing.)
A side issue is that non-trivial SVG authoring is painful to do by hand, so most people use some tool to do it. But the exported SVG will work on the rendering engine of the tool, not necessarily wherever it gets rendered downstream, and it can be difficult to know which features of your tool will result in rendering issues downstream. And sometimes the error is just missing content, others (like filters) often render the image completely black.
It's like using a compiler that supports one version of an architecture and you need to learn what you can/can't do in the source code that will result in illegal instructions anywhere else.
While Sketch is (imo) the best editor I've ever used for SVG it's also the worst about using weird SVG features that are poorly supported outside like, Safari and Chrome (I think they use the former).
There are plenty of people who do know how to create good SVGs, but my first thought when I read the title was: maybe the people who know how, also know it's better not to.
This doesn't match my experience but maybe I'm in a bubble: for open source design and fabrication work, svg is basically as standard as pdf, I'll often convert pdfs to svgs to extract vector art and send it to another process, including 3D mesh editors that can extrude from svg files.
The editor I install on every machine and teach other people to use is Inkscape. The learning curve really isn't that bad, I've seen many kids really take off with it.
Inkscape is so overwhelmingly popular for SVG illustrations on Wikimedia that they've seriously considered just using headless Inkscape as the standard SVG rendering backend, instead of rsvg.
Wordpress is a significant part of the internet (hobbyist and small business definitely) and it still blocks SVG by default due to security concerns because SVG images (like fonts) are essentially scripts/programs, not images.
There are various potential vulnerabilities due to this and you can sanitise images or use correct headers to mitigate the issues, but it's easier for many to just say no and sidestep the issue.
Motion is a design tool like any other and can be abused if it's overused.
A button that's a bright color will draw the eyes to that particular element... until that element is everywhere on the page. At that point it just becomes visual noise. Passively animating icons everywhere are a terrible choice, as it doesn't give the eye any focal point.
Animations for icons are great if it's an ongoing task that will likely be completed shortly, but that's about it. You should use motion to draw the eyes to one specific thing on the page, and in general when doing motion design I try and only animate one thing on the page at once.
I've recently done quite a bit of work with SVGs, including those with animations. Some observations:
* Edge doesn't support SVG animation in the older engine, only the newer Chromium-based one.
* Until recently, Chrome had a massive memory leak with SVG animations that loop if left up for several hours.
* SVG animations often cause enough CPU load to spin up laptop fans.
* There is no SVG support in email, so using SVGs in an environment that has both web and emailed pieces can mean duplicate assets.
* For maximum styling control, SVGs must be inlined. You cannot modify most attributes via CSS if they're loaded as an image.
And one nit about the linked tool from this post, Motion.app is a bad application name choice for OS X. It conflicts with Apple's Motion.app, which more than a few designers are likely to have.
It surely doesn't help that SVG 2.0 is on a seemingly perpetual horizon for almost a decade now and nobody was willing to guarantee functionality everywhere. And SMIL certainly will not be in that one.
Animation being only the tip of the issues, the moment you rely on anything, that isn't a filled polygon with no stroke, SVG support and compability starts falling apart in the most unexpected places.
The SVG + CSS is really clumsy combination. The SVG exists outside web technologies as vector image format, where CSS would be horrible choice. The combination of overly verbose XML and inadequate CSS, each with its own idiosyncrasies creates too much mental overhead for developers. Looking at some online examples, I would hate to work on project that uses this combination.
There is also JS animation option which has many flaws. I guess it is impossible to accelerate on GPU, it forces imperative instead of declarative animation style and you have to execute someone's code in order to show graphics/animation.
I don't think SMIL (or even SVG) is perfect, but it is still the best option for open vector graphics standard. Maybe a much smaller subset would be something all mayor players could agree to support? The transpiler to shader language would be a good solution for performance issues.
> For maximum styling control, SVGs must be inlined
This was a real sticking point for me since editing and version-controlling a standalone SVG file is easier. I've had success with using Javascript to inline SVGs: https://github.com/jonnyhaynes/inline-svg
> You cannot modify most attributes via CSS if they're loaded as an image.
You can't modify the attributes with CSS outside of the IMG, but CSS embedded in the SVG still works.
I use SVGator to create animated SVG and it exports an svg file with embedded animation via css animation / transform, they work great as <img src=".svg">
you can inline external SVG files with SVG injection. Works pretty well and almost feels like working with normal images. Here is an open source SVG injector: https://github.com/iconfu/svg-inject
The performance issues are what prevented me from using SMIL. A project I was working on called for an SVG animation that we also had to move on scroll (don't ask...). The animation was choppy and definitely got the fans spinning.
Swapping that out for the equivalent CSS animation and everything was smooth as butter. It's obvious that SMIL performance is not as important to the browser makers than CSS animation performance.
I had the opposite experience a few years ago, where SMIL performed better than CSS animation but it likely varies depending on what is animated. Problem was only that certain browsers at the time (old Edge for ex.) didn't support it. Thankfully Chromium and FF continue to support it. It has its place and also has supported features CSS has only fairly recently begun to see equivalents for (eg: motion paths).
> There is no SVG support in email, so using SVGs in an environment that has both web and emailed pieces can mean duplicate assets.
FWIW, Thunderbirds displays svg sent as attachments inline at the bottom.
Whatever you do, of course, do not break plaintext email. I only use plaintext emails.
> SVG animations often cause enough CPU load to spin up laptop fans.
Yeah I really don't know why the article claimed animated SVGs are performant. They aren't. SVGs are incredibly slow to render, and asking them to animate is murder as a result. There's no acceleration for them at all, entirely CPU-rendered (slow) and then needs to be uploaded to the GPU for the rest of the otherwise GPU-rendered or at least GPU-composited scene (also slow).
Trying to do any of this on mobile, with extremely high resolutions, is going to absolutely tank performance.
> Creating animations is hard! This is one reason why many developers do not attempt it. You need to have a "design eye" or you need to study animation. People go to school for years to learn about animation and spend years refining their craft.
This! On a project I was working on recently, animations cost around $10k per object. If we wanted to invest in a full experience it easily grew to a several million dollar effort. Although it's high fidelity, the reality is, unlike film or tv, software is ever changing. Styles change and fads come and go. Ultimately the cost is never justified.
I’m surprised that some combination of Canvas, SVG, CSS and JavaScript hasn’t replaced Flash. This is established tech and fairly simple. This combo also makes responsiveness easier, IMO.
I'd say it comes down to two big issues: the first one being the tooling just isn't there, and people don't want to do this stuff in code. The second—and I'd say probably bigger—issue is that video streaming has solved the problem in most cases instead.
Flash animation had its heyday when it was the only way to deliver video and games on the web realistically. With video streaming being so easy and having the added benefit of platforms with lots of eyes already, animation is a hard sell.
As you say, responsiveness is a huge advantage for animation, but unfortunately I don't think that is enough to get people on-board.
I'd be remiss to not point out: the latest version of Tumult Hype [1] added vector shape animation, line drawing, and morphing. It uses SVG under the hood, though SVGs cannot be imported currently.
The shape morphing intelligently figures out the best morph such that the from- and to- shapes can have vastly different control points.
I wrote SVG-SMIL export for Animatron (www.animatron.com) in 2015 that aimed to get near the level of Adobe Flash in plain browser, however it was extremely difficult due to broken SVG-SMIL implementations in all major browsers. You can see some examples here:
The issue back then was that Google suddenly announced their intent to deprecate and remove SVG-SMIL from Chrome, instantly freezing all development there. However YouTube complained and made them change their minds; later they put it into a "frozen" mode but didn't remove it.
For most artists it would have been a risky bet to use it if Google didn't want to support it any further, despite the promise of having an official standard for animation in all browsers.
You can open any of these images and View Source to dive in to the implementation... except for Edge, SMIL plays exactly the same in all browsers, whereas I've found using CSS to drive the animations has varied results (especially in Safari) and worse performance.
Very nice! I love the idea of small animations to dress up long-form articles, and we don't see it enough on the web because most "content" is written by content marketers and animations I guess are too time-intensive to be considered worthwhile.
Could you tell us what the flow looks like? For example, what do you use to create the SVG, clean it up, and import it into SMIL and animate it there?
Also, how much time would you say this process takes you?
Agreed! My process for creating something like this involves a few steps, but is pretty straightforward:
1. Draw vector art in Infinity Designer on my iPad (with pencil)
2. Export as svg, and then clean it up in Inkscape (simplify paths, finalize shapes, etc).
3. Export Inkscape svg and then optimize it with `svgo --pretty`
4. This results in nice clean svg code that I then hand edit to add the SMIL animations. This involves wrapping objects in <g> tags and adding mostly <animateTransforms>. Once you get a hang of the syntax (as with any kind of coding) it's relatively easy.
5. Final debugging / testing happens in the browser. Just open the file directly and use the dev tools inspector.
Total time depends, from 2-3 hrs for a simple sketch and animation (eg. the LinkedIn one) to a day or 2 for something complex.
I appreciate your work and what you've done here. I would consider using these if I could animate them on an event, such as a mouse over or click, but not on a cycle by itself. Is that possible to do?
Also, would it be possible to buy a license for just the icons and not have any recurring fee if I didn't want to use the IDE?
I've wanted to use the web as a replacement for PyQt (and tkinter, going all the way back to ~1995). It's really been amazing how badly the web tracks what is possible (and easy!) in a good GUI toolkit.
Every 3-5 years I go back and try to find out what is the minimal way to get HTML + JS + CSS to produce something that would be easy in PyQt, while also being fairly principled, standardized, and maintainable.
For example, I wanted to make an animation of a robot that assembled burgers where burger components dropped down a hopper, the robot moved its arms around (kinematics) to assemble components, a conveyor belt to convey burgers, etc.
I ended up using SVG Animations. To get anything done, I ended up on 3-4 pages where the designers who implemented the Animation standard show some examples and a few sparse reference docs. I'm not completely unhappy with the results (many kids at maker faire found the animation enjoyable) but it still feels like the web is missing a really good graphics/view framework like https://doc.qt.io/qt-5/graphicsview.html
The graphics view framework is very performant, provides a lot of very nice features "for free", and can make extremely sophisticated applications. It's well documented, but of course is not a web app (some days I wonder what would happen if people did full Qt-on-WASM with a browser window rendering context).
It's pretty terrible though. Definitely not close to "production-ready." Even simple examples take a long time to load and some don't load at all (on Safari and Firefox anyway, I don't use Chrome).
Does the app do anything besides let you edit the colors, stroke, and speed? The blog post made it sound like it would make creating animations from scratch easier, but all I see is library of pre-made animations. If it can be used to make new animated icons, then the main page does a bad job of showing that.
> This process reminds me of web design in the 2000s when Photoshop was king.
~~Cries in Adobe Fireworks~~
I always wondered why Adobe Fireworks, which was a hundred times better than PS for web design, never got traction. I mean this was the time of web 2.0 gradients and rounded corner gel buttons and people were making this stuff with freaking PS. Why? Adobe Fireworks could do vector graphics wonderfully.
What did the workflow of using photoshop even look like? I might be misinterpreting "web design". It means developing a design to be consumed by a computer, and also developing a design to be consumed by a web developer (like a mock-up design).
I have no idea how they did it. In Fireworks you could just slice up your design and export all the assets in one go, all at the desired quality settings. It even supported 32bit png files with alpha transparency. You could have multiple pages and each of those pages could have different states. You could have buttons all over your website that would change everywhere if you edited them in one place (symbols). It was just perfect for web dev.
I miss Fireworks so much, I even tried to run the latest version under wine but never managed to get it to run correctly. Does anyone know of a good alternative that runs on Linux? I've been using Gravit Designer but it's kinda slow.
What kills me is that literally nothing (inc Photoshop) will import a .fw.png file and keep it editable. I know it's using some kind of proprietary extension to the PNG format, and that some gradients and textures would inevitably be Fireworks specific, but it'd still be useful to be able to open an old mockup and tinker with it.
Short answer: Adobe (and their Photoshop) is pretty much the reason Fireworks never got better traction.
Longer answer:
Fireworks was originally a Macromedia product. Back when it was released, from what I recall, it was in fact getting some pretty reasonable traction: in many folks eyes, it was a good upcoming web graphics tool, by the folk who made Flash (which actually had many fans back then). It was cheaper than Adobe's Photoshop, and addressed a different use case, and in those cases it certainly had better workflow.
Then Adobe acquired Macromedia. Fireworks pretty much got back-seated, most probably because Adobe already had a flagship 2d/photo graphics editor. A tiny handful of Fireworks' features made it into Photoshop. And Fireworks got a small amount of integration with the rest of the Adobe suite. But Adobe never really promoted Fireworks. And AFAIK they simply never put any resources (developers) into Fireworks.
Looks cool and all, I was actually pretty sold the moment you started to talk about the editor. However, I still don't know what your editor actually does.
You ended the article abruptly and maybe expect people to click the link and go to your website to learn more? A bit more introduction is needed for your call-to-action to work. You can't just say "I made an editor" without at least listing the key features.
My collaborator and I create animation art with SVG (he is the animator, and I'm the composer/video editor, though we work together on the overall concept).
Thing is, he doesn't use the animation facilities of SVG, because he can't get it to do the extremely complex things he wants to do with it (honestly, his XML/XSLT/SVG chops are not really in question here). Instead, he has a (gigantic) system that renders individual frames using XSLT, and then stitches it together with ffmpeg. His SVG files are already constantly pushing up against the abilities of tools like Batik, and for XSLT, there's really only one fully compliant tool in town (Saxon).
I find it kind of amazing that there aren't better tools out there for SVG -- and frankly, for XML. The fast tools (imagemagick, rsvg, libxslt) aren't compliant, and the compliant ones aren't fast (they're all in Java and very resource intensive).
Despite the fact that all of this uses open standards, it can sometimes feel as if we're working in the next Flash.
Back in 2013 the game magazine Polygon created really stunning illuminations in their Playstation 4 and Xbox One reviews. It's what got my interested in the more advanced uses of SVG and CSS -- it uses a clever trick where it uses the bezier curves as paths that are then filled in by offsetting the stroke fill... here it is.
Used this same trick (but with SMIL) for an automotive client back ca. 2004. They wanted their electrical systems' documentation diagrams to be in SVG, with signals being animated in a similar fashion. At the time the only viewer that supported it was Adobe's ActiveX plugin! (Not claiming credit for the trick; AFAIR I found it on a web forum somewhere... wish I remember who invented it)
The lack of open-source animation tools is really concerning to me. I've been looking for a way to animate some text and graphics for a series of training presentations that I was making and I couldn't find anything suitable. Open source tools are either geared towards animation of cartoons or they're so rudimentary that they're not really valuable to invest the time into.
Anyone have any recommendations for animation tools? Something that works either on macOS or Linux? If only paid solutions exist, what's out there (besides After Effects)?
In the process, we've built a tool to autocrop and optimize SVGs so that they are as small as possible and work correctly in Illustrator and all other readers. The tool is open source and available at https://autocrop.cncf.io.
199 comments
[ 5.8 ms ] story [ 222 ms ] threadAlso, I can't agree with "Let's not just do this because we can." enough.
There isn't even an argument that doodads like these can placed on websites in an attempt to monetize users, like ads, where all the debate about sustainable sources of revenue and the ethics of adblocking come into play. They serve no material purpose at all except to be distracting.
Animations of any kind, even the ones that are finite in lifespan or simple page transitions, already annoy me greatly. If we lose this front, where random businesses start adding things like this only because the web platform has sufficiently advanced technologically to allow it, and a majority of users become desensitized into believing it is "cool" and shifting the the baseline of the web such that this majority now expects and might even want this kind of behavior, it would surely become another unnecessary annoyance. I feel like this has already happened with Metro/Flat design and the death of skeuomorphism (more or less), and also the overuse of animated GIFs in blogs.
But there's nothing making it outright illegal, so I'm not sure what would stop them from doing so at this point. We can't exactly go back to Web 1.0 (nor should we) - that kind of design is opt-in now.
Or are you forcing people to scrub over every element on the screen to "discover" instead of it being visible to begin with? That's annoying as hell and people are probably missing things because you chose to hide them by default.
The human eye is very sensitive to motion. It can be a fun thing to add to loading screens (the gusto pig, for example), but icons are designed to live on a page for a long time and only take our attention when we are actively looking for them. Motion is not good for this purpose.
I can see animations like these working for when a user interacts with something, as an alternative to just highlighting or doing a material style ripple. The problem is that most of the time I'd want that, I'd also want to transition between two states, which—unless I'm missing it—isn't something this offers.
After all, we only got rid of animated GIFs not too long ago.
[under-construction.gif]
This does not only apply to vector icons, by the way. Most highly polished icon sets will have an icon for different sizes. For example, in Windows, zoom the desktop icons in/out and compare.
An animated green check mark when showing a popup confirming that an action has succeeded, an animated red cross when showing an error, wheels of a car icon rolling when hovering over the car option in the menu, those kinds of animations can all aid design by showing the user that the site or application is responding to user feedback.
It makes the user flow just a tiny bit more interactive and polished without being too distracted. After all, if there's a popup, the intention is to direct the attention of the viewer to that spot already. Same with a menu icon.
That said, the animations shouldn't be too fast. Some examples, like the moving train, are way too fast to be comfortable to use in my opinion. Proper pacing is important.
I don't know. I'm not sure what the real numbers are but in my experience SVGs are pretty commonly used for app and web icons because they are easily "themeable" (color changes etc.)
Just to be clear though - I love SVGs and want them to get more momentum solely on the basis that they're just a way better way to store abstract line art and can yield proper image scaling... I just think a lot of the technical advantages we tend to think of aren't really that valued by designers and get lost in needing to be done manually anyways.
Lots of XML-based standards of a similar age seem to have suffered from this. There was an idea that there'd be a standard for everything, and each XML-based standard would refer to others when it made sense rather than re-inventing the wheel. But too often the result was that in order to implement standard A fully you needed to implement all of B and C and D which your users didn't really care about, so in practice you ended up with an undocumented de-facto usable subset.
(Though for SVG I think the worst problem is that they didn't specify a fixed subset of CSS that should be supported, which isn't an XML-world thing.)
It's like using a compiler that supports one version of an architecture and you need to learn what you can/can't do in the source code that will result in illegal instructions anywhere else.
While Sketch is (imo) the best editor I've ever used for SVG it's also the worst about using weird SVG features that are poorly supported outside like, Safari and Chrome (I think they use the former).
https://www.w3.org/TR/SVG11/painting.html#ColorInterpolation...
The editor I install on every machine and teach other people to use is Inkscape. The learning curve really isn't that bad, I've seen many kids really take off with it.
There are various potential vulnerabilities due to this and you can sanitise images or use correct headers to mitigate the issues, but it's easier for many to just say no and sidestep the issue.
A button that's a bright color will draw the eyes to that particular element... until that element is everywhere on the page. At that point it just becomes visual noise. Passively animating icons everywhere are a terrible choice, as it doesn't give the eye any focal point.
Animations for icons are great if it's an ongoing task that will likely be completed shortly, but that's about it. You should use motion to draw the eyes to one specific thing on the page, and in general when doing motion design I try and only animate one thing on the page at once.
* Edge doesn't support SVG animation in the older engine, only the newer Chromium-based one.
* Until recently, Chrome had a massive memory leak with SVG animations that loop if left up for several hours.
* SVG animations often cause enough CPU load to spin up laptop fans.
* There is no SVG support in email, so using SVGs in an environment that has both web and emailed pieces can mean duplicate assets.
* For maximum styling control, SVGs must be inlined. You cannot modify most attributes via CSS if they're loaded as an image.
And one nit about the linked tool from this post, Motion.app is a bad application name choice for OS X. It conflicts with Apple's Motion.app, which more than a few designers are likely to have.
Animation being only the tip of the issues, the moment you rely on anything, that isn't a filled polygon with no stroke, SVG support and compability starts falling apart in the most unexpected places.
> We firmly believe that SMIL is not in the best long-term interests of the open web platform for several reasons:
> * There is no clear path towards broad cross-browser support.
> * The vendors which support SMIL have implementations that continue to vary widely, even after more than a decade of support.
> * There are high-quality cross-platform replacement features on the horizon.
https://groups.google.com/a/chromium.org/forum/#!topic/blink...
That still sounds very "obsolete" to me.
CSS animations also solve the performance problem because they can be GPU accelerated.
There is also JS animation option which has many flaws. I guess it is impossible to accelerate on GPU, it forces imperative instead of declarative animation style and you have to execute someone's code in order to show graphics/animation.
I don't think SMIL (or even SVG) is perfect, but it is still the best option for open vector graphics standard. Maybe a much smaller subset would be something all mayor players could agree to support? The transpiler to shader language would be a good solution for performance issues.
This was a real sticking point for me since editing and version-controlling a standalone SVG file is easier. I've had success with using Javascript to inline SVGs: https://github.com/jonnyhaynes/inline-svg
You can't modify the attributes with CSS outside of the IMG, but CSS embedded in the SVG still works.
I use SVGator to create animated SVG and it exports an svg file with embedded animation via css animation / transform, they work great as <img src=".svg">
Swapping that out for the equivalent CSS animation and everything was smooth as butter. It's obvious that SMIL performance is not as important to the browser makers than CSS animation performance.
It's far preferable to most scroll-related effects I've seen.
FWIW, Thunderbirds displays svg sent as attachments inline at the bottom. Whatever you do, of course, do not break plaintext email. I only use plaintext emails.
So I use Thunderbird, with no HTML, images or remote resources.
And there's a site that, every week, sends me this message:
> Please view this email in an HTML compatible email client.
Yeah I really don't know why the article claimed animated SVGs are performant. They aren't. SVGs are incredibly slow to render, and asking them to animate is murder as a result. There's no acceleration for them at all, entirely CPU-rendered (slow) and then needs to be uploaded to the GPU for the rest of the otherwise GPU-rendered or at least GPU-composited scene (also slow).
Trying to do any of this on mobile, with extremely high resolutions, is going to absolutely tank performance.
This! On a project I was working on recently, animations cost around $10k per object. If we wanted to invest in a full experience it easily grew to a several million dollar effort. Although it's high fidelity, the reality is, unlike film or tv, software is ever changing. Styles change and fads come and go. Ultimately the cost is never justified.
Flash animation had its heyday when it was the only way to deliver video and games on the web realistically. With video streaming being so easy and having the added benefit of platforms with lots of eyes already, animation is a hard sell.
As you say, responsiveness is a huge advantage for animation, but unfortunately I don't think that is enough to get people on-board.
The shape morphing intelligently figures out the best morph such that the from- and to- shapes can have vastly different control points.
[1] https://tumult.com/hype/whats-new/4.0/
https://drive.google.com/drive/folders/14DKPte-1YvU5IV3Rb8zd...
The issue back then was that Google suddenly announced their intent to deprecate and remove SVG-SMIL from Chrome, instantly freezing all development there. However YouTube complained and made them change their minds; later they put it into a "frozen" mode but didn't remove it.
For most artists it would have been a risky bet to use it if Google didn't want to support it any further, despite the promise of having an official standard for animation in all browsers.
https://www.pcmaffey.com/roll-your-own-analytics
https://www.pcmaffey.com/finally-i-closed-my-linkedin
https://www.astronomer.io/404.html (let this play > 1 minute)
You can open any of these images and View Source to dive in to the implementation... except for Edge, SMIL plays exactly the same in all browsers, whereas I've found using CSS to drive the animations has varied results (especially in Safari) and worse performance.
Could you tell us what the flow looks like? For example, what do you use to create the SVG, clean it up, and import it into SMIL and animate it there?
Also, how much time would you say this process takes you?
1. Draw vector art in Infinity Designer on my iPad (with pencil)
2. Export as svg, and then clean it up in Inkscape (simplify paths, finalize shapes, etc).
3. Export Inkscape svg and then optimize it with `svgo --pretty`
4. This results in nice clean svg code that I then hand edit to add the SMIL animations. This involves wrapping objects in <g> tags and adding mostly <animateTransforms>. Once you get a hang of the syntax (as with any kind of coding) it's relatively easy.
5. Final debugging / testing happens in the browser. Just open the file directly and use the dev tools inspector.
Total time depends, from 2-3 hrs for a simple sketch and animation (eg. the LinkedIn one) to a day or 2 for something complex.
Also, would it be possible to buy a license for just the icons and not have any recurring fee if I didn't want to use the IDE?
Every 3-5 years I go back and try to find out what is the minimal way to get HTML + JS + CSS to produce something that would be easy in PyQt, while also being fairly principled, standardized, and maintainable.
For example, I wanted to make an animation of a robot that assembled burgers where burger components dropped down a hopper, the robot moved its arms around (kinematics) to assemble components, a conveyor belt to convey burgers, etc.
I ended up using SVG Animations. To get anything done, I ended up on 3-4 pages where the designers who implemented the Animation standard show some examples and a few sparse reference docs. I'm not completely unhappy with the results (many kids at maker faire found the animation enjoyable) but it still feels like the web is missing a really good graphics/view framework like https://doc.qt.io/qt-5/graphicsview.html
The graphics view framework is very performant, provides a lot of very nice features "for free", and can make extremely sophisticated applications. It's well documented, but of course is not a web app (some days I wonder what would happen if people did full Qt-on-WASM with a browser window rendering context).
https://www.pixijs.com/
Kinda seems like the blog post was just there to sell the app, which is just there to sell 'premium' icons.
~~Cries in Adobe Fireworks~~
I always wondered why Adobe Fireworks, which was a hundred times better than PS for web design, never got traction. I mean this was the time of web 2.0 gradients and rounded corner gel buttons and people were making this stuff with freaking PS. Why? Adobe Fireworks could do vector graphics wonderfully.
Longer answer:
Fireworks was originally a Macromedia product. Back when it was released, from what I recall, it was in fact getting some pretty reasonable traction: in many folks eyes, it was a good upcoming web graphics tool, by the folk who made Flash (which actually had many fans back then). It was cheaper than Adobe's Photoshop, and addressed a different use case, and in those cases it certainly had better workflow.
Then Adobe acquired Macromedia. Fireworks pretty much got back-seated, most probably because Adobe already had a flagship 2d/photo graphics editor. A tiny handful of Fireworks' features made it into Photoshop. And Fireworks got a small amount of integration with the rest of the Adobe suite. But Adobe never really promoted Fireworks. And AFAIK they simply never put any resources (developers) into Fireworks.
I, for one, am exceedingly happy that the web isn't filled with this stuff.
You ended the article abruptly and maybe expect people to click the link and go to your website to learn more? A bit more introduction is needed for your call-to-action to work. You can't just say "I made an editor" without at least listing the key features.
Other than that, good luck.
Some samples of our work here: https://vimeo.com/user1776782
Thing is, he doesn't use the animation facilities of SVG, because he can't get it to do the extremely complex things he wants to do with it (honestly, his XML/XSLT/SVG chops are not really in question here). Instead, he has a (gigantic) system that renders individual frames using XSLT, and then stitches it together with ffmpeg. His SVG files are already constantly pushing up against the abilities of tools like Batik, and for XSLT, there's really only one fully compliant tool in town (Saxon).
I find it kind of amazing that there aren't better tools out there for SVG -- and frankly, for XML. The fast tools (imagemagick, rsvg, libxslt) aren't compliant, and the compliant ones aren't fast (they're all in Java and very resource intensive).
Despite the fact that all of this uses open standards, it can sometimes feel as if we're working in the next Flash.
https://www.polygon.com/a/xbox-one-review#console
https://product.voxmedia.com/2013/11/25/5426880/polygon-feat...
Anyone have any recommendations for animation tools? Something that works either on macOS or Linux? If only paid solutions exist, what's out there (besides After Effects)?
Pencil 2D
Synfig Studio
OpenToonz (used by Studio Ghibli, no less!)
If you want 3D, then Blender is a fantastic open source tool.
It is in the 1.3.12 release.
There is also this new tool called enve (Linux only): https://maurycyliebner.github.io/
In the process, we've built a tool to autocrop and optimize SVGs so that they are as small as possible and work correctly in Illustrator and all other readers. The tool is open source and available at https://autocrop.cncf.io.