CSS Animation, and Creating Art with Code, with Rachel Smith

In this episode of the Versioning Show, Tim and David are joined by Rachel Smith, a front-end developer at CodePen. They discuss creating art with code, learning the skills of animation, the future of animation on the web, and being limitlessly creative with code.

Show Notes

• Rachel Smith on Twitter: @Rachsmithtweets
• CodePen
• Rachel on CodePen
• Rachel’s CodePen blog
• Rachel’s blog post on “lerping”
• RachSmith.com
• Rachel’s GitHub AMA repo
• @mpjme
• FunFunFunction
• FunFunFunction on the question Is Programming Art?
• Framer
• More Twitter links: @mdavidgreen | @tevko | @versioningshow | @sitepointdotcom

Transcript

Tim:

Hey, what’s up, everybody, this is Tim Evko …

David:

… and this is M. David Green …

Tim:

… and you’re listening to episode number five of the Versioning Podcast.

David:

This is a place where we get together to discuss the industry of the web from development to design — with some of the people making it happen today and planning where it’s headed in the next version.

Tim:

So today we have with us Rachel Smith. So Rachel, thank you so much for joining us! Do you want to give us a quick intro for those of us who do not know you?

Rachel:

Sure, my name’s Rachel Smith. I’m an Australian web developer who lives in the US in California, and my day job is with CodePen — helping build the app that is CodePen.

And I’m mostly a front-end developer, but I also do a little bit of back end, and I have sort of a hobby in building art with code.

David:

Yes, and we’re going to be asking a lot of questions about that hobby. But, before we get started, we want to ask you our philosophical Versioning question. In your current career, what version are you, and why?

Rachel:

Oooh! [Laughs] In my current career, what version am I? I would say the best version! Where I am in my career right now is kind of a place that I’ve been working towards for a while now. And this job, working for a product that I really believe in and really enjoy — being able to make that better — is kind of like my dream job scenario as far as my career is concerned.

So, yeah, that’s the version.

Tim:

I have to say, that’s probably the best answer we’ve gotten so far.

Rachel:

Oh, really? That’s good! [Laughs]

Tim:

Everyone picks a number, and goes through this “I was version 0.0 here …” You were just like, “No, best version right here.”

Rachel:

O, right! Let’s say latest, best, stable. [Laughs]

Tim:

Sounds good.

David:

Stable is something we can all aspire to.

Tim:

So, speaking about creating art with code, it’s very interesting you mention that, because I was actually watching a YouTube video today. It’s by @mpjme I believe? (I may have butchered that.) But he does FunFunFunction, and every Monday he kind of releases a new video, and today’s topic was art and code related.

So, on the heels of that, do you want to go into a little bit more about how you create art with code?

Rachel:

I like to see code — especially front end technologies — as an avenue to create visualizations that you dream up, as well as there being a practical function for it.

I think, in the front-end sphere, we kind of obsess over whether things are necessary or practical, or what’s the best solution for a certain front-end problem. But I love it when people break out of that and use code purely as a form of artistic expression. So personally, I like to use different kinds of technologies to create different visualizations, I guess, and to explore those technologies and the effects they can create on the screen.

David:

It’s a fascinating direction to take your work in. A lot of people who do coding can relate to that notion that it feels like an artistic process. What got you started with thinking about code as art?

Rachel:

I started building animated stuff out of necessity, because my career started in making Flash banners, basically for banner ads to advertise certain services in Australia.

It was usually like lottery banners actually — trying to sell lottery tickets — because gambling is a huge industry in Australia. So we’d make these banners that were crazy, animated, jump out at you, to try and get people to click on them. And that was with Flash.

And from there, I fell in love with motion design on the web. And that led me into an area where I can appreciate the abstract use of animation with — I don’t use Flash any more, but I sort of took that approach into using HTML, CSS, JavaScript to build these weird, pointless things that are pretty to look at.

David [4:24]:

I know the technology for doing that changes rapidly, and you’re already taking us all the way back to Flash, which gives me some flashbacks as well.

But what time frame did you start shifting into HTML, CSS and JavaScript for this, and how have you seen that changing?

Rachel:

I guess my first foray into doing non-Flash animation was via CSS3 and also canvas. So it was probably around the time that HTML5 was a massive buzzword, so I’m just thinking when this would have been. It would have been the end of 2011 and 2012, I think.

And this was when CSS3 and CSS animations were coming into more mainstream front-end practices, as well as HTML5 Canvas API. So that’s when I started exploring those options. In 2012, I was working as a contractor in London, and I happened to take on a couple of contract jobs in the advertising realm, where they were requiring a lot of HTML5 animation, but they wanted it to work on iPads.

So we were forced to do away with Flash, and really try to push the boundaries of what HTML5 technology could do. And then we ran into a lot of roadblocks and it was really hard to make anything look good with a good frame rate. And I think the main thing that’s excited me since then — since 2012 — we’ve seen a huge growth in capabilities, as far as what the browser rendering engine can do and what it can do with these animation technologies.

And it’s just such better performance these days, and what you’re capable of doing — like building entire 3D environments and animating them with technologies like WebGL, which now works as far as your mobile devices —that is super exciting to me.

Tim:

So one of the things that I really enjoy about your work is that it always seems so simple the way that — especially in your CodePen blogs — you kind of break it down and explain the types of things that you’re doing.

In fact, one of your blog posts that I have bookmarked is lerping, which was a really cool subject for me to learn about. But speaking about that, I feel like a lot of people — myself included — are intimidated about the advance of JavaScript animations, because some of these are like 400 lines long of code.

So how did you make that transition from CSS animations — which some people see as a little bit less complex — to these full WebGL and 3D environments?

Rachel:

I had a sort of fortunate experience in my work within the advertising industry. I was able to work with and meet a bunch of extremely talented folks who just live and breathe this sort of hardcore animation stuff.

And through working with them, I was able to get into learning more advanced JavaScript animation, and certainly work on it myself. But it is hard to teach yourself when you don’t have someone who’s more senior than you in that topic. So, I definitely had a lot of help from the people I worked with.

But unless you’re in those agencies, working with those people, you really don’t get exposed to that information, because the advertising agency world is typically very closed, and they like to keep their cards close to their chest as far as their knowledge sharing. And it makes a lot of sense, because it’s an extremely competitive, cutthroat industry.

And there’s a lot of copying, and your ability to create technically impressive projects is sort of the reason people would hire you. So you wouldn’t exactly give that information away. But the shame in that is that there’s so much innovation being made in web rendering, but it’s not really being shared. And I just felt I wanted to take a little bit of that knowledge, break it down to a beginner level, and just share it with everyone.

Because the stuff that I write about, you’re not going to be an expert and suddenly making award-winning websites. But, it is an introduction that might make things seem a little bit more approachable for beginners. And then they won’t feel as intimidated heading into advanced JavaScript animation, if they see it’s like a process of smaller steps along the way.

David [9:04]:

Yeah, the CodePen examples are fantastic, and they break things down, and your code is always very clean and very well commented and easy to follow. It’s hard to find good examples sometimes out there, and I’m curious where do you direct people when they’re interested in learning more about this, if they don’t have the opportunity that you have to work with more advanced people?

Rachel:

There’s a couple of books I usually recommend as far as JavaScript animation goes. They’re usually my go-to recommendations. I feel like the most important thing that I share with people is that you can take some of my beginner resources and read them. And then possibly find more complicated projects on GitHub, where people have shared their code.

But this kind of work, the most important thing you can do is just practice, and try and build your own things. And constantly just mess around with it and play around with it, because you can read all you want on these things, but you’re only going to get better — particularly with animation work — if you try and build it yourself, and find your own style, and find your own way through. Just practicing, and making silly things that don’t have to be some grand vision, but just messing around with it and having fun with it. Because it is art, after all, that is the most important part.

David:

I like that you recommend people not really worry about cross browser compatibility issues to start with, but just go in there and experiment.

Rachel:

Yeah, so I feel like the way we’ve been taught in development is often to search for the best way to do something — scour the internet, and read until we’ve found the most efficient solution to a problem.

But I feel that this sort of stuff — the way you achieve it, or obsessing over achieving the best way to learn something — isn’t the way to go about it. Stress less over implementation details, and just try some stuff out and see what is the production of that, and iterate on it. Don’t stress out over the best way to learn canvas, or the best way to learn WebGL. Learn it in a way that works for you, and helps you create the art you want to create.

Tim:

That’s very cool, and extremely sound advice.

So, you mentioned earlier CodePen, and that being sort of a dream job for you, which definitely does sound amazing. Can you talk a little bit about the type of work that you do there? And how you find art in that, and what the typical standards are for the types of interactions that you build?

Rachel:

Yes. So my work for CodePen is actually kind of funny — in the way that I don’t have a lot of creative freedom in my work on the CodePen app itself, because it needs to be a very usable website. And it needs to be usable in the sense that CodePen is sort of just like the shell, or the provider, for our users to do really exciting, creative things. So, we don’t want to try to do our own fancy stuff with CodePen itself — because you don’t need the website UI competing with the content.

If anything is going to be hogging browser resources to animate, it should be the content, rather than our site. So, I feel like with my CodePen work, it’s very functional and I have to leave my ego at the door and just focus on providing the best user experience.

But that is still my dream job, because in building this app, and making it the best kind of app we can, we are providing a space and community for people to create this really exciting fun art — which I happen to get to stare at all day while I’m working on the site.

So that, for me, is still my dream job, even if I’m dealing during the day with very banal things like form elements and fixing little UI bugs.

David [12:55]:

I’m curious, are there any special challenges to working on a site that is intended to feature other people’s codes and other people’s projects?

Rachel:

O, so many challenges! When you’re letting people run code on a site, there’s obviously a lot of security issues — which I’m definitely not qualified to solve, but the other guys I work with have done a great job at dealing with those issues. But the challenge we run into a lot is, because our users are really pushing the boundaries with browser rendering capabilities — which is awesome, it’s so great — you can have a situation where, if you have eight iframes on a page, and they’re all attempting to do some crazy CSS animations, that could cause the browser to slow down. So, that’s something we’re always aware of, and that’s a constant thing we have to mitigate against.

Tim:

Yeah, that definitely sounds challenging, and I can’t imagine having to think about all of those things while building something that still works well for people who are trying to build inside of it. That’s intense.

Stepping away for a second from animation, are there other things that you typically enjoy working on, any side projects, things like that?

Rachel:

As well as animation, I enjoy anything to do with data design. That’s really interesting to me, whether it’s data visualization or even just organizing data — so it can be used in an app. That is very interesting to me. I also love anything to do with typography: motion with type is my favorite, but really I just love anything hand lettered as well.

So they’re also side interests of mine.

David:

It sounds like you come at your front-end work with kind of a design background as well as a development background. Do you have a background in design?

Rachel:

I did actually study some design, when I went to college the second time (because the first time was a bit of a failure).

The second time I went, I decided I wanted to be a web designer, and this is because the first time I went, I thought I was going to be a software engineer. That didn’t go so well, because it was just too “engineering slash back end” to maintain my interest — because I’m sort of a very visual person, but I enjoy the logic.

And when I went to study web design, I didn’t realize at the time, there was a whole front-end world where you could use your design skills, but also programming skills. And it was during that web design course that we did some intro to HTML, CSS JavaScript stuff, and then I was like, “Oh, this is what I like, what I should be doing.” So …

David:

That’s exciting, and it’s great when you discover something like that.

Rachel:

Mm-hmm.

David:

It brings up an interesting question, because the interface between designers and front-end developers is always a challenging one — especially when you’re getting into things like animation and motion design. I’m curious if you’ve come across good solutions for working with designers on animation and motion design for front-end development.

Rachel [16:00]:

I think the space for this sort of thing is growing, as far as the tools that people can use to prototype design. And specifically for designers to prototype design work, so they can work with their developers. There’s a couple of tools; one that comes to mind is Framer. That allows you to write quick, animated design prototypes without having hard-core dev skills.

So there’s these tools that are sort of bridging the gap between traditional visual designers and developers who are able to do the coding. It’s still a very difficult problem to solve, though. Animation brings in a level of complexity that is just so much harder to communicate than just static comps — that we were designing with for the last ten years or so.

So I think a lot of people are working on solutions now to help in that space, but I don’t think we’re 100% there yet with making that an easy transition from motion design to development.

Tim:

In my job, I work on an ecommerce site. That’s definitely something I find we struggle with — between getting a typical Sketch file, or a Photoshop document, and then this intermediary state: what are the interactions? And at times there are layer comps, or videos, but there’s always this difficulty with how you translate the actual feel of the thing that you’re working with. So I definitely understand that there.

Rachel:

Yeah, it’s a very specific skill set, and — because of how new it all is to all of us — I don’t think there’s a huge amount of people who are an expert in that skill set. Because traditional motion designers are very good at motion design, but just because you are good at motion design doesn’t mean you can design motion for interactive interfaces — because that’s like a totally different thing, as opposed to just sitting and watching something animate in front of you.

Having an interface animate has totally different requirements. And as developers, we haven’t had these animation technologies around for super long, so we haven’t had much time to sharpen our skills on how to even make this stuff work. So it’s hard, and I think it’s going to take some time for us all to find our way with this. But as long as we’re trying, I think within a few years we’ll be seeing some really polished animated interfaces coming out of it.

David:

Yeah, it’s a very exciting time, and it’s definitely at the cutting edge of what we’re trying to work on right now. So I’m curious, how can people find you online and get in touch with you?

Rachel:

Probably the best place to find me is on Twitter. I’m pretty active on Twitter, and my Twitter handle is @Rachsmithtweets.

You can find me on CodePen obviously, codepen.io/RachSmith. I also have a website, RachSmith.com, but I don’t really publish much on there, because I put most of my blogging on my CodePen blog. I also have a GitHub “Ask me anything” repo, which is a great place for anyone to send in a question they want to ask me. I do get email, and I tend to be really bad at email and not reply. So, if you anyone has a question, I do have a GitHub repo that’s good for that.

David:

Fantastic. We’ll definitely put links to all of those in the Show Notes, and thank you so much for joining us today on the Versioning Show.

Rachel:

Thank you for having me!

[Musical interlude]

Tim:

So that was definitely very interesting. One of the reasons I wanted to have Rachel on the show is because of how great she is at putting out such clean code and easy-to-digest-and-understand demos. What did you think, David?

David:

I was really glad that you invited her, because I wasn’t familiar with her work beforehand. But now I am addicted to her CodePen demos. They’re so much fun. You can go in there and tweak and twiddle, and she’s got such great visuals and tips about how to use motion, how to use easing, and it’s so much to learn from.

Tim:

Yeah, it really is. Definitely great resources there. I also thought it was interesting — and this isn’t necessarily something that I hear talked about every day, but — there really is a gap between development and design when it comes to thinking through and creating complex visual animations. Have you ever had to deal with that before? If you have, what did you do to get around that space?

David [20:22]:

It’s a teeth-gritting kind of a situation. I’ve had to deal with it unfortunately a lot. I’ve worked at companies, and I’ve consulted for companies, that have been trying to put their interfaces online, at the very cutting edge of what the browsers are capable of. And that crossed over from, “Are we going to do Flash?” to “Are we going to do CSS?” to “Are we going to use JavaScript for our animations? What’s the most efficient for the users?”

And then trying to get designers — who, first of all, might only be used to thinking in terms of static content — thinking about not only how animation would work on their own desktop devices, but also how to translate that into something that makes sense for a user interface.

It was a difficult transition for a lot of people, and I agree with Rachel, the tools just are not really there yet for designers to communicate their theories about how they want something to work and interact effectively — even those designers who understand how motion graphics work in a web interface to communicate concepts.

Tim:

Yes, it’s ironic, because at my job, one of the main ways that we try to communicate these interactions with each other — between development and design — is by sending around CodePen demos. Which is kind of funny, because there’s one for everything, down to, “I wanna click this search icon SVG, and have it turn into an X. And what does that look and feel like?”

But CodePen is great for at least a piece of reference material. And if you don’t have something like that, then my next go-to is just to sit down with a designer and say, “All right, what were you thinking? Let’s prototype this out together.”

David:

Sometimes it really does take a pair programming situation with the designer and a developer to make it happen. One of the challenges when you’re sharing things with CodePen, for example, is designers who may know exactly what they want to happen visually, but are not actually developers; they’ll be forced to learn how to write just enough bad code in order to get something looking like they want it to look.

But it’s prototype code, and the confusion about whether or not this is “done” — versus actually “ready for production” — is something that engineers need to keep on top of when working with designers.

Tim:

Careful — that unfinished code thing you mention sounds dangerously close to what I do every day! So …

[Laughter]

David:

Hey, I have faith in you. I know that you’re looking at the overall production quality code issue.

Tim:

Well thank you very much. But yeah, there’s something to be said there, and it’s almost like there’s a book or a really good talk just waiting to be written about working on sharing difficult animation sorts of work between development and design. And I, for one, would love to see somebody step forward with some creative solutions to that problem.

David:

Maybe somebody who can communicate as well as Rachel does.

Tim:

I think so. We should at least strongly hint that we believe Rachel should write a book about the solutions!

David:

Yeah, and everybody knows how to get in touch with her now, because it’s all in the Show Notes for this episode.

Tim:

Yes, sorry Rachel, we may have just given you a lot more work to do.

[Laughter]

David:

Well, it doesn’t seem like Rachel minds that sort of thing. I love that she’s so active about sharing information and educating the community. And just reading through the questions in her AMA, it’s wonderful to see the nuggets of solid wisdom that come out in that.

Tim:

Yeah, that was another interesting and creative thing, the GitHub AMA. I would love to see more leaders in the industry do things like that — people like Paul Irish, John Resig, Chris Coyier, for example. I think there are a ton of questions a lot of us have to ask them, specifically because those are the types of people who have taught us most of what we know about.

I mean, for myself for example, most of what I know about JavaScript and browser performance and CSS comes from those three specifically, and it’s a good thing to do. I’m definitely thinking of copying that myself. If there’s anything anybody wants to ask me — I don’t know.

David:

I’m sure that there is, and I like the way that Rachel positions it. She says she’s bad at email. I don’t believe that she actually is, but it’s a great way to have a place to point people when they email you a question.

You can say, I’ve already answered that, and here’s where it lives. Or, if you haven’t, you can put it up there and the next person who asks, there’s a place where they can go and look for that answer.

Tim:

Yes, definitely. An excellent solution.

David:

Cool. Well, I think this was a great episode, and I’m sure that our listeners learned a lot from Rachel.

Tim:

Yeah, I certainly did.

---

Thank you you so much for listening, everybody. We always enjoy getting to talk technology with all of you.

David:

We would also like to thank SitePoint.com, and our producers, Adam Roberts and Ophelie Lechat. Please feel free to send us your comments on Twitter — @versioningshow — and give us a rating on iTunes.

Let us know how we’re doing.

Tim:

We’ll see you next time, and we hope you enjoyed this version.

Frequently Asked Questions (FAQs) about CSS Animation and Coding Art