Skip to our site navigation Skip to the content

Responsive Web Design


Episode 126: Spotlight: Val Head

This week we talk to independent web animation consultant Val Head, whose recent book Designing Interface Animation is a must-read.

You didn’t have to be like, “Oh, we’ll do this boring HTML site, or we’ll do this interesting creative Flash site.” We can do them all in one place and we can make it be responsive, we can progressively enhance it, we can even make this animation accessible.

If you’d like, you can download this episode’s audio file. Additionally, you can follow us on iTunes, on Google Play Music, or subscribe to our RSS feed.

Buy The Books

Everything you need to go responsive, in four short books. Save 15% on all four!

Subscribe Now

The podcast may have ended in 2018, but you can still subscribe! If you want the latest episodes, fire up your favorite podcasting app and subscribe via RSS, Google Play Music, or on iTunes.



This Week’s Guest

Val Head

Author, Designing Interface Animation

Val is a web animation expert and author with a talent for getting designers and developers alike excited about the power of animation. She is the author of Designing Interface Animation on Rosenfeld Media and teaches CSS Animation on lynda.com.

Val curates the UI Animation Newsletter, co-hosts the Motion and Meaning podcast, and leads web animation workshops at companies and conferences around the world.


Episode Transcript

Ethan:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, well, I don’t think I’m speaking out of turn when I say that Karen and I are both beside ourselves with excitement, because we are speaking with our good friend, Val Head, who’s an extraordinary designer, developer, and the author of Designing Interface Animation. Val, thanks so much for joining us this week.

Val:

Thanks for having me on the show. I’m super excited to be here!

Ethan:

Like I said, we are excited to have you. For our audience members who may not necessarily be quite as familiar with the kind of work that you do, do you want to tell us a little bit about yourself and what you’re working on these days?

Val:

Lately I’ve mostly been doing a lot of consulting and training and teaching around web animation. I teach a lot of workshops, write a lot of articles, and I have a little newsletter about it and everything. And kind of my secret mission lately is to help web designers figure out how to use animation well so the web can be like this extra awesome place for the best interface design ever.

Ethan:

That is one heck of a tag line.

Val:

[laughs] It’s a small goal.

Ethan:

[laughs] Yeah, no, no, that’s good, set the bar at a modest point, see if you can clear it. But Val, you’re one of my favorite speakers, and I’ve seen you speak about web animation a number of times, but I’ve never really asked you: How did you get started on that path? What is it about animation that really hooked you, and why are you so passionate about it?

Val:

That’s a good question. I first started out with animation way back in the day, I took like an animation workshop that was like hand-drawn cel animation stuff with Flash, and I was like, this animation stuff is pretty cool. I can’t draw very well, but you can make some fun abstract shape things! It was very experimental animations I was making then. And right after the course, I was like, “Hey, I’ve heard this Flash thing can be interactive. What if I wanted to click buttons and make animations play?” and the instructor was like, “Oh, there’s this whole other side to Flash called ActionScript, and you can write code that makes things move around on screen.” And that was sort of like a life-changing moment for me, because I was like, so all of these math classes that I hated, I could’ve been using for animation and no one told me? [laughs] It felt like, that was really something someone should have told me when I was fifteen or something—math class would have been a lot different.

So, I started doing a lot of web design and Flash design and kind of ended up being this weird person in most of the companies I worked for, who really liked web standards and also really liked Flash. Because you were supposed to pick sides, you know? You liked one, you hated the other. I was the weirdo that thought they were both pretty cool. So when we started getting these better tools for web animation and actually being able to animate with CSS, being able to animate really quick, have really fast JavaScript in the browser so we could use that more, that was kind of like combining the best of both worlds for me. You didn’t have to be like, “Oh, we’ll do this boring HTML site, or we’ll do this interesting creative Flash site.” We can do them all in one place and we can make it be responsive, we can progressively enhance it, we can even make this animation accessible, which is a thing Flash could never do well. So, it was just kind of like this perfect storm of all my favorite things.

Ethan:

That’s really great. Since you mentioned responsive, and just in keeping with the theme of the podcast, you’ve spoken a fair bit about how responsive design actually introduces some interesting challenges for doing really effective animation on the web. Could you talk a little bit about that? What are some of the challenges you find in your work?

Val:

Yeah, responsive design makes animation just a bit different. I feel like it’s one of the unique challenges we have on the web. Even though maybe some apps may be designed for different screen sizes, it’s just not really the same. We run into things with responsive design that affect animation both on the technical side and on the design side, which is why I think it’s such an interesting challenge. I did a video awhile back, and actually a talk at Responsive Day Out, on some of the ways different sites had handled large amounts of animation and what they did at the different screen sizes and how they adjusted their animation at different viewports, and it was really interesting to find that there was no one trend. It wasn’t like everyone was just like, “Small viewport, turn off animation, go away!” Some of them pared it down, partly because on that smaller visual stage you could call it, suddenly small movements or two or three movements seems like a lot, but on a large desktop-sized viewport, maybe those seem like almost unnoticeable.

So, a lot of it was a question of art direction as well as technical. There’s definitely some technical things where you’re like, I’m going to move this across the screen, and when the width of the screen changes, you kind of have to adjust that animation because it’s not moving as far, or it needs to move faster or slower to accommodate the actual space it’s in. So, I find it an interesting challenge as it does hit at both, oh, we need to adjust the code at different breakpoints, and also you need to think of it from a design standpoint of are the things we’re animating, do they still make sense in these different sizes?

Karen:

Val, can you talk a little bit about, just in general, why do organizations want to do this? Like, if you’re explaining to a client why they should be thinking about interface animation in this way or perhaps what the benefits would be, how do you explain that?

Val:

I do get that question a lot, especially from people who are maybe used to kind of thinking of animation as just like this extra thing, like this decoration, or the “sprinkles on your sundae” or something—I don’t know, is it too early for dessert metaphors? But animation is really a design tool we have at our disposal that we can use to make things easier to follow. We can use animation to help establish some spatial relationships, or help our users see what’s happening as opposed to guessing what’s happening. You can kind of reduce that cognitive load for them, of being like, “This thing moved from here to off-screen,” instead of like, “This thing just disappeared and where did it go?” So, there’s a lot of opportunity to kind of guide people through an experience or an interface with motion that you just wouldn’t be able to do with other tools, like type and color and hierarchy and all those things.

I think the biggest thing is to realize that it is another tool in our tool box for designing good experiences. It’s not like a magic bullet that’s going to fix bad design. If you have an impossible-to-follow layout with terrible hierarchy, making it move is probably not going to help. But if you have a design that’s already pretty solid, or if you have certain goals that you want to accomplish rather, you can use animation as one of the ways you accomplish those goals, one of the ways you get your message across. Since we have this as an option now that we didn’t before, it just makes a lot of sense to at least consider it. Because the more tools at your disposal, the better chance of creating something that really fits what you want to create, whether that’s the message you want to give or the people you’re making it for, and it gives you an extra chance to stand out and just maybe create a unique experience that maybe we didn’t have before.

Ethan:

Val, since you mentioned art direction earlier, I’d love to hear how you actually work with some of your clients to figure out what those goals actually are. I’ve found that at least in my work, actually establishing a consensus about what really matters to an interface is actually a sizable amount of work. How do you actually get people around the table to start answering that question?

Val:

Getting everyone to agree can be really hard, isn’t it? [laughs] A lot of what I usually work with clients on is usually animation, a lot from the design perspective when we’re dealing with those kinds of questions. I’ll usually start from things like, a lot of companies will either have a brand definition or even design principles that they’ve created for their interface design, or maybe even their print design depending on what the company does, and usually I like to start with translating those to motion. Certain companies are like, “One of our principles is we want to be very simple and clear.” I might prototype some ways that they could create animation that reads as simple and clear. Usually that might be things that just go directly to their destination, like a simple ease-in, ease-out instead of bouncing; something that’s very easy to follow visually and a thing that knows where it’s going and has that confidence and just gets there.

A lot of it’s through prototyping and showing and then kind of bringing those things to, whether it’s design reviews or critiques or wherever the company tends to discuss these things, and then having those discussions with those designers, with whoever else is usually involved in these kinds of decisions, of, “Does this fit? Does this work?” and really guiding the conversation around it. A lot of the time I feel like one of the barriers to using animation as a design tool is knowing how to talk about it. Just like you can’t be like, “I don’t like blue!”—that’s not an acceptable design critique or anything—being like, “I don’t like that animation,” also isn’t. So, I really help a lot of my clients kind of figure out how to talk about it as a design thing and how to evaluate it to figure out if it’s something that’s making their work better, or helping them push their message forward or not.

Ethan:

Are there tools that you find are especially helpful to have some of those conversations? What do you use on a daily basis when you’re talking about prototyping or sketching out motion ideas? What are some things in your tool belt that you find really useful?

Val:

[laughs] I feel like I always disappoint people when I answer this question. because it’s really the same stuff that everyone uses for regular web design things. I usually start, especially if we’re workshopping a thing or trying to have a bunch of people around a table, contributing ideas, I’ll start with sketching, whether that’s on paper or whiteboard, kind of creating these little mini animation storyboards for different interactions or microactions, because that’s a great way that everyone can contribute, right? You don’t have to know any particular software to just draw a little storyboard and be like, “How would this feel? Would this work?” kind of thing. So, I do a lot of that.

After doing the kind of pen-and-paper exploring stuff and sketching, usually I move to some kind of prototype, whether that’s something that’s just kind of a video that plays back, something that’s made in After Effects or something. But a lot of the time I try to actually build the stuff out as a functional prototype in code. I feel like that’s the fastest way to kind of get to an answer, especially because a lot of the companies I work for, they’re web companies, their thing exists on the web. So if I can show them a prototype that’s like a CodePen prototype, that’s animated and maybe I have a whole series of them that we can talk about and actually use and interact with, that’s much more powerful than, “Here, watch this little After Effects video of how it could be.” Having it on the web just sometimes has that extra impact. Depending on the project, I’ve also used things like Framer to make some prototypes, because it’s a nice little contained library for creating interfaces quickly—at least prototypes rather quickly. It’s not really very useful for anything for production in the end, but it works out well for a quick test of things.

So, a lot of the same stuff that all web designers use, like CodePen, Sketch, or Photoshop, a little bit of After Effects and Framer, and then the sketching stuff, which I think is where pretty much every design starts. So, there’s a lot of repurposed and familiar tools for animation purposes.

Karen:

Val, talk to me about how this kind of animation work gets reviewed with stakeholders, with a larger team. Like, how do you think about presenting this work and getting feedback on it?

Val:

Yeah, a lot of that I try to go with what the company already does to talk about design or code. Pretty much everyone has some sort of design review process, whether it’s critiques or maybe like a weekly design team meeting, and they usually also have some kind of similar code review setup. And since I’m usually like the outside person brought in to work with the team, I’m like, “I’ll go with your usual habits.” But you can bring prototypes to a design review or design critique pretty easily.

One approach I take pretty often is to create maybe three prototypes of one specific interaction and apply their design principles with motion to that interaction in different ways. Like I might bring one, let’s say it’s a modal entering the screen—that’s an easy one for everyone to think of—and maybe I’ll bring in one and say, “Here’s one that really focuses on your simple and clear principle, and it invokes that principle by coming in a quick speed but having that ease-in, ease-out, so it just settles right into place. And it has these properties of when you act on it, it exits going downward, and when you dismiss it, it exits going upward,” or something like that. Really much the same way you might discuss other types, like non-moving interfaces. And then maybe I’d bring, to complement that, like, “Here’s one that really focuses more on the friendly aspect, or the high-energy goal that you have for your design, and this one maybe has a little bit of a bounce to it, or maybe scales a little bit, or has a 3D effect to it,” just kind of showing the different ways they can apply these design principles to existing interactions that maybe they’re already animating.

Because a lot of times I get brought in to help people kind of create a system for all their animations. They’ve realized they’ve got, like, forty-five different fade-ins and maybe there needs to be a system to this. I’ve done similar things in code review-type situations too, where you kind of look at the code behind what’s making these animations work and then dig into like, “Are we using the most performant properties?” “Is this going to work with the existing codebase?”—which is always a big question, too. You can prototype all sorts of crazy things, but if the pieces aren’t in the existing components, at least for an existing product, it’s going to be pretty hard to make that happen. So, the code part can often be sort of a reality check of what you can really pull off, or maybe what’s worth changing the underlying code for. If you’ve come up with a really great interaction that’s going to be super effective and is really important to the team, maybe it’s worth adjusting the actual underlying code and refactoring the codebase for that.

Karen:

Val, let me shift gears a tiny bit and ask not just about the type of client work that you do, but some of the teaching and education and workshops that you might do. How do you train the designers and developers of the future to be able to do this kind of work?

Val:

I really like training, it’s probably the most fun part for me. So, I have a few different workshops that I run, some of them are very focused on the UX side of animation and are kind of like “code-free” in the sense that we talk about finding these places where animation can be useful, how to sketch them, how to evaluate them, and how to prototype them with something anywhere from Keynote to Framer, depending on what the team is most comfortable with. It’s amazing what you can get done in Keynote, actually. I’m always surprised by that; people make some things in Keynote in my workshops and I’m just like, “How did you do that? You are so smart!”

And then I also have some more code-focused workshops. I’ve actually put together a special series with my friend Sarah Drasner, where we cover like the code side of web animation. Basically from like zero to sixty we go from your basic CSS stuff, all the way through JavaScript and the TweenLite/TweenMax Libraries, and then we do it all with SVG the second day and kind of teach everyone all the behind-the-scenes code stuff that makes animation work.

Ethan:

Val, since you mentioned performance earlier, I’d love to hear, do you ever have to have discussions with your clients around questions of device support or hardware? How do you actually ensure that some of the animations you’re sketching out deal with maybe devices that are a year or two older than might be ideal?

Val:

Right, performance is definitely a question. I think a lot of the time it can get device-specific depending on what devices people know that their product is used on often and that kind of thing. I feel like everyone has a bit of a shortlist of devices, like, “These are the most important to us and it must work here.” And of course testing is a big part of this, because there are certainly some old Android devices that just don’t have the power to run a lot of animation. Maybe in those cases you have to make some adjustments to kind of use animation in that progressive enhancement stack, where you’re like, “Hey, if you’ve got this kind of device, maybe you don’t get animation or you get a stripped down version just so you can still actually use the thing.” And a lot of the time for just basic web performance stuff too, the properties you animate can make a really big difference in the performance you see even in the most modern browsers. So, a lot of it might be kind of looking at the codebase and figuring out, “Are we dealing with transforms and scales as opposed to animating top and left?” Sometimes even making small changes like that can make a huge difference in the performance that you see.

But a lot of it does come down to deciding what’s important to you and that product, and what’s worth keeping where, if you have a lot of devices that maybe aren’t as capable of handling animation. But also there’s a really big difference between a parallax site with all sorts of bells and whistles and 3D stuff going on, and then some button hovers or small scales on your search box and things like that. So, animation covers such a large range of things. Sometimes you might have no problems at all for performance. Actually, maybe a lot of the time, if you’re just doing a lot of these small microinteraction animations. The difficulty tends to come in some of these larger animations, or things that rely a lot more heavily on animation.

Karen:

Val, this has been such an interesting conversation and I bet there’s a lot of people out there that also wish that they could get this kind of time with you. If you had to offer some advice to maybe a young designer/developer that’s maybe breaking into the field or interested in doing more animation work, what would you tell him or her?

Val:

I think the biggest thing, especially for young designers just getting into this, is kind of developing your own taste around animation, because I think that’s not a thing that gets covered in a lot of web design courses or schools. There’s so many other things to cover, it tends to be near the bottom of the list. But seeking out apps or sites that you think use animation well, and really deciding why you think that animation works well. Is it the way it looks? Is it where it’s placed? Is it because it’s helping you get a thing done? I think being able to recognize those things in other people’s work makes it easier for you to find places to use it in your own work and to use it well.

I think it’s also really important to find some good sources of animation inspiration, whether that’s on sites like Art of the Title is a favorite of mine, because they talk about all these titles for TV and movies, and they just are amazing. Or looking at certain gallery sites, like Use Your Interface, or Capptivate.co, finding inspiration and seeing what other people are doing with motion and kind of figuring out what you think good motion looks like or what you think good animation feels like, because the “feel” part can be the hardest part when it comes to animated microinteractions and doing UI animation. We’re creating animations that people have to interact with and not just watch, which makes a big difference. So, I think really exploring and kind of critiquing what you see, as far as your taste or your outlook on design, what works and what doesn’t, and that kind of judgment aspect of it I think is really key to using it well.

Karen:

That is a super inspirational note on which to end our little podcast here. Val, thank you so much for hanging out with us this morning. It is always a pleasure to get to talk to you, and this was no exception.

Val:

Yeah, thanks so much for having me! It’s always a pleasure to talk to you too, as well.

Ethan:

Thanks to everyone for listening to this episode of a responsive web design podcast.

If your company wants to go responsive but you need help getting started, Karen and I offer a two-day onsite workshop to help you make it happen. Visit responsivewebdesign.com/workshop to find out more and let us know your company is interested.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Thanks for listening, and we’ll be back next week.


Skip to our site navigation; skip to main content