Chapter 17. Designing, Prototyping, and Animation in Component Libraries

Our modern frontend workflow has matured over time to include design systems and component libraries that help us stay organized, improve workflows, and simplify maintenance. These systems, when executed well, ensure proper documentation of the code available and enable our systems to scale with reduced communication conflicts.

But while most of these systems take a critical stance on fonts, colors, and general building blocks, their treatment of animation remains disorganized and ad hoc. Fortunately, we can leverage existing structures and workflows to reduce friction when it comes to animation and create cohesive and performant user experiences.

In this chapter, we’ll break down how to design, plan, and implement animations.

Designing an Animation

Animations, like any other facet of the web, must be designed. You can refer to the following articles on Smashing Magazine for details as to why:

As web developers, we think about the effects of typography, layout, interaction, and shifting viewports, but when incorporating animation we have another factor to consider: time.

It’s not just an extra aspect to consider, either: it increases the complexity of each of the aforementioned parameters exponentially. But rather than viewing this as a heavy mass of ideas, we can bake animation into the core of our user experience process to create dazzling, exciting, and engaging work that pushes boundaries and collectively elevates the medium of the web.

Working with the Language of Motion

Everyone has different ways of working and nothing is gospel, but here are a few key points that I have discovered after working at this for a while.

First, pay attention to how stuff moves. This one might make you laugh, it’s so simple. But how often do you really watch water pour into a glass? What makes one person’s gait so recognizable?

Most people start with a ball bouncing, and that’s a great exercise, partly because the simplicity can show you character, weight, and dynamism. Figure 17-1 and its corresponding demo show two balls bouncing: can you guess which is hard and which is soft?

Figure 17-1. You can tell the difference in “character”—how soft the material is, for instance—even though both balls are bouncing at the same rate

How do you know which is which? First, there is the elasticity of the objects. One stays consistently round; the other is manipulated based on the impact. What else? Well, there’s the movement: one seems fairly rigid, and the other is more playful. Though they have the same timing, their physical motions imply different masses. Easing functions convey the density of the object.

Note also that even though they have the same timing, the easing function is used in such a way that they have different keyframes. If I placed a strobe light on these balls, you would see them at different places during the same time period. This concept has a term in old cel animation: spacing. See Figure 17-2 and its corresponding demo.

Figure 17-2. By showing the outline, we can see the “spacing” and the difference between each

This can also come in the form of the motion of secondary elements. If someone shakes a glass, how is the water inside affected? When someone kicks a rock, how does the rock express the force of impact? There’s a great example of elemental motion design available on Dribbble.com.

As Hans Bacher discusses in Dream Worlds (Focal Press), when animators were working on Beauty and the Beast they were flown to London and France to observe the styles of these places. You might not have this kind of budget (but if you do, take me with you!); luckily, the internet has plenty of visual, historical, and spatial information for you to work from.

Follow your interests. If you have any leeway at all in the content of the animation, use that to your advantage. Genuine interest and enthusiasm are easily conveyed. You’re more likely to follow a project through if the content excites you.

Rein It In

Unlike fonts, colors, and so on, we tend to add animation in as a last step, which leads to disorganized implementations that lack overall cohesion. If you asked a designer or developer to create a mockup or build a UI without knowing the fonts they were working with, they would dislike the idea. Not knowing the building blocks they’re working with—leaving out something so fundamental at the start—means that the design can fall apart or the development can break. It’s the same with good animation. Avoid the temptation to load up your design with flashy animations at the end; with animation, less is often more.

The first step in reining in your use of animation is to perform an animation audit. Look at all the places you are using animation on your site, or the places you aren’t using animation but probably should be. (Hint: perceived performance of a loader on a form submission can dramatically change your bounce rates.)

Not sure how to perform a good audit? Val Head has a great chapter on it in her book Designing Interface Animations (Rosenfeld Media), which contains buckets of research and great ideas.

Even some beautiful component libraries that have animation in the docs make this mistake. You don’t need every kind of animation, just like you don’t need every kind of font. Having too many options bloats your code. Ask yourself questions like “Do I really need a flip 180 degree animation?” I can’t even conceive of a place on a typical UI where that would be useful, yet most component libraries that I’ve seen have a mixin that does just this.

Which leads to…

Have an Opinion

Many people are confused about material design. They think that material design is motion design, mostly because they’ve never seen anyone take a stance on animation before and document these opinions well. But every time you use material design as your motion design language, people look at your site and think GOOGLE. Now that’s good branding.

By using Google’s motion design language and not your own, you’re losing out on a chance to be memorable on your own website.

The impact of Google’s material design, in my mind, lies less with the design language itself, and more with that it was the first major industry example of a company incorporating animation guidelines in its branding. For the first time, people started thinking about the style of animation as a functioning entity that had a voice—one that must be designed in cohesion with everything else.

If your company is a well-trusted, stoic insurance company, the character of any animation on your site is going to be less flamboyant and more formal, and you’ll tend to use linear eases rather than bounce or elastic motion. But with branding that’s more comfortable and friendly, on a site like Zendesk’s or MailChimp’s, the form should follow the branding and accordingly have more lively animation, while still communicating effectively; something with the charm of Chris Gannon’s loaders is simple, yet exciting.

If you think back to the first time you cried because of a fictional character, it was likely animated. In Aarron Walters’s Designing for Emotion (A Book Apart), he discusses how emotion is tied to the limbic system: we are more likely to remember something that becomes part of our emotional memory. Chapter 7 of his book goes into hard numbers on how much return on investment can be gained by focusing on the impact of users’ emotive experiences.

If you have a static piece of content that looks like a Photoshop mock-up on a web page, the viewer engagement stops where your CSS does. Animation allows us to show rather than tell, a vital tactic considering users typically only scan body content. It allows customers to attach themselves to our UIs personally, for their needs to unfold before them. If done correctly, the potential for positive engagement is staggering.

What does having an opinion on motion look like in practice? It could mean you’ve decided that you never flip things and that your eases are always going to glide. In that instance, you would put your efforts toward finding an ease that looks like it glides and pulling out any transform: scaleX(-1) animations you find on your site. Across teams, everyone knows not to spend time mocking up flipping animations (even if they’re working on an entirely different codebase), and to instead work on something that feels like it glides. You save time and don’t have to communicate again and again to make things feel  cohesive.

Elevate This

Animation has to be taught to live on its own as a substantial part of the development process. We can accomplish this in several ways:

  • Animation has to be designed just as the rest of the page is: with mock-ups, color palettes, storyboards with wireframes, and its own composition.
  • Your design process should follow the same logical structure as your code.
  • Animation must move toward being informative, appealing to rationality and guiding users’ attention.
  • Animation should follow branding guidelines, be part of a living style guide, and appeal to users’ emotions.
  • We shouldn’t reinvent the wheel. Animation has existed outside of the web for ages. (Yes, you can go watch Toy Story for “research” purposes.)

Because animation is so engaging, it’s easy to overdo it, but not everything on the screen needs to be animated. You don’t start a war with the secret weapon. Animation can be a way of signifying the end or beginning of something, as well as directing your attention. With animation that is purposeful and planned according to viewer engagement, performance budget, and branding, we can elevate the medium. Val Head discusses this very clearly when she writes about invisible animation. Good animation should not seem out of place, nor be an afterthought.

Check out Oleg Solomka’s Bubble layout demo (it’s nice with the sound on): the animation is delightful enough to keep you engaged as you navigate, but gets out of your way while you’re reading the content. Keep in mind that the purpose of these tutorials is to showcase a particular method; in the wild, the implementation can even be toned down slightly to accommodate a professional, yet engaging effect.

Prototyping

After design, the next step is planning.

Backward to Move Forward

Before you begin animating, you must storyboard. Storyboarding is a very important part of the process because it allows you to work modularly in your code, in scenes. It allows you to plan out timing. And it allows you to work backward: to draw something and then slowly unveil it.

A common misconception is that your storyboards have to look like polished comics. I think that’s often why people don’t want to make them: they’re scared of drawing; they’re scared that their work has to look perfect; they’re scared of spending all of their creative energy in the planning process, and they just want to start working on the project. I understand this completely. To avoid all of it, I encourage you to forget the Platonic ideal of a storyboard.

I was a scientific illustrator for the Field Museum of Natural History and Stanford. I was a professor of painting at a college. Can I draw? You betcha. Figure 17-3 is what my storyboards look like.

Am I ashamed of this? Not in the slightest. That storyboard took me 45 seconds and allowed me to understand and edit up front what I was going to spend many days making. Without it, my workflow would have doubled. Storyboards exist behind the scenes and are for personal communication. I’m not saying you can’t create beautiful standalone work like Rachel Nabors, just that you don’t have to.

Figure 17-3. Ugly storyboards are really helpful

Let’s revisit our discussion about user empathy. You can accomplish this with storyboarding all of a user’s interaction, from beginning to end, as well. Consider the article “Story Map” by James Buckhouse. A story map takes you through the entire experience of visiting your site and becoming a customer, from beginning to end. It’s a storyboard with muscle, one where you see the whole picture of a user’s visit and therefore can make purposeful decisions based on desired direction and outcome.

It’s probably not new to hear about storyboards in animation: little comics that allow animators to break down tasks scene by scene. But did you know that there are also color scripts? Just as you design color and overall branding for your site, animators at Disney and other animation houses create color scripts that work well with the colors of their main characters and inform the scene. You should be doing this, too.

This means you should spend some time on Adobe Kuler, crafting color swatches. It takes a small amount of time at the start, but saves buckets while you’re working. We all know color is meaningful. Working with it is made so much easier in CSS with preprocessor variables; use them to your advantage.

Tools

First, let’s develop our vocabulary around planning an animation, because there are differences in what’s available and when you want to use each tool.

Thumbnails are small notes to yourself (Figure 17-4). They don’t have to be legible at all—even to you. They should take a matter of seconds, and are extremely basic so that you can iterate quickly and throw out ideas without any time wasted.

Figure 17-4. Thumbnails are very sketchy notes to yourself that take seconds and can be thrown away

Storyboards are one step up in fidelity from thumbnails. They are slightly more discernible, but not by much (Figure 17-5). You could feasibly show them to another person and communicate with them, but they aren’t appropriate for a presentation unless it’s very casual. Even if they’re sketchy, they are likely to show many scenes.

Figure 17-5. Storyboards are slightly more high-fidelity, but don’t have to be full drawings; you can actually communicate an idea to others with a storyboard, even if it’s not well drawn

Prototypes are  moving versions of your proposed animation. In order to not build out the whole thing, you have a few courses of action. One is a low-fidelity prototype, with just basic shapes moving around to get the motion down (Figure 17-6). This is so that you don’t have to build out or incorporate the whole site.

Figure 17-6. GIF mockup of basic UI shapes moving by Yaroslav Zubko

There’s a great read by Yaroslav Zubko about how to make prototypes with basic UI patterns and shapes. There’s also a moving version of the GIF.

Another way of working is to take a screenshot of the site or a flattened mockup and set it as a background image, absolutely positioning the elements that need to move on top of it and working with the motion. That way you can get up and running quickly with something that communicates to people in a presentation: it doesn’t require much time, but it also looks pretty close to what it will eventually be. This can be good for stakeholder meetings.

There are also several very good tools for prototyping available if you’re trying to collaborate between design and engineering, including:

Personally, I just go with straight code—I feel that some of these tools take time to learn that I’d rather devote to development practice. This has the added advantage that if one of your prototypes gets buy-in, you can clean up the code and use it in the actual codebase without having to rewrite anything or start over.

“Murder Your Darlings”

“Murder your darlings” is an old quotation traced back to Arthur Quiller-Couch, but it’s valid in design. Don’t be afraid to remove or revise some of the aspects of your work that seem precious. You’re never going to get things right the first time, so relax and make some mistakes. Whether you’re a designer, a developer, or both, chances are you weren’t as good in the beginning as you are now and it took a lot of ugly stuff in the middle to get to where you are. That’s OK. This means trying different types of animation on for size, and messing all of those up, too. Did you learn JavaScript by only programming one kind of interaction using only one library? No. Did you learn to design only using one composition? I certainly hope not. The same principles apply to learning to animate as well.

Perhaps you can have both graphics editor and text editor open at the same time. You need to move fluidly back and forth between them. Don’t be scared of retracing your steps, adding things, or editing. You will need ready access to your tooling for tasks like optimization, so you can move quickly through them. The further you put these things away from you, the lazier and sloppier you will become about adjusting, editing, and re-creating images or code as you need to. And you will need to.

You’re going to have to redo your timing and easing a hundred times. Personally, I find it easiest when I’m using a tool like GreenSock’s TimelineLite to move pieces around. It lets you stack, stagger, overlap timings, and even animate full scenes

CSS is great for very small UI interactions; in fact, I really recommend it for those use cases because you don’t need to load other resources. However, if you have more than two animations set on an object, you should probably consider switching over to GSAP. The ability to move a little forward or behind the last animation, or set them to fire at the same time no matter what, makes it too powerful a tool to avoid, particularly when you need to rehearse and readjust the timing. CSS makes you recalculate all of your values if something in your animation changes at the start, but the GSAP timeline does not.

This wouldn’t be such a major issue if timing weren’t so vital. Have you ever noticed how some comics have frames where there is no action? They create the illusion of a pause, and your brain treats it as such. Timing is vital for comedy, for whimsy, but also for UI animation that appears seamless or natural.

Just like in all design, the parts of an animation that look simple and effortless are sometimes the hardest to accomplish.

Design and Code Workflows

It’s clear that storyboarding pays off in the design and planning stages of animations, but it can easily reap rewards in your code architecture, too. If your code reflects the same logical organization you use for your design, you gain all the benefits of clear, legible structure; and the more it mirrors the design process, the easier it is to share implementations between the two.

Functions should be named according to the scene you are in: even “sceneOne” will do. Similarly named variables look nice and neat, but they’ll trip up you and your team in the long run, particularly as an animation gets more complex. Naming form elements as the characters they portray, and setting up your code in a clear way that mirrors your design, means less worrying about scoping problems, and more concrete divisions between JavaScript and Sass variables and assignments. It’s also particularly helpful at the end when you have to go back in and adjust something: you will easily find your place again and know what follows.

Animations in Component Libraries

Sometimes people don’t incorporate animation into a component library because they aren’t sure how, beyond the base hover states. All animation properties can be broken into interchangeable pieces. This allows developers and designers alike to mix and match and iterate quickly, while still staying in the correct language. Here is a basic boilerplate structure (in Sass) for a basic set of CSS animation patterns (apologies for the length):

// ----   timing  ----//
$class-slug: t !default;

@for $i from 1 through 7 {
  .#{$class-slug}-#{$i} {
    animation-duration: 0.8 - (0.1s * $i);
  }
}

// ----   ease  ----//
$easein-quad: cubic-bezier(0.55, 0.085, 0.68, 0.53);
$easeout-quad: cubic-bezier(0.25, 0.46, 0.45, 0.94);
$easein-back: cubic-bezier(.57, .07, .6, 1.71);
$easeout-back: cubic-bezier(0.175, 0.885, 0.32, 1.275);

.entrance {
  animation-timing-function: $easeout-quad;
}
.entrance-emphasis {
  animation-timing-function: $easeout-back;
}
.exit {
  animation-timing-function: $easein-quad;
}
.exit-emphasis {
  animation-timing-function: $easein-back;
}

// ----   fill mode extend ---//
// we probably want this so we'll create a class that can be @extended as a 
// default into our animations
.anim-fill-both {
  animation-fill-mode: both;
}

// animations
@keyframes pop {
  0% {
    transform: scale(0.9) translateZ(0);
  }
  100% {
    transform: scale(1) translateZ(0);
  }
}

.pop {
  animation-name: pop;
  @extend .anim-fill-both;
}

@keyframes unpop {
  0% {
    transform: scale(1) translateZ(0);
  }
  100% {
    transform: scale(0.9) translateZ(0);
  }
}

.unpop {
  animation-name: unpop;
  @extend .anim-fill-both;
}

You can also take a look at the full pen.

Create timing units, similar to h1h2h3. In a system I worked on recently, I called these t1t2t3, etc. t1 was reserved for longer pieces, while t5 was a bit like h5 in that it was the default (usually around .25 seconds or thereabouts). Keep animation easings for entrance, exit, entrance emphasis, and exit emphasis that people can commonly refer to. This, and the animation-fill-mode, are likely to be the only two properties that can be reused for the entrance and exit of the animation. Use the animation-name property to define the keyframes for the animation itself. I would recommend starting with five or six before making a slew of them, and see if you need more. Writing 30 different animations might seem like a nice resource, but just like with your color palette, having too many can bulk up your codebase unnecessarily and keep it from feeling cohesive. Think critically about what you need here.

The previous example is pared down, but you can see how in a robust system, having pieces that are interchangeable cached across the whole system would save time for iterations and prototyping, not to mention making it easy to make adjustments for different-feeling movement on the same animation easily.

One low-hanging fruit might be a loader that leads to a success dialog. On a big site, you might have that pattern many times, so writing up a component that does only that helps you move faster while also allowing you to really zoom in and focus on that pattern. You avoid throwing something together at the last minute, or using GIFs, which are really heavy and also look mushy on a Retina display. You can make singular pieces that look refined and are reusable.

React and Vue implementations are great for reusable components, as you can create a building block with a common animation pattern, and once created, it can be a resource for all. Remember to take advantage of things like props to allow for timing and easing adjustments like we have in the previous example!

Buy-in

Sometimes people don’t create animation resources simply because it gets deprioritized. But design systems were also something we once had to fight for. At the CSS Dev Conf in 2016, Rachel Nabors demonstrated how to plot out animation wants versus needs on a graph (reproduced with her permission) to help prioritize them (Figures 17-7 and 17-8).

Figure 17-7. Wants versus needs (courtesy of Rachel Nabors)
Figure 17-8. Level of difficulty in implementation (courtesy of Rachel Nabors)

This helps people you’re working with figure out the relative necessity and workload of the addition of these animations and think more critically about it. You’re also more likely to get something through if you’re proving that what you’re making is needed and can be reused.

Good compromises can be made this way: “We’re not going to go all out and create an animated ‘About Us’ page like you wanted, but I suppose we can let our users know their contact email went through with a small progress and success notification.”

Successfully pushing smaller projects through helps build trust with your team, and lets them see what this type of collaboration can look like. This builds up the type of relationship necessary to push through projects that are more involved. It can’t be overstressed that good communication is key.

Time Is Money

Animation is often considered an afterthought in the corporate development process. We make mock-ups, pass them, develop them, and at the very end add an animation on top. Because of this, animated components can often look like what they are: whipped-cream fluff. It is only when animation is baked into the substance of layout, storyboard, and development processes that it holds meaning as a performant and substantial piece of a web experience.

Studios like Active Theory get away with engaging their clients with this conversation earlier in the design process because of their own branding: “We make bold things for the big guys.” Clients who seek out Active Theory’s work know they are paying for a blockbuster, knock-your-socks-off kind of web experience. This isn’t going to be the case 98% of the time.

How do we change this? Again, the way that we usually do. In salesman’s terms, that means “increase the ROI.” In developer terms it means elevating the product to something that’s useful, increases engagement, or has a positive experience, and then it won’t be a waste of time or money. For more information on how to communicate with clients effectively, check out Mike Monteiro’s books You’re My Favorite Client or Design Is a Job (A Book Apart).

Before we gleefully skip into the sunset and make everything on the page move, we need to commit to some action items to make an effective change.

The first is communicating effectively with our clients. This does not mean railroading them into adhering to our beliefs. It means explaining the possible gains, assuring them we will A/B test our interfaces and produce measurable results, and meeting them halfway on time allowances.

Consider the form we worked on earlier. Show your client prototypes of two forms—you can show them other people’s work as an example if you don’t have the time to build; CodePen has a great design patterns resource. One form will present itself without feedback on the button or progress, or a snappy success UX; the other will incorporate all the lessons we’ve learned here. Or better yet, use A/B testing (usability testing with different variants) to prove the form with animation to be a more effective tool. Solid numbers are always better than subjective opinion, which can be shaped around trends, ignorance, or past bad experiences due to poor implementation.

Once you get the go-ahead, you can plan. You have performance budget allowances in new categories now:

  • Time
  • Experience
  • Performance
  • Color
  • Composition
  • User’s time

This may seem overly complicated, but you should be able to give yourself basic ballpark figures within seconds for each of these, and they should be considered before you move on. Do you lack experience? Then you’ll need a little more time, as with most things. Do you currently have a lot of other heavy assets on the page? You will need to be very careful loading up images, SVGs, scripts, and animation libraries. Does your site already have a very rich palette? You’ll need to reuse those color variables.

The Sky’s the Limit

Frank Thomas and Ollie Johnston’s Disney Animation: The Illusion of Life (Disney Editions) begins with one of my all-time favorite quotes from Walt Disney: “Animation can explain whatever the mind of man can conceive.” This quotation is so spot-on because it really is animation’s strength: you can make anything happen. You can create and destroy worlds, excite or condemn.

That said, there is a lot to consider. Animation will never be more than empty calories if we don’t design it the way we do other aspects of UX. As with our other tooling, it is a loss leader: we’ll spend more time getting the variables and parameters set up at the start. But with that preparation, the character will tell us which road it would like to take during implementation, even if the character is a UI or branding.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.188.216.249