Motion Design with CSS Duration

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Rachel Nabors: Let's focus a little bit on theory. So back in 1993, Jacob Nielsen did a bunch of research that showed that there were three major time limits to keep in mind when optimizing human computer interaction, specifically page loads. Now, it should be mentioned that humans and their interactions with computers have changed a lot since one 1993.

[00:00:25] We have people who are much more used to using computers today on faster Internet connections and even with gesture interfaces that respond immediately to them like in the app environment. So our expectations today might be different from how they were in 1993. However, these experiments haven't been repeated and they do give us some temporal guidelines to work from not to mention they do line up with some experiments I saw in the past and I'll talk about them in a moment.

[00:00:55] So let's extrapolate a bit from this research what you found was that 100 milliseconds a jump cut that is to say going from one page to another takes 1000 milliseconds will feel instantaneous to a user. They don't notice that there's any kind of a lag it feels like they've just popped on to the other page even if it took 100 milliseconds to go from point A to point B and re-render the page.

[00:01:18] In animation, at one hundred milliseconds, happened so quickly that it's hard to perceive. Now, page loads from one hundred milliseconds to one second long, they would be noticeable but people still felt very connected to that interaction, right? So that's kind of your sweet spot, between one hundred milliseconds and one second.

[00:01:38] This lines up with some research that has been done about how long it takes humans to notice change. Now, there's a huge variety in people's temporal beats. Now you might have noticed older people saying everything seems like it's going by so fast, this has been scientifically proven. That many older people experience time passing faster because their internal metronome is ticking slower.

[00:02:05] Some people have internal metronomes that tick very fast. So everything feels like it's happening very slowly around them. These people can notice change closer to around 70 milliseconds. Whereas, older people might be noticing change happening over 700 milliseconds. That's that's a pretty big range, but that's one of the reasons why we notice that there's this kind of a sweet spot, right between 1 second and 100 milliseconds.

[00:02:32] Because this is going to capture the gross of humanity. We'll talk a little bit more about that in a moment. So,
>> Rachel Nabors: There was this other thing too. Around 10 seconds response delay, users no longer felt like their action and the interface's reaction were connected. That is to say, you can think of the 10 seconds point as the I'm bored point.

[00:02:59] If something takes ten seconds long, if you're going to be running an animation for 10 seconds, probably needs a play button on it, or it could be a movie. Just putting that out there.
>> Rachel Nabors: So here's my site at this time in 2016, here's my site with a one second transition duration on this side bar.

[00:03:25]
>> Rachel Nabors: When I was developing this one second seemed fine. But you never seen this before? Probably feel like this is a little slow. This user interface feels slow to you. Okay that is fine, that is a fair assumption. And the reason that it would look fine to me.

[00:03:42] After spending a week or so working on it is because, and this is a well known problem in studio animation. When studio animators are working on animations to get pulled into this warped sense of time. Because they're so busy studying every frame of that animation. Imagine two people dancing they can see every movement, that when they replay it they tend to replay it at speeds where they can see each of those individual frames and actually experience it because they're fine tuning it.

[00:04:09] They're playing it slowly they're looking for the movements. So there's a rule of thumb in Animation Studios which is that however long your pre-production animation is you need to have its duration and then have it again that is to say quarter it. When preparing final frames to show to an audience, if I ran them at the same speed that I was working on the at it would really be slow and it's the same for studio animators.

[00:04:35] That dance sequence that they spent, who knows how many man hours making they're going to have to play it really quickly, which is kind of sad for the art but hopefully someone will take some beautiful stills. So here's my site with a 300 milliseconds duration. I found that 250 milliseconds was a little bit too fast for the motion.

[00:04:56] You will find that motion, like actual movements of things across screens, tends to do better with longer durations the wider the distance it has to cross. So that's just because large things moving quickly across the screen never look good. In user interface animation 250 to 300 milliseconds are a recurring theme and they recur for a reason.

[00:05:24] In game development, you also find 250 to 300 milliseconds. They show up over and over again. That is because this is kind of the gross median for humans to notice change, and this is going to feel right to probably the vast majority of users. Although a little fast perhaps, to people whose metronomes are ticking a bit slower and a little slow to people whose metronomes are ticking a bit faster.

[00:05:49] Now, there is an opportunity with the Web Animations API, which is in development right now. It's shipping out In more and more browsers there's discussion of letting users access the global timeline so that they could say I want all animations that the web animations API runs which would be CSS animations and CSS transitions because this API underlies how the browser renders them.

[00:06:15] I want all of these to run a little faster or a little slower. And this would be an accessibility thing than the browser could go in and adjust the internal playback rate for all of its animations in accordance with this. That's the hope to let people have choice in how they perceive the web.

[00:06:33] So you can go with these default setting look pretty good for everyone but users would then have the choice to slow down or speed things up across the board across the web for themselves. Just putting that out there, it's a little bit in the future people who are watching this video in the future might be like totally happened or they might be like totally didn't happen.

[00:06:54] But I wanted to remind you that this is in the works. But keep in mind you do still have a full second to play with people before they get bored. So if your animations like you're moving something really big across the screen takes 800 milliseconds, don't feel too bad about it.

[00:07:10] If that's what it takes for it to look right, you still haven't gone over that one second mark.
>> Rachel Nabors: And that's an important note to make here. Who here is a major performance wonk?. I know we've got some performance wonks in the audience here. I see a little hand see another hand.

[00:07:28] We are really focused on performance right now and that is wonderful It is so good to see people excited about performance. But sometimes we forget why we were originally excited about performance. We get so focused on just getting information splashed on the screen as quickly as we possibly can that we forgot why we were trying to do that in the first place.

[00:07:52] It all comes down to that study by Jacob Nielsen we wanna make sure that people can see that page has changed within 100 milliseconds. We want them to feel like the interface is reacting to them, is responsive to them, that things are being done. It's like having someone pick up the phone and saying hey yeah we totally understand you're having a problem.

[00:08:12] But they can still say I have to put you on hold for one minute, I'll be back to you. And as long as they're back within a reasonable amount of time that person calling the call center will not be upset. But still much better to get that notification that this is being handled than it is to get like a phone that just keeps ringing.

[00:08:29] It's the same with performance. I hear a lot from people who love performance that they don't like animations because they just shaved you know 300 milliseconds off of, off of the load time for a page by optimizing database calls and now I want to add 250 milliseconds to that page load with the transition am I crazy, well that, yes and no.

[00:08:57] You have to keep in mind that deciphering an interface Increases cognitive load time and can slow users down just as badly as a slow load time. If you're going from a page that is very different from the page where the user was adding a transition to show them how they're getting there can help them reorient faster than if you just got it to them in 50 milliseconds.

[00:09:22] So that's one of the reasons why animations can be your friend too. They can also mask long load times. If you're going to take fifty milliseconds, having a one hundred millisecond animation on it, isn't necessarily a bad idea. You will be masking that load time. So animation and performance can be friends and it's important to remember why performance and animation are important.

[00:09:43] Because you want users to feel like that interface is responding to them. But you also don't want them to be confused if the interface suddenly and rapidly changes, all right.
>> Speaker 2: So we had question.
>> Rachel Nabors: Yes.
>> Speaker 2: Before you move on, it was a little bit back when you're talking about how this might not actually be implemented quite yet.

[00:10:06] So the question is from the Nicholas asked is there an option for us to control this via JavaScript in the meantime in other words can we set some variables and allow users to manipulate those through controls?
>> Rachel Nabors: Can we let people manipulate the global time line of animations today?

[00:10:24] Well, yeah kind of. That would require you to use the web animations API polyfill. And you'd have to do things where you basically run through all of the animations on the page, and then adjust their playback rates. It's not quite feasible for today. But this is something that hopefully within the next year or two will be possible and a little bit more convenient and won't require a poly fill on quite so many browsers.

[00:10:52] We'll talk a little bit more about the Web animations API at the end. That was a very good question and I'm happy to revisit it later too.
>> Rachel Nabors: The other alternative would be that you could write an alternative style sheet with different durations and let people set their duration preferences.

[00:11:11] If you are working on a government site or a site with profiles and accessibility options. Which, if you do work on a site, and you have, you probably should have some accessibility options for a site with a huge amount of different users of different capabilities and age ranges, you probably should have some like would you like to use a font that is good for people with dyslexia options somewhere.

[00:11:34] Along with font sizes etc for people who don't want to dig around the guts of their browsers, we're not all built for that. That would be a good place to put that option like would you like animations to run a little bit slower or possibly not at all.

[00:11:47] That would be a good place to add an alternative stylesheet option. That's how I would do it without using JavaScript, if push came to shove and that would work pretty much across the board today. All right, so there is something to keep in mind, though. That's not my mouse.

[00:12:10] If an animation is too fast to be interpreted it's cognitive load benefits can be lost. Here's my site with 100 millisecond duration on that slide. If you blink you'll miss it. It's happening so fast that very few people are going to benefit from this. It may as well just be a jump coming in and off the page without an animation.

[00:12:31] Now here, the animation is happening so fast it's barely noticeable. Do we really need it? Probably not, we could probably save some time, save a threat on the on the CPU or the GPU in this case. I'm using transforms and not bother to animate that. So If you're going to animate things too quickly for them to help people, to help ease cognitive load, help them see where things are coming from and where they're going, it's probably better to just not animate them at all.