DEV Community: Dakota Sexton

A Brief and Personal History of Animation Approaches I Love

Dakota Sexton — Wed, 19 Feb 2020 03:17:16 +0000

I think choosing whether or not you need another web animation library in your life is a little bit like dating. It’s awkward and hyper personal and a bit irrational. And you might be really hesitant to do something new if it feels like you’ve already adapted your whole life to something like Greensock or plain CSS.

As Bryan Braun’s Bouncy Ball project demonstrates, there are at least 20 different ways to animate a two-dimensional blob on the web. And the funny thing to me isn’t how many options the project documents — but pretty much any single one can be used to move a blob in the exact same way.

If the bouncy ball test parameters were different — if there were hundreds of moving blobs, each with its own independent velocity, and some form of randomness that contributed to entirely different motion paths for each individual ball — there might be a more clear winner.

More than likely, the winner would be canvas: because a website can get pretty dang slow when countless nodes that are a part of a DOM tree are moving in a million complex and continually-evolving ways. (And this is especially true for mobile users!)

But web performance aside, it’s not always so easy to delineate what does or doesn’t make sense for a creative project. Your mileage may vary, and you may hate the things that I love.

So this is more or less just an abbreviated history of my personal experience with different approaches to web animation.

GreenSock

You always remember your first love, right? This one was mine. It’s commonly referred to as GSAP, and I discovered it the summer I quit my career in publishing and began dreaming of doing weirder, more creative things.

The first weird, creative thing that I discovered built with it was definitely the homepage for Mild Bunch, a coworking space in Bristol, which seamlessly blends gifs into GreenSock-driven animations.

If you’re patient and watch for it, you can catch several different events unfold: including a hot air balloon that drifts away, a flock of birds, a dog walker, a child on a scooter, and a cyclist.

Carefully sequenced, animated timelines like this are often what GreenSock is known and loved for. It can also animate html elements along bezier motion paths; morph between disparate shapes; normalize browser quirks; and a swiss-army-knife oddity of other tasks.

d3

Learning d3 came next for me, and it initially made a lot of sense. It’s an open-source tool and ubiquitous to online data visualization. And after several years in print publishing, using it to pivot my career into more interactive forms of journalism felt like a somewhat happy accident. Like tripping on the sidewalk in a romcom and accidentally discovering your one true love.

Except, d3 probably isn’t it for me. When I tried to learn it, I was still struggling with basic Javascript fundamentals. I couldn’t manage to do much without adding an additional charting library on top of d3. I’m also still not sure I enjoy charts as much as I just inherently feel like I should.

But d3 is a powerful thing that can definitely be used creatively — and an excellent example of that is A Visual Introduction to Machine Learning.

If you’re interested in learning more about the interaction design theory behind it, Tony Chu gave a talk about the project at OpenVis Conf called Animation, Pacing, and Exhibition.

CSS

If I can carry on the whole weird theme of comparing romance to web animation without losing too many readers, how I feel about CSS animation is nothing short of intimate and intense best-friend love. The kind of love embodied by Abbi and Illana on Broad City, or even moreso by Amy and Molly of Booksmart —

Because this is a very nerdy kind of joy. And there’s something wildly pleasing about being able to draw or even hand-write simple svg shapes (or even just divs) and then animate them with css transforms.

Lynn Fisher’s A Single Div project captures much of how silly and wonderful of a style it can feel, with only (as the name implies) a single div and a bit of CSS.

Framer Motion

Sometimes you want to be challenged, and for me recently that’s involved learning Framer Motion. Which isn’t to say it’s difficult to use: the React animation library has a simple, declarative syntax that’s convenient for one-off animations and yet still flexible enough for more complex orchestration.

I’ve been most excited the past few months about how simple it is use asynchronous callbacks from my own custom hooks — written with web platform APIs like Intersection Observer — to affect the state and velocity of a scroll-based animation.

I’m also really excited to experiment with features that include gesture recognition and an accessibility-focused hook called useReducedMotion, and some of the more creative applications of spring and inertia-driven animation.

Which is probably just to say, in the parlance of an old Hollywood talkie, if you’re a creative soul with a penchant for React, I think Framer Motion is nothing short of a fast-talking Bette Davis: a no-nonsense, dependable dame with impeccable wit.

WebGL / Canvas / three.js

I repeatedly ignored these approaches to animation for years before taking a class with Matt Deslaurier last fall on AdvancedWebGL and Shaders at Frontend Masters. Not necessarily because I didn’t think canvas or the 3d applications of Three.js were interesting.

I was mostly just super intimidated.

And I didn’t realize that it was possible to use everything I knew and loved about frontend web development and apply it to in-person, interactive installations — not until meeting Deslaurier and discovering he does just that with projects like N Dimension.

I'm probably going to be in a very shy, staring-at-my-crush-from-behind-a-bush kind of love with this for a little bit, but I've always wanted to experiment with mixing generative design with interaction.

So with any luck, this might just be the accountability I need to pursue it.

Avoiding Common Web Animation Mistakes

Dakota Sexton — Mon, 10 Feb 2020 06:08:42 +0000

I love experimenting with web animation. It doesn’t take much, or even any, boilerplate to get started (especially with tools like Codepen and CodeSandbox). And whenever I’m frustrated or overwhelmed by the looming complexity of web development, spending an afternoon drawing and animating abstract boxy things often reminds me of the childish excitement I had when I first began experimenting with code.

But there are other times — much more awkward times — when I throw around lots of big numbers I don’t understand, or just don’t feel very confident about what I’m doing. And then it feels like studying up for the once-a-year opportunity in which it’s possible to try to impress an accountant with my fundamentally incorrect understanding of how capital gains tax works.

In hopes of making web animation a little less like that, I’ve decided to catalogue a few common mistakes.

Accidentally merging paths

This typically happens when I create illustrations in Sketch or Illustrator and then accidentally go too far with svg optimization.

To optimize my files, I often use Jake Archibald’s open-source SVGOMG (which serves as a visual interface for svgo) — and generally love it. It provides a really convenient way to understand how individual optimization settings might affect the visual output of your illustration.

But one thing that I wish I knew sooner was that some optimization tools (including SVGOMG and SVG2JX) merge shapes into as a few nodes as possible by default — and that’s the last thing you want if your goals for an animation include some form of staggered or overlapping orchestration of multiple elements.

Thankfully, the fix for SVGOMG is uncomplicated. Make sure “merge paths” is not toggled in the right-hand sidebar of the UI. Then double-check the output of your code to verify that any optimized elements are still output in the quantity you expected.

Not removing transforms

Some pretty flicker-inducing or otherwise funky things can happen if you try to animate an illustration with transforms embedded somewhere within its inline svg syntax.

If you’re familiar with CSS transforms, the syntax might look vaguely familiar:

<polygon transform="translate(65.074074, 14.500000) rotate(-180.000000) translate(-65.074074, -14.500000)" points="65.0740741 0 91.1481481 29 39 29"></polygon>

Sketch and Illustrator commonly export shapes like this if they aren’t flattened. Which isn’t necessarily bad for static icons. But if unchanged, the above polygon will animate from its initial origin point, not the position it appears at.

You can avoid the funky mess in two ways, of varying simplicity:

Duplicate an artboard containing the final illustration and flatten each of its shapes before export.
Use Figma for image optimization. Its svg export option was built with human readability in mind, and will output as few bits of crufty code as possible. That includes removing transforms, and outputting simple shapes (such as rect and circle elements) whenever possible — instead of more cryptic paths. You can read more about it on the Figma blog.

Adding unintentional horizontal scrolling

Superfluous horizontal scrollbars and the awkward additional space that accompanies them can pop up on otherwise-responsive websites for plenty of reasons. In the context of illustration and animation work, I’ve repeatedly caused accidental overflow in two ways:

Sometimes, just by adding an explicitly large inline svg (with a width of 1440px) to a webpage and forgetting to define CSS for how the image should scale at smaller sizes.

For less complex situations, this can usually be fixed by defining a global rule for all images that prevents them from busting out of the bounds defined by a parent container:

img, svg {max-width: 100% }

Note: this is a pretty nuanced topic. A more in-depth take on the issue is the CSS Tricks guide to scaling svg.

Other times, the size of an svg is not the problem. Content overflow can also be caused by animating individual shapes to — or from — an off-canvas portion of the webpage. To make sure shapes stay hidden (and don’t unintentionally increase the width of your website), make sure to define the overflow property of the svg or a parent container.

.generic-element { overflow: hidden }

Adding unintentional layout thrashing

This isn’t much of a bug. It’s really a performance concern, and one that you’ll want to keep in mind when strategizing the overall vibe or narrative direction of a specific project.

Layout thrashing is a common side effect of introducing too many drastic changes to a website at once, or attempting to change the explicit computed size or position of an element.

If you’ve ever scrolled a website that suddenly became unresponsive at a certain point — or continued to scroll, but only with an uncomfortable level of jank — you’ve experienced layout thrashing. To avoid making it happening because of web animation, you’ll want to focus on animating the opacity and the transform properties of an svg or other html element exclusively.

There are caveats to this rule — most notably, the will-change property, which is intended to help browsers mitigate future performance costs. But keep in mind that will change is recommended by the MDN web docs only as a last resort, not necessarily a point of entry for creative coding.

To improve the performance impact further, you might also want to consider how many animations need to be introduced to a webpage at once. Does an animation need to loop indefinitely? Or should it only trigger once, when visible within the viewport?

That might be an ideal use case for introducing Intersection Observer.

A More Creative Approach to Learning Git

Dakota Sexton — Sat, 01 Feb 2020 15:08:16 +0000

For me personally, learning git has often felt like struggling to swim. Without knowing much, I’ve generally been able to get to where I need to go. But sometimes only with an awful lot of awkward splashing, second guesses, and unnecessary panic.

And if you’re anything like me, surviving even just one or two botched attempts at a git merge can make you question if you’re the only human who struggles with command-line tasks — and the awkwardness can be amplified by unsuccessful attempts to understand the super-technical nature of git’s documentation.

So when I had an opportunity to teach other creatives about git earlier this year, I started experimenting with a slightly different, analog approach. It involved sandwiches.

But why sandwiches

A very kind senior developer once told me that learning how to solve new problems with code is a lot like writing a recipe for making a sandwich. He was totally right: and I think the concept applies to any form of cooking. Even if you don’t understand how to recreate the fluffiness of a buttermilk pancake without flour or dairy, you can still typically begin to strategize the individual, discrete steps that might push you in the right direction.

But less seriously, I’m mostly just nostalgic for a good grilled cheese.

Sandwich blogging for beginners

If you were to write down the necessary steps to make a traditional bánh mì, you might include a lot of short, concise instructions in the present tense. Like “buy sourdough baguette” or “add pickled carrots.”

Maybe all of your friends and followers love fermented food, so there’s no reason to ever blog about why exactly anyone should add pickled carrots. And working with git is pretty similar — you can make a series of decisions about your code, and then choose to write simple, self-explanatory messages about each one without additional explanation.

Sometimes, of course, there’s a significant reason for choosing one particular sourdough baguette over another. So you write down “buy sourdough baguette” and then in a sub-section beneath that heading, elaborate on why you think the sourdough baguette from a small bakery in Northeast Minneapolis has no comparable alternative, because all other attempts at a sourdough with a large, amorphously blobby crumb structure are unfortunately just garbage and not suitable to the demands of this particular sandwich.

Other times, you’ve made preventative considerations for commonly occurring problems — like the scourge of a soggy sandwich.

Part of the magic of git for me is that it provides individuals with a structured way to handle all three of these situations, by allowing individual contributors to annotate changes in the heading, body, and footer sections of a commit message. Even better, platforms like Github can automatically parse — and link — these comments to relevant discussions and feature-specific issues.

Collaborative sandwich arts

Sometimes you need to get inspired before you can even commit to making a sandwich, much less write about it. So you spend an hour watching videos from the Bon Appétit test kitchen to get into an experimental mood, and eventually end up copying down a recipe for a seemingly great grilled Halloumi sandwich from Montreal’s Dépanneur Le Pick-Up.

After you write the recipe down, you delete certain steps that don’t make any sense. Like, Halloumi gives you mad gas. But maybe you could replace it with a nice garlicky cashew cheese? You’re also one of the unfortunate humans who think cilantro tastes like soap. But you have some parsley about to wilt in the fridge, and that might be nice. And your initial dose of hot sauce was just not quite sufficient enough — three separate times.

Cooking is full of this type of experimentation, and it feels like the perfect parallel to git’s interactive rebase features — which make it easier to delete, combine, or re-arrange commits in your existing git history.

I didn’t love using git’s interactive rebase until a couple years ago. I thought if I tried rebasing frequently I might just end up screwing up all the time. And I wasn’t sure how necessary it was, in the same way in which coloring outside of the lines of a given recipe can feel like too big of a risk.

But rebasing your commit history can help provide a cleaner, more linear narrative for your code. That might make it easier for others to read in code reviews, or even easier to debug in the future — when and if you’re faced with digging through multiple commits to find where exactly a certain bug was introduced.

Insert your own sandwich jokes, please

I’m sure there are plenty of other silly things that can be said about sandwiches and collaborative coding. These are just a few, and I’d welcome anyone to add their own.