This is the written version of the presentation I gave in October for CSSDevConf in Estes Park Colorado. If you want a much better thought out and presented essay on the same lines, I recommend Frank Chimero’s "What Screens Want". Seriously, his is much better.
The slides can be found here.
This talk is not about the technical aspects of css animations and transitions. Those are much better learned in the context of a tutorial online or reading the docs. I could probably spend an hour exploring them, but I’d get bored after 10 minutes and then how could I hold your attention?
So I’m going to focus on what motion is in the context of user interfaces, how it’s valuable, and some philosophical principles for how to employ it. I am interested in the design of interfaces not in how they look, but how they respond.
So let’s get started.
1. Why Move?
I think it’s helpful to define the types of motion I’m referring to in interaction design so that we can start out on the same page. I’m afraid that there are some people who think that the purpose of CSS Transitions and Animations are to replace Flash. Google’s recently released Web Designer Toolkit suggests this usage. I have nothing against that type of motion, it’s fun and eye catching, but it’s not exactly useful in the everyday production of sites and apps.
That type of motion makes me think of all the flash based sites we used to have to deal with. You know what I’m talking about. They would take minutes to load, and then it was just a collage where the buttons were non-standard and every time you clicked something everything would move around and there was SO MUCH MOVEMENT and none of it was helpful find the menu of a restaurant or the tour dates of the band you liked. That is awful, and I am not interested in that.
The motion I’m interested in is transitory and communicative. It’s not necessarily things moving and switching, it’s simply taking advantage of the tools at hand to tell the user look here! and this was supposed to happen! It is simultaneously mimicry of the real world (for every action there is an equal and opposite reaction) and invention of a new world, because using motion in a digital interface has no true connection with physics so you can play and experiment and use movement as an added layer of identification for your creation.
So let’s get this party moving.
What’s the Basis?
I like to watch people use technology. Mostly I just observe but I occasionally ask questions and from this practice I’ve learned some not-statistically or scientifically valid tidbits.
Users are scared
Computers JUMP a lot. States change. Modals appear, windows hide, context changes. Non-technical users don’t always know what to expect. And when things are appearing and jumping without explanation, they figure out why. Because
Users are Smart
We are all living out a story. Yes, there’s the biography of our lives, but internally there’s the narrative we create to explain life. In the 1940’s Psychologists did experiments regarding our sense of causality. They would show simple animations like this and ask viewers what they saw. The viewers across the board explained that the blue ball moved because the red ball pushed it. You see it there, right? That is not at all what’s happening though - someone animated a red circle to move, and then when it reached a certain point they animated the blue circle to move. The two circles have no actual connection, it’s only in our brains. Many viewers would describe it as the red circle trying to play with the blue circle and failing - going further than just assigning causality to build a narrative with motivation and emotion. It’s just two circles, but we wrap automatically explain it by wrapping a narrative around it; assigning cause and effect and motivation and emotion to the shapes on the screen.
Users do this with our creations. If things happen that they don’t expect they will concoct really fascinating explanations. Have you ever watched someone on a computing device go through a seemingly ridiculous series of steps to achieve their end goal? It probably traces back to a time that their internal explanation for an event did not match the actual cause. I think of slow responding webpages. Perhaps you click a button, but the page does not respond immediately, so you start tapping other things and trying other things, and then finally the original desired event occurs. If you don’t understand the intricacies of network latency and server responses and bad developers you might be inclined to connect the last action you made prior to the event occurring as the driving “cause.” This is a perfectly rational and intelligent response, given the information you have. It’s completely false, but it’s rational.
- Users get frustrated, unnecessarily
The net result of these fantastical narratives and jumping interfaces is frustrated users. I’m not sure if this is an obvious statement or not, or a controversial statement, but generally we should try to avoid frustrating our users. Maybe?
Now, nothing about this talk is a magic cure for the issues I’ve outlined above. It’s the reason that User Experience is such a massive field and the reason that it’s terribly difficult to design simple and easy-to-use interfaces. But I do think that the inclusion of movement in design is often overlooked despite the fact that it’s incredibly helpful for users. So lets try to understand it a bit better.
Why is it helpful?
Movement is communication.
Our brains are designed to interpret motion. It’s one of the things we’re pretty good at. Well, specifically we’re very good at assigning causes to events, that we then assume are the correct explanations. There’s a problem with this though, explained well in a recent Wired article about science:
The problem with this assumption, however, is that causes are a strange kind of knowledge. This was first pointed out by David Hume, the 18th-century Scottish philosopher. Hume realized that, although people talk about causes as if they are real facts—tangible things that can be discovered—they’re actually not at all factual. Instead, Hume said, every cause is just a slippery story, a catchy conjecture, a “lively conception produced by habit.” When an apple falls from a tree, the cause is obvious: gravity. Hume’s skeptical insight was that we don’t see gravity—we see only an object tugged toward the earth. We look at X and then at Y, and invent a story about what happened in between. We can measure facts, but a cause is not a fact—it’s a fiction that helps us make sense of facts. source
My point being we’re not good at assigning accurate causation, instead we’re good at crafting a simple narrative about what is happening. And we do this based on patterns we’ve learned and observed since birth. Those patterns are useful for us as developers.
So in the context of user interfaces, how does this narrative-building function come into play? It gives users the ability to read movement and understand what it’s communicating. Because movement is communication.
Movement, or motion, can communicate:
* State change
We can tap into our brains’ innate abilities for narrative-building to ease our users fears and help them navigate and use our products with confidence. We can encourage them to build a mental map of the tools they are using. Even better, we can change the way we design things because we will think about them differently. So let’s dive into movement in app design.
2. What Move?
transition: all .2s linear;
That would transition all animatable CSS attributes with linear timing over 200 milliseconds. And this line captures the aspects of movement that I’m interested in with regards to interaction design:
The ingredients of motion: Attribute + Time + Style
* What should change
* How fast should it change
* What should the change feel like
So here’s the question: how can I mix these three parts to create movement that is useful. And what exactly is “useful” in the context of what I’m doing?
This consideration is really important with current design trends. Perhaps you’ve heard of “flat” design, the highly controversial styling that one of the two dominant smartphone platforms recently introduced. That now means that both major mobile OS’s are pulling from this “flat” design language. And this trend is spreading across the web as well. I personally really hate this term “flat” though, since it doesn’t seem to actually describe what’s going on. I think a much better term is “light” design, as in lightweight. Christa Mrgan, a designer, explains well in an article published after the debut of iOS7:
In shedding this faux-3D skin, iOS has transformed into something remarkable, with a new kind of depth and motion. Apple has given up the artificial 3D image techniques of deep shadows, strong highlights, and gloss in favor of relying on spry animation and the parallax effects of flat planes to convey the sensation of depth. source
I get why the word flat is thrown around - there is a distinct absence of drop shadows and bezels and texture that suggest depth. But where the design trends of today avoid using optical illusions to suggest depth, there is a genuine attempt to use the viewport as a window looking into a digital space, where user interface elements actually have weight and space and relation to each other.
The goal then is not to create textured skeuomorphic designs to map our apps onto real-world metaphors but to give the user just enough interface to understand how to accomplish the things they want to accomplish, and then to get out of the way. And as states change, or new functionality comes into play or new content is revealed, we utilize the faux 3D language to give our users a framework for understanding our app. In this new design language, motion is critical as it helps us build a mental map of where things are, how to get to them, how to get back to them once they go away, and what the interface “feels like.”
So the goal is to make a light interface. Give the user just enough interface to make sense of what they are seeing, then use contextual communication to help them feel comfortable.
So I want to explore the ingredients of interface movement in the context of attempting to make a light interface.
A. Movement as Relation
If a user performs an action on our site that causes the display to change, movement may be all that’s needed to connect the two. Remember earlier how I spoke about our need to ascribe causality? This is where movement is needed. The key of course, is lack of delay. In the real world we expect interactions to have instant feedback: If we push on a door to open it, we expect it to either open as we push on it, or for us to smack into it because it’s locked or opens the opposite way. The feedback is immediate. In the digital world, we design things to have instant feedback, but maybe we don’t think about the delays that can happen in production, delays caused by slow computers or network latency or bad programmers creating slow code. Those are just obstacles that we should factor into our design. Loading spinners are great, but make sure that you are communicating to the user immediately that they have done the correct thing, regardless of any delays (except bad programming, that’s hard to work around).
The easiest way to signal relation with movement is with direction, which means thinking through what attributes to animate. If I click a button that causes new content to arrive, maybe the content container can move into place starting from the direction of the button, without waiting on the content to load via AJAX. This doesn’t have to be egregious; you don’t have to have boxes flying out of buttons and inserting themselves into the DOM (good luck achieving that with only CSS and keeping it 60FPS), but you can add a slight bit of movement and a fade to make it clear that the Button press caused this to appear. These are small details, but hopefully we all agree the small details are the ones that make the difference between good and awesome.
The other aspect of relational movement goes back to the faux-3D space that so many pages and apps live in now. If you think of the viewport as a window, then it’s popular to animate in new elements and content as if it’s somewhere outside of the viewport at the moment, or hidden behind elements on the viewport. This is awesome! It’s a great visual metaphor and helps users feel grounded in your app. But it also is easy to abuse, and in doing so remove a lot of the value from the design.
The thing about the faux-3D world is that theoretically you’re placing the elements of your site or app into a space. For users, this space is real, even if they can’t always explain where things are at the moment. Here’s an example that has just been bugging the hell out of me lately. In iOS7, when you log into the home screen after the phone has been locked, all your apps fly in on the screen. Ooooh.
My question is, aside from the unnecessary delay it puts on using your phone, why were my apps floating out in front of my screen while my phone was off? What is it about the screen locking that causes the app icons to float a few inches away from their normal positioning? It doesn’t make sense. It bugs me, because I personally think in 3D. I have a mental map of where I am always, even in digital spaces. So say, when I’m using the virtual desktop feature in OSX where I have multiple desktops open and different apps in each one, I know, in 3D space, where those apps are at the moment. It helps me navigate and organize my computer. If I tried to access one of those apps, that I knew was about 2 feet off my screen at the moment, and it just popped up from the bottom of the screen it would be very disconcerting to me.
Now, this isn’t a rule, I guess, because not everyone is a freak like me, I understand that. But here’s what I’m getting at. If you’re going to use this relational metaphor within your designs, STICK TO IT. Think through it, and create a z-space styleguide, and make it useful. If your menu is behind your page, don’t stick other things back there too that don’t make sense. If you have modals, make them useful, otherwise look at ways of inserting content into the dom. Think through the layers of interaction and make the metaphor a useful one, or don’t use it at all.
I think all this philosophizing is worthwhile here at CSS Dev Conf because if you’ve ever explored this with CSS, it can be REALLY HARD. It’s one thing if a user just toggles something and we transition from active to inactive, but it can get really complicated really quickly as you try to transition lots of content or rearrange things or insert new things. Transitions are very helpful in communicating to a user where to look or what they’ve done, but that doesn’t mean CSS and HTML make it very easy to utilize them. There are interesting projects attempting to tackle the combination of CSS only + 60FPS (“Jank free” in Google lingo) + plug and play, but they are very much works in progress.
B. Movement as style
So movement as relation is a way to animate specific attributes such that the movement itself has communicative meaning, but what about the other two ingredients I mentioned before: how fast should it change and how should the change feel? Let’s explore those, because I think if I say anything that may be unexplored here, it’s this section.
The first ingredient is time. Typically, this is a matter of hundredths of a second, right? What’s cool, is that even though this seems like an indistinguishable amount of time, our eyes can perceive it. We can see the difference between .2s and .4s, or at least, we can “feel” it. That’s great, because we can use our perception to our advantage. We can make certain actions seem snappy, and certain others seem sluggish. We can animate certain attributes at one interval of time, and other attributes at a different interval of time, and trigger them together, and the movement will have some extra dynamism.
This of course, often results in really crappy movement. It’s a trial and error development, where mostly you error but occasionally you succeed! And furthermore, if you go back home and start trying to do this, what you’re going to find is that css animations have great potential, but we’re still in the early days, and browsers don’t always render them the way you might expect. That’s ok. We’ll get there.
But time-intervals really only get exciting when you start playing with easing functions. Easing functions are the 3rd attribute in the CSS transition shorthand notation, and maybe you get them, or maybe you don’t, but I thought it’d be interesting to end by exploring them a bit.
Easing functions look like this, in their raw form:
c(t/=d)t*t + b;
So why take advantage of them? Because they imbue your motion with that little bit of pizazz that seems to say something. Let’s look at an example of each.
Here’s a line expanding on with a linear function over 2 seconds. Now compare that to an Ease In function over 2 seconds. And here’s Ease Out. And Ease In and Out. They all start and stop at the same time, but they move with different purposes. Or, we perceive them to have different purposes (our silly brains wrapping narrative around pixels on a screen being drawn according to a math equation).
Ease In functions feel soft and comfortable. From a user perspective, an Ease In function isn’t jarring because the motion starts slowly and then gains speed, before stopping at the final point. The real world corollary is a snowball on a hill. It starts slow, gains mass and momentum, before hitting some tree at the bottom of the hill.
Ease Out functions are the opposite - the movement is sudden but then slows gracefully down. The real world corollary is starting a pinball game - you pull the little springy trigger and the ball jumps out of the gate before slowly losing momentum (until you hit it again). For users, this suggests an immediacy - what you did resulted in an action, but it’s not a bad action since things slow down before it stops.
Ease In and Out is exactly what it suggests: the majority of the movement happens in the middle of the timeline, the beginning and end are easing curves. I couldn’t think of a real-world corollary although I’m sure there are plenty. For users this is often a very pleasing movement because there’s nothing sudden on either side of the timeline, things move in such a way as to feel completely intentional.
With each of these broad categories there are different functions that result in different curves which you can play with for your intended purpose. But here are some thoughts I have about how they can employed to give your pages or apps some style. As a disclaimer, these are thoughts that should be tested contextually - A/B tests will surely help you know if users are understanding the intent of your design decisions.
If you’re building a light or “flat” design, one thing that can be interesting is making certain actions feel spring loaded. In narrative terms, it’s like the app was just waiting for you to click something, so it could respond. To accomplish this, you’d play around with Ease-Out functions - because they tend to spring into action and then wind down. This is perfect for menu reveals (like the oh so popular menu under the interface), as it makes the app feel snappy and responsive.
Another way you could subtly communicate with users is by adding a gravity to actions that are destructive or should involve caution. A longer transition time (.7s or .8s) plus an Ease-in timing function will make actions seem sloowww, psychologically communicating to users that it’s harder to do (as if the server did not want to perform the action). Google has done tests and discovered that a half second of delay greatly decreases user engagement. Sometimes, that’s the desired outcome.
If ever you are introduction new content to the page, motion can help it feel smooth and intentional. One way to do this is with the combination of an opacity transition and slight directional motion with an ease out function, if you’re introducing content, or ease-in if you’re removing. The reason this feels nice is that the content becomes visible after it’s already in motion, so from a visible perspective it is slowing down as it arrives into place. It’s subtle, but it feels right at certain times.
These are just 3 ideas, there are so many different ways to play with motion to make your interaction design more fluid, more comfortable, and sometimes even more whimsical.
So this has been a deep dive into motion that kind of touched on neuroscience, psychology, philosophy, and code. What the hell was the point?
Here’s what I hope you’ve taken away from this:
- Motion in interaction design is not just icing
- Users will use the information available to them to understand how to use our creations
- Intentional use of motion can give them information that otherwise is hard to come by.
- If you choose to use the z-axis metaphor, stick to it and be consistent
- Have fun! I’m not saying motion is a make it or break it aspect of interaction design, but I am saying it can be a really valuable tool.