CSS Animation, Prototyping Tools, and Sources of Inspiration, with Donovan Hutchinson

By M. David Green , Tim Evko
We teamed up with SiteGround
To bring you up to 65% off web hosting, plus free access to the entire SitePoint Premium library (worth $99). Get SiteGround + SitePoint Premium Now

CSS Animation, Prototyping Tools, and Sources of Inspiration, with Donovan Hutchinson

In this episode of the Versioning Show, Tim and David are joined by Donovan Hutchinson, a developer, teacher and proprietor of CSSanimation.rocks. They discuss how teaching and speaking can help you learn, solving user problems, CSS animations and accessibility, bridging the design and development worlds, prototyping tools, browser compatibility, sources of inspiration, making whooshing sounds, and designing UIs for cats.

Don’t forget to check out Donovan’s Animating with CSS course here on SitePoint!

Show Notes

Conversation Highlights

I remember spending evenings trying to model my guitar or different parts of my house in the Amiga, and then leave it on overnight to render, of course.


a very inspiring CTO at a small startup … convinced me not just to try the new technologies and to embrace this interesting stuff that was going on in the web, but also to write about it.


I had just begun reading about Angular. He suggested I should go give a talk about it at the end of that month at a local meetup. I had no idea I could learn enough to give a talk on the subject in just a few weeks, but it worked out, and it really showed me that taking the time to properly understand something enough that you could teach somebody about it is a great way to thoroughly understand something and appreciate it — much more than just using it on the surface.


Where it all comes together for me is combining an interest in how things look and feel with how they’re built. And, for that, CSS kind of sits nicely in the middle there. It can be frustrating at times, and sure CSS is what it is, but it’s a great way to express layouts, and to understand the point at which people actually use our software.


I certainly don’t let the older browsers dictate what can be done with the new features.


Often, even subtle animations can distract people to the point where they literally can’t even use the application anymore, because the movement is stopping them from getting past that part. We have to be very mindful of that, in terms of when we use animation, and when we start and stop and turn off animations when we want people to concentrate on something else.


The main two properties that animate extremely well are transform and opacity, which deal with things like position, with scaling, skewing objects, and dealing with how transparent or see-through they are.


prototyping tools really help people communicate ideas.

CSS Animation, Prototyping Tools, and Sources of Inspiration, with Donovan Hutchinson

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 29 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 are talking with Donovan Hutchinson, who is a developer, teacher and proprietor of CSSAnimation.rocks. So, we’re gonna talk to him about development and teaching, and CSS animations. So, let’s go ahead and get this version started.

David:

Hey, Donovan, how are you doing today?

Donovan:

I’m great, thanks.

David:

Good. Thanks for joining us on the Versioning Show.

Donovan:

It’s a pleasure. Thanks for having me on.

David:

Cool. So, since is the Versioning show, and we’re talking about the philosophy of web design and development, we always like to ask our guests a philosophical question. Your philosophical question today is this: in your current career, what version are you, and why?

Donovan:

Wow. Okay. I’d say, gosh, it’d have to be version three or four at this point. I’ve gone through a few different stages in my career to get to this point. It all began back in the late 90s when I was introduced to my first Amiga, and started using it to create, at the time, music and 3D graphics, and find myself using computers to create stuff … which, very quickly when the web took off, became a job on the web. For a long while there, I was what you might call a webmaster — which used to be a thing, before it became more of a developer. Then these days I’ve stepped across into more design. I guess that bridge between design and back-ends that people call front-end development.

David:

Yeah, front-end development tracks a lot of us, I think, but I also have fond memories of my Amiga days back when I was starting out. Nowadays, I think you can emulate one in JavaScript, can’t you?

Donovan:

I believe I’ve seen something like that, yeah.

David:

So, I can understand going from Amiga to going to front-end. Did you always have an interest in the visual side? You said the audio was what attracted you to the Amiga in the first place.

Donovan:

I guess it was a mixture of things. When I really got into it originally, I used to create — or maybe copy — games from magazines into my ZX spectrum, and type them in one word at a time. It was really the ability to make something and then see the results. Or, in the case of audio, to make something and hear the results. The process was just as interesting to me regardless. So, when it came to audio, I loved collecting samples. I used to record hours of radio, and cut it down into small samples, and use that to make music. But, at the same time, 3D software was becoming a thing at the time, in terms of mass-market use. You could get free trials of quite powerful software on the front cover of a magazine at the time. I remember spending evenings trying to model my guitar or different parts of my house in the Amiga, and then leave it on overnight to render, of course.

David:

How did that lead you to web development and design, and particularly this front-end work you’ve been doing?

Donovan:

I guess, initially, it was a place to share what I was creating, and being able to create a web presence then was part of sharing the music I was writing. I created some websites that shared the music, and then discovered mp3.com and used that. But the process of sharing a separate interest, in terms of making music on the web, got me interested in actually the mechanisms of building websites themselves. That branched across then into building for the web, rather than just using the web as a means of sharing.

David:

Was the web the first way that you tried sharing when the idea occurred to you, or were you sharing in other ways before that?

Donovan:

We used to go around parties with cassettes. That was generally the way you’d share at that point.

David:

So, the audio work led to sharing, led to the web, led to getting involved with people. Then at some point, you started teaching as well.

Donovan:

That’s a more recent thing for me, and definitely something I’m very into at the moment. I guess it started maybe four or five years ago, when I was lucky enough to work with a very inspiring CTO at a small startup who convinced me not just to try the new technologies and to embrace this interesting stuff that was going on in the web, but also to write about it. That got me, in a way, learning things better, because in order to write about something, I had to better understand it. Then he actually urged me on to giving talks on the topics as well. For example, I was learning Angular at the time. I had just begun reading about Angular. He suggested I should go give a talk about it at the end of that month at a local meetup. I had no idea I could learn enough to give a talk on the subject in just a few weeks, but it worked out, and it really showed me that taking the time to properly understand something enough that you could teach somebody about it is a great way to thoroughly understand something and appreciate it — much more than just using it on the surface.

David [4:21]:

Yeah, I can understand how that teaching has become an important part of the way that you learn things. We’ve talked to a few folks who’ve talked about how the teaching process ends up being something that they learned from. One of the things that caught my attention when you said that was that you learned enough about Angular so that you could teach it, but it wasn’t as if you were presenting yourself as the Angular expert, in this case.

Donovan:

Yes. Far from it. I was presenting something I felt was interesting to people that I felt would enjoy hearing about it.

David:

How did you get into Angular in the first place? I mean, there are lots of different directions that JavaScript’s been going in.

Donovan:

At the time, when I was looking into the MVC frameworks, and looking for something that would be two-way bind with the data, I was building a back-end for a web application, and we needed something quite quick that would show edits in real-time across various views on a page. It just clicked with me really in terms of the way it was presented, and the way you could build using directives, quite complex functionality, into tags. The fact that it was backed by, I think, Google, that helped as well. I’ve moved on since then, and thankfully, the ecosystem around that has grown a lot. You have fantastic options like React, and lots of even faster options coming in as well. But, at the time, it was a great choice, I felt, for the problem we had at hand, and it gave me a chance to improve my JavaScript too, just to better understand really what I was doing when I built a front-end application using JavaScript.

David:

When I think of the stuff that you’ve been teaching lately, though, I think mostly about the CSS side of things.

Donovan:

Yeah, a lot of what drives me is a bit closer to the presentation layer, in terms of how things are interacted with, and how things are presented in apps or websites. I have moved toward design more in the past few years than I initially started out, and I enjoy thinking about solving user problems, thinking about user experience from that perspective. Where it all comes together for me is combining an interest in how things look and feel with how they’re built. And, for that, CSS kind of sits nicely in the middle there. It can be frustrating at times, and sure CSS is what it is, but it’s a great way to express layouts, and to understand the point at which people actually use our software. Then for me, there’s so many ways you can go into CSS and use it, and learn within that. I’m currently interested in animation as one part of that, but that’s a small niche within a very big topic that CSS is.

David:

I know you’ve done a lot of work with interesting CSS animation stuff. Can you tell us a little bit about some of the stuff you’ve been publishing?

Donovan:

Sure. I was lucky enough to work with you guys at SitePoint on a course recently, where I talked about how the concepts of CSS animation, keyframes and transitions all work. I introduced the theory around that, and talked about practical ways that it can be used on projects. I also write and I share tutorials as I learn more about the topic on my website, CSSAnimation.rocks. It’s my outlet for ideas, so if I decide, well, what happens if I try to build this in CSS? And if it works, if I learn something, then I go onto the site and share that.

David:

How do you come across these projects to share? Like, how do you decide what you want to put up there?

Donovan:

It can come from all sorts of places. One example was when I was watching the trailer for Star Wars last year. I was impressed by the credit roll at the end, and thought, I wonder, can that be done in CSS? It looks like the kind of thing transformers might be a good fit for. I just tried it and saw what happened.

Another source might be at work, where we are trying to think about solving UI challenges, and how to help maybe users understand where something comes from, and where it goes. That might yield some thoughts about maybe how you animate a curved path using CSS. That then is something to write about, and becomes a topic in itself.

David:

The stuff that you’re writing, do you target that at a beginner level, or is it more targeted toward advanced CSS folks?

Donovan [7:47]:

Well, I guess a byproduct of the fact that I’m writing about stuff as I learn it is that it’s quite easy to carry a bit of an expectation in terms of that people know a lot of what I know when I write … because that’s where my head’s at at the time. I often have to stop and kind of tell myself to think back on how I got here, and maybe what assumptions I’m bringing in terms of what I’m working with. But, generally speaking, I would assume an understanding of CSS in general, in terms of what maybe positioning is, what margins and paddings and the basics are. But, wherever possible, I try to take time to just explain if I’m doing something fiddly with like any kind of new CSS properties. I might take a chance just to explain what it is that I’m doing with that to give context.

An example was today when I was writing an example about how to stop an animation before the page loads, and I used the :not pseudo class. It’s not something I tend to use very often, but when it’s needed, it’s extremely useful. That’s the kind of point I guess I would just stop for a second and say, Hang on. This is what this means, in case you haven’t seen it before.

David:

I know a lot of those things were unfamiliar to people because of compatibility issues. How much attention do you pay to browser compatibility when you’re doing the stuff that you’re working on?

Donovan:

Generally speaking, when I start, when I begin writing a tutorial, that’s when I wouldn’t worry too much about making everything work all the way back. But, I always keep it in mind. And, when I design and build things, I like it to be firstly trying to achieve as much as possible with CSS, but at the same time, to degrade gracefully back to something that still works and is accessible behind the scenes. In terms of thinking of actual version numbers, I often don’t really get too caught up on that, as much as thinking, Well what if JavaScript doesn’t work here, or, What if this browser isn’t capable of animations? We should then use Modernizr, or some fallback that makes sure that the content is actually going to be readable, that it will appear on the screen regardless. Then if the project’s capable of doing the fancy animation things, then go for it. Do as much as possible. It’s great, but I certainly don’t let the older browsers dictate what can be done with the new features.

David:

That makes perfect sense. One of the articles that you wrote that I was most intrigued about was these issues around accessibility and animation. I’m curious. Could you share with folks some of the things that you came across around that?

Donovan:

Sure. There are a couple of main issues that do come up when people do use animations, the first being motion sickness. We have this hardwired balancing system in our head that tells us that when the earth moves, we feel it a certain way. If we present animation, especially if it’s large animation that maybe covers the entire screen, that tricks the brain into thinking that something ought to move, but our brain doesn’t feel that movement, we can feel ill. That’s something that some people are more susceptible to than others. At the same time, another issue that sometimes comes up with accessibility is when movement is on the screen, it’s very difficult to not look at the moving thing. Often, even subtle animations can distract people to the point where they literally can’t even use the application anymore, because the movement is stopping them from getting past that part. We have to be very mindful of that, in terms of when we use animation, and when we start and stop and turn off animations when we want people to concentrate on something else.

David:

I hadn’t thought about the motion sickness side of it, but that’s an interesting point. I was thinking about how animation could be useful for people with impaired vision, because of our natural tendency to see things that move, and have our attention drawn to them.

Donovan:

That’s a good point, yeah definitely. People notice things. That’s the counter side to being distracted by movement, is it’s much more easy to notice. And, if you want to draw attention to something, or even more to explain where something came from, animation can help more than have something just appear.

David:

It’s true. When you’re creating your animations with CSS, do you run into a lot of issues around keeping smooth motion, dealing with like the 60-frames-per-second issues?

Donovan:

Absolutely, but most of the time, it really comes down to which properties we choose to animate. The main two properties that animate extremely well are transform and opacity, which deal with things like position, with scaling, skewing objects, and dealing with how transparent or see-through they are. If you’re using those — if you’re say, scaling things up and moving them around, using transforms and translation — then that’s typically great, because the browser isn’t repainting every time something moves. It’s not recalculating the positioning of everything else on the page. These things tend to then move in isolation. But, if you’re animating something like height … Say you have a div that has a fixed height, and you want it to get bigger to show more content, it has to nudge everything else out of the way. If you have a large page, that can often then cause stutteriness, because it’s recalculating up to 60 times a second, the entire layout of the page. That’s not what you want.

The same goes for font sizing, and other aspects maybe aren’t hardware accelerated — like if you tried to animate the background color of a large area, maybe the whole page or screen. That might, again, look very obvious and not right, because it’s trying to repaint many times a second, a very complicated scene. So, it’s a judgement call sometimes. You maybe look at it, and say, Well, maybe there’s too much going on in this animation. If we trim that back, or try to stick to transforms and opacity, then typically that results in a better performance.

David [12:28]:

That makes sense. That’s the sort of consideration that an engineer would take looking at trying to develop a site, but a designer might not actually be thinking about those issues when they’re putting together the design. I’m curious since you say you’re kind of transitioning between design and developer, how do you bridge those worlds, especially with designers who don’t know a lot about the engineering side, and vice versa?

Donovan:

I think this is a problem that … it depends where you work, I guess, but it’s becoming less of an issue, and I’m seeing less of a problem than it used to be, where maybe back in the day, people would approach a lot of the design work from a print background, and think in terms of above the fold, and very locked-down expectations of what things would look like, and pixel-perfect designs. But, we’re reaching a situation now where prototyping tools really help people communicate ideas, I think, better between departments, so that if someone’s building something, if the designer can help actually building how it moves, and even better, using a tool like Framer, for example, where there’s some basic JavaScript involved, and there’s some actual tweening, then that can communicate very clearly to the developer building it that this is the intent as far as the design is concerned.

But, then vice versa: if the designer’s trying to think up something but doesn’t really know if it’s gonna work, in terms of the capabilities of the browser, then tools like this help get that out in the open quicker. It helps the conversation happen back and forth, and I find that’s useful for communicating, Well, this is what we can do, and then having a two-way conversation about what’s being designed.

David:

Are there any tools in particular that you found very useful?

Donovan:

Any tools in particular? I’m a big fan of Principle. And, in terms of getting quickly to a basic prototype, I find that a fantastic tool. You can go further and make some quite realistic-looking mockups using Principle. But, my use has been actually even more basic with it. I once used Principle to create a simulation of an interaction using whiteboard drawings.

I drew each board on the screen, on the whiteboard, took a photograph of each one, put each screen into Principle, and made touch areas. It was as lo-fi as you can get, but it got the idea across of what will happen when people touch this part, and where will the screen go.

There’s Principle. There’s also FramerJS, which I would recommend if people want to be a bit more familiar with code. But, it has some good tools as well for creating movement, and is quite mobile-friendly.

David:

Do you find that there’s any difficulty communicating to engineers about what the subtleties involved in animation are? Like, why certain things matter, and why certain things don’t?

Donovan:

There can be. Like I say though, a good use of prototyping can really help clarify just what’s happening. For example, when designing for iOS, there are some tools that can really not just help by showing how things look, they can actually output the code needed for iOS to actually handle the springiness, or the bounciness, of the movements.

Yeah, I think the more people can communicate through whatever mediums, whatever tools we can find to help bridge these gaps, it really helps the process be smoother. It helps people communicate ideas from design right through.

David:

I think animation is becoming more of a critical element in user interface in general, and people are starting to come up with almost a linguistics for how to use animation in their user interfaces.

Donovan:

Yeah. I think communicating what animations are is a tricky thing to do. Sometimes it’s tough to try to just get the idea across. You can’t really do as much as you need to with just waving your hands, for example.

David:

[Chuckles] But, when people see something in their user interface, and the menu bounces a little bit, people are starting to become familiar with that as communicating a specific notion about what’s happening with the content.

Donovan:

I’m a big fan of what Google did with that with their material design work, where they took a lot of the principles of animation, and applied it to help people understand just what was happening with UI. Some of the subtle animation touches that they came up with, for example if something appeared on the screen, it should start off already in motion and then slow down, rather than ease up and then down into the view. It was good to see that kind of realistic design taken on board in terms of UI.

David [16:13]:

I know what you mean. A lot of us grew up watching cartoons in which all of those things are animated and exaggerated. Yet, now all the things that we saw as children are informing the way that we do our work today.

Donovan:

I think the principles of animation still stand. There are 12, actually, very well-considered points there in terms of how to help us connect with what’s on the screen. If we apply that to our UI, then helping people connect to what we’re building is a good thing.

David:

Have you been getting any feedback from users about the types of the information you’ve been putting out there?

Donovan:

Over the past two years, I’ve had over 2000 people take part in a course I run at CSSanimation.rocks. That’s been invaluable for me in terms of learning what people really enjoy learning about, but also what they use these skills on. Seeing the different perspectives and the different ideas, and then seeing things pop up on sites like CodePen, it’s just fantastic to see the ecosystem around web and animation growing.

David:

Where do you think you’re gonna be taking this next?

Donovan:

I’m gonna keep pulling the thread and see where it leads. Every time I learn something new, I’ll do my best to share it, and see what exciting doors it opens up.

David:

That’s awesome. For listeners who are curious in your course and your information, how can people find you online?

Donovan:

I can be found on Twitter @DonovanH, and on the web I run a website called CSSanimation.rocks. That is also on Twitter, but the handle is @CSSanimation.

David:

Cool, and I think you have a course at SitePoint as well.

Donovan:

I do indeed. I recommend you check it out.

David:

Fantastic. Well, thanks for joining us today. This has been really fascinating.

Donovan:

Thank you very much. It’s been a pleasure.

[Musical interlude]

David:

Well, Tim, I really need to thank you, because you know we had some technical problems during that show which is why I was asking all the questions. But, you were there in the background sending me the good questions to ask. You were typing on the back channel, and letting me know what I should be asking Donovan about.

Tim:

Yes. I was there in spirit, and muted on Google Hangouts.

David:

Muted thankfully, but it worked out very well for all of us. It was a great episode too, and Donovan really brought me back to my past. It was talking about the Amiga and the Sinclair ZX81, and 3D rendering. Man, that brings me back to the old days.

Tim:

While I was listening to him speak, and listening to you speak, and just listening in general, it really started to dawn on me how there’s almost this formulaic progression wherein someone just gets interested in the field of web development, and they go on to learn and write or speak or teach about what they’ve been learning, and they just, they continue to do that. As they’re learning something, they figure out to themselves: okay, this is an interesting thing. I’m gonna tell others about what I’m doing. They just continue with that, and that’s how they get to this sort of stage in the industry wherein they become a good resource.

David:

It’s inspiring, because it’s so easy to think about just going in, doing your job, and then going home, taking assignments as they come, and not really thinking about the broader picture. But, these are the people who are taking agency in their own careers, and saying, This is what I’m interested in. This is what fascinates me. They go down those funny little channels, and explore the odd nooks and crannies of, like, CSS animation for example — areas that people might not think of as hardcore engineering, or serious career development. But, they end up building reputations for themselves. And they do that in a way that makes them the sorts of people that we’d want to have on the show talking about how they’ve built their careers.

Tim:

Yeah. It’s like they allow their curiosity drive them. Yeah, I love to see that, and of course they become the people who we ask questions. Like, for example, when you asked Donovan about CSS animation, and I learned something completely new, wherein your animating can sometimes throw people off balance, and cause special dis-awareness. I’ve probably done that before, and I’ve never thought anything about it.

David [20:07]:

It’s true, and it’s so wonderful that people are thinking about accessibility issues. As Donovan said, accessibility isn’t just about people with disabilities. Accessibility is about being able to interact with the site from wherever you happen to be coming from. It can come from people who, they might be distracted. You might need to design in a special way so that somebody can pay attention, so you put something flashing over here to take advantage of the human natural tendency to respond to flashing items.

Tim:

Yes. Situational awareness is often something that we don’t think about when we’re building things. You know, we don’t often ask ourselves, What is in the mental space of the person who is using this service or product? Actually, I believe it’s Eric Meyer who has a lot to say about that. He speaks a lot about designing for crisis. For example, if you are building a splash page for a hospital, what is the type of information that’s more important, and what kind of state is the user in when they’re looking up that information?

David:

This is why the whole field of UX design, I think, is exploding right now, because we’re getting to the situation where something that somebody cobbled together on a deadline in order to meet some requirement is now saving lives, or failing to save lives. It’s becoming a reality in the institutions that our society is built around. So, now we have to play quick catch up, and realize that all of this work that we’ve been doing, it has a real impact on people’s lives. These are the sorts of things that are going to come up, and we need to pay attention to that we wouldn’t have thought about this before.

Tim:

It’s easy to forget about something. I’m working on building some search functionality at work right now. There are some very little expectations that we put into these sorts of products without ever thinking about it. For example, when a user searches, we kind of assume from the get-go that we know what they’re searching for. That’s not necessarily … Let’s say I’m building a search to search for, I don’t know, different types of cardboard boxes, right? You could assume that I need to buy a cardboard box, or you could assume that I’m a cardboard box aficionado.

David:

Or, you could assume that you’re a cat.

Tim:

You could also assume that I’m a cat. In that case, no red dots flashing across the screen. I’ll attack my computer.

David:

[Chuckles] It’s true. But no, you bring up a very valid point. I mean, we’re making these immediate assumptions about if we have a user, we know what we would like that user to be there to look for. We know what would benefit our business for that user to be there for. But, what that user’s actually there for, we might have no idea. Being able to come up with that perspective, and recognize it, and be adaptable enough, that what we’re doing will work for whatever kind of user happens to be coming to us, that’s a skill that people haven’t been developing enough.

Tim:

Yeah. I’m 100% guilty on that.

David:

One of the things that Donovan was talking about, particularly around the issues of CSS animation, was the tools that people use to communicate how an animation is supposed to work. We’ve talked about this before, I think, with some other folks — about designers not being engineers, not necessarily knowing what the capabilities are of the technologies. At the same time, engineers — not being designers — don’t understand what the user expectations are necessarily going to be around an animation. He brought up some tools. I haven’t actually worked with either one of those tools. I think it was Principle and Framer.JS.

Tim:

I’ve heard of Framer.JS, but I haven’t used it. What I can tell you is I’m very guilty of communicating animations with designers by waving your hands around in the air, and making whooshing sounds.

David:

Tim-driven design, that would be.

Tim:

Tim-driven design is probably —

David:

Hashtag!

Tim:

… not as good as FramerJS, but it makes —

David:

It’s probably more fun to watch though.

Tim:

Oh yes. It’s great. It’s great, especially if you can’t hear what anybody’s saying, and then you get to ad lib.

David:

How does that actually work in practice?

Tim:

Not well, because what you end up is an animation that was never fully communicated, and nobody expected.

David [24:02]:

It’s a tricky problem, and I think that a lot of it comes down to the language that people use to communicate what it actually means to produce a type of animation. I don’t think that we yet have the language for doing that.

Tim:

It’s almost as if every time I start working with a new designer, I forget to say, Here’s what we should use to prototype animations, and here’s what I’m going to use to build out those prototypes.

David:

I think it’s useful for the designers to know what the engineers are working with. At some point, there has to be a lot more interaction between those two sides of the equation, because an engineer who has to understand the complex mathematics of how these things are going to work together, versus a designer who might be thinking more about, perhaps it’s the situational attention of the user.

Tim:

As we mentioned before, the animation usually comes in as an afterthought. We need to talk with people like Donovan to remind ourselves continuously that it’s an important thing. It deserves thought, and you need to have a plan for it. Even if you don’t actually plan on adding animation to your project, most of the time, it kind of just seeps in there.

David:

You raise a valid point there about animation coming in as an afterthought. I think a few years ago, a lot of us used to bristle at the idea of Am I a developer or a designer? As a developer, somebody would say, Are you a web designer? You would get all upset about being called a designer when you’re actually a developer. I think these days, people are looking at animation a lot the way that they were looking at design back 10 maybe 15 years ago. It was something that you added as a decoration at the end of a project. But, in actual fact, animation is critical to the way people are interacting with all of these interfaces these days. We’re learning more and more about how critical animation can be.

Tim:

Right, because nobody wants to open up an off-canvas navigation menu, for example, and it to just blink and be there. You want it to slide out a little bit. Even if you don’t think about that as a user, subconsciously, when it opens all nice and smooth-like, it makes you feel better about what you’re using.

David:

It simulates the real-world interactions, and it gives you a context that you’re operating in. I imagine that as we start getting into more immersive environments and augmented reality, that’s going to become even more critical.

Tim:

Right, because no one actually likes using interfaces. In fact, it seems like the more technology progresses, the less interfaces you actually want to have, right? There’s the concept of the UI-less application, wherein you get a push notification, and you respond to that with the touch of a button. That might be all the interacting with an application that you do, because every new user interface that comes along, it requires an investment. You have to invest time into learning how to use it to learn its quirks, its defects, what’s good about it. But, users themselves don’t want to give this initial investment into these sorts of things. They just want to complete the objective at hand.

David:

That’s one of the reasons why it’s so frustrating for users when the interface changes in an application, as we’ve seen. When you move this button over here, you change the way people interact, you adjust the way you click on a form button, or how an input field works. The users have become used to a certain pattern for how these things behave. It’s one of the reason I think that when the browser designers decided to make HTML form elements more difficult to style with CSS, that was brilliant, because users are used to the way that their browser’s form elements work. If you get into a situation where people are over styling and over styling form elements to make them behave or look and feel the way that the rest of the specific application looks, a user, who’s used to the way their browser’s form elements work, is gonna get confused from one site to the next.

Tim:

I wish it would translate that way between designers and developers as well.

[Chuckling]

Because I very often get comps that ask for redesigning for how a select drop-down works, or a radio button, or a file input type.

David [27:56]:

Yeah. That’s something that I often push back on. I don’t always win those arguments when I’m pushing back on it. But, I think that there’s a more valid argument to be made now, for recognizing that these interactions make a difference to the way that users will interpret an application consistently across all of the different applications that they’re using within their browser. As designers are getting more into animation design, and into situational perception, I think that they might be more attuned to that issue right now.

Tim:

Yes, I would certainly hope so. Speaking about perception, one of the things that I really like about Donovan is how he teaches, because it seems like looking through his courses on CSSanimation.rocks, he really seems to understand that the type of person he’s teaching about CSS animation might be coming from a background of not necessarily understanding anything about the topic.

Just diving into the material here, you can really see that this is geared towards someone at any level. You know, basic concepts are explained, but not in too much detail that it becomes trivial for someone who is not necessarily a beginner. But it really does translate that he’s thought about where his user is coming from, in terms of diving into his course.

David:

And I know a lot of people who have a background in engineering have historically tended to shy away from CSS. It’s attracted more people from the design side of the world than from the engineering side of the world. Yet, these days, it’s becoming so integral to engineering to be able to create performant CSS, especially with animation, that creating courses like this that allow people to come in and apply their skills, and yet develop the knowledge that they need, it’s invaluable.

One of the things that impressed me with Donovan what he was talking about about teaching courses is how he goes out and learns the things that he’s interested in, and learns through the process of teaching. I think that that’s something that’s universal with teachers.

Tim:

Yeah. He also mentioned something to the effect of CSS being hard for everybody, because it’s not necessarily a programmatic language in the way JavaScript or PHP or Ruby is. It’s very declarative. That trips a lot of people up. Taking advice from the way that Donovan got started, by getting interested, learning, and then teaching what he’s learned, it seems like that’s good advice for anyone who does find CSS incredibly difficult, right? If you’re struggling with it, maybe it’s a good idea to build your own CSS 101 course, and see just how far that gets you into understanding the fundamentals a little bit better.

David:

That’s true, and it’s not like there isn’t going to be an audience out there. There’s always somebody out there who’s interested in learning these things. All you need to do is know one thing beyond what your audience is looking for, and then you’re the expert on that one thing that they need to know next. Like, for example the way he was talking about the different techniques in animation that can be more or less performant. He was talking about transform and opacity, scaling and translation — but, don’t change height and don’t change size — and how those things make a big difference in terms of how people interact with a web page. He can rattle that off, because he went through and, step-by-step, he figured out these are the things that work, these are the things that don’t.

Tim:

And, it’s not just necessarily about having information that someone else doesn’t have. Most of the times, these also serve as excellent reminders. I can probably go through this CSS animation 101 course that Donvan’s released. I’ve probably heard about every single thing in that course, but I can guarantee you, there is more than one thing there that I will go, Oh. I totally forgot about that. Let me write that down.

David:

It’s always going to change, too. The other thing that’s important is that it’s never something that’s going to be sitting still. As the browsers change, as the expectations of users change, as design techniques change, we’re always going to have to keep on learning new things. That technique that was marginal five years ago is now absolutely central to the work that we’re doing, so there’s always another opportunity to go out and learn something.

Tim [31:48]:

Right. For example, those getting started with CSS right now may not have to worry about browser vendor prefixes as much as we used to have to, right? I don’t really have to write a browser prefix for a border radius anymore. That’s not something that I have to worry about. For anything that I do have to worry about those, I can just hook up a post-processor that’ll add those browser prefixes in via Can I use data, and it’s just completely forgotten about.

David:

Of course if we’re using Sass, a whole lot of that gets taken care of for us behind the scenes anyway, unless we’re the people writing plugins for Sass to make that stuff happen.

Tim:

Yes, those people have to know about it.

David:

I’m so grateful for that, because there were days back in the day when I used to dream in CSS browser prefixes and hacks, like putting asterisks in front of things in order to make IE6 recognize or not recognize different selectors. So glad those days are behind us.

Tim:

The zoom property. That was just — nothing’s working, I’m gonna try this.

David:

It was amazing how often that worked, too.


Tim:

Well, thank 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, with production help from Ralph Mason. Please feel free to send us your comments on Twitter — @versioningshow — and give us a rating on iTunes to let us know how we’re doing.

Tim:

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

The most important and interesting stories in tech. Straight to your inbox, daily. Get Versioning.
We teamed up with SiteGround
To bring you up to 65% off web hosting, plus free access to the entire SitePoint Premium library (worth $99). Get SiteGround + SitePoint Premium Now
Login or Create Account to Comment
Login Create Account