Building Motion for the Web: Creating a Motion ‘Volume’ Scale

This article is part two of a series unpacking how motion is defined and implemented at Viget. The other articles in the Building Motion for the Web series are part one: In the 'Zone' and part three: Recipes for Design Success.

In our previous article, we spent time classifying some characteristics of motion to produce ‘zones’ or types of motion. We introduced two scales: information type (literal or abstract) and integration type (integrated or isolated). Now we’re going to introduce a new scale: amount of motion, like a volume knob — how loud do you want to crank it?

But not all music should be cranked to the same volume, just like not all experiences benefit from the same amount of motion. There are a few factors we consider in delivering the right amount of motion in an experience:

• Goals: What is the desired user experience?
• Planning: How much time should we plan to spend creating motion and interaction?
• Collaboration: Where are the technological complexity boundaries?

All three need to be aligned to create a successful implementation. By the end of this article, we’ll outline a framework that can be used as a way to inform each of these areas.

Goals: Picking the right ‘venue’ for your users

To continue with our music analogy: picking the user experience for motion is like picking a venue for an event. If we want the experience to be a thoughtful place, like a coffee shop or bookstore, we’d want the motion volume, like the music, set pretty low. Likewise, if we want the experience to be a joyful celebration like a party, we’d want it up pretty high.

The exercise here is to shepherd users toward the goals of your project. If there’s a mismatch between the expectation and the experience, it could lead to unnecessary or frustrating interactions. Imagine going to that coffee shop to study but they’re blasting hair metal at top volume, or going to a party and the music is almost inaudible. You may just walk right out of both situations. (You ever wonder why they play classical music in some stores?)

One metric we can use here is the balance of information to experience. Highly informational experiences will benefit from a lower motion volume, while something meant to be experienced and evoke emotions or a feeling will be more effective at a higher motion volume.

Another question to ask is whether the motion should be augmentative or integral. In an augmentative experience, the motion takes a backseat to the true objective but complements it, like soft music playing in a coffee shop to provide some masking of conversations. It doesn’t get in the way. But in an integral experience, removing motion would lessen the experience, like a party with no music. You’ve come here for the experience, so you expect it to take the front seat.

Planning: Creating the Space

Even the most dialed-in goals and brightest ideas will never materialize without the proper time to create them. So when discussing motion, it is essential to also talk about budget and timing — and to do it early on.

When we sit down with clients in the early stages of a project, we’re also listening to understand what kind of solution is going to most closely fit their needs. With our motion ‘volume’ scale, we can figure out a rough ‘mix’ of how much time and effort should be spent on motion and interaction. Like a ballpark estimate, these 'motion ballpark effort mixes' are based on high-level objectives that give us a range of effort we can use to help plan a project.

If we’re looking to build a highly experiential solution, we can expect to spend a good percentage of the allotted time and budget creating and fine-tuning motion. For an ‘integral’ experience, it may even take 20-50% of the total overall visual design and UI development time. 

But for an ‘augmentative’ experience, where we want the motion volume to be much lower, we might expect something south of 15% of total design and development time. This way we can spend more time nailing down critical parts of that experience, like Information Architecture or customizing the CMS to allow bespoke authoring workflows.

These ‘motion ballpark effort mixes’ are not meant to replace estimates but rather to give a quick sense of how much space should be protected in a timeline to implement the desired motion volume. If critical features and the 'motion ballpark effort mixes' don't fit in the project budget and timeline then we have an early opportunity discuss what really matters to the success of the project and course-correct.

By setting these expectations early on we can help avoid surprises and make sure we're creating the right kind of space for the right kind of work.

Collaboration: Boundaries of Play

There’s a funny thing that happens with motion: concepts that are easy to visualize and communicate can be hard to implement. Likewise, some complicated interactions wind up being easy to build. There’s a friction between concept and implementation that can be hard for any one discipline to overcome.

So how do we create safe boundaries of play? When does the designer know that they’ve crossed into something that will take exponentially longer to build?

Looking at how we implement motion, we can start creating ‘boundaries’ that coincide with this scale of motion volume that we’re building. These different methods each have limits that naturally mark where complexity can ramp up and require more effort to implement.

Native Browser Features

At the ground level, we have native browser motion affordances like:

• CSS animations and transitions
• Web Animations API via JavaScript
• SVG animations

These techniques can be powerful by themselves, require no additional libraries, and (with a lot of practice and patience) can do amazing things. This level excels at direct, functional animation and is a quickly growing category with exciting new features looming like View Transitions and native scroll-driven animations. But these native affordances start to show limits at intersections of requirements like:

• Multi-step animations
• Binding interactions in more complex ways (like scroll scrubbing, although perhaps not for long…)
• Staggering effects dynamically for non-static elements
• Responding to complex user input
• Animating several properties that aren’t GPU-accelerated (transforms, opacity, some filters, etc.).

JavaScript Motion Frameworks

When we need to push past native implementations, we turn to motion-specific frameworks like:

• Greensock
• Anime.js
• Or a framework-specific library like Framer Motion or React Spring

These libraries are powerful frameworks for creating dynamic motion interactions and have been battle-tested for performance and speed. With these tools we can orchestrate complex 2D animations, create chaining effects, and bind interaction to multiple user inputs, but these solutions start to show limits in boundaries like:

• 3D animation
• Complex data visualization
• Physics simulations
• Orchestrating numerous highly-complex animations (something like a video game).

Specialist Technologies

At this level, we’re looking into interactions requiring specialist solutions like:

• ThreeJS
• D3.js
• Matter.js
• Babylon.js
• Or even a rendering engine like PixiJS.

From this level, we’ll be pushing the boundaries of what’s possible on the web with 3D animation, complex visualization, and deeply rich interactions.

This progression of limits and tools to push past them gives us three levels of implementation that we can attach to complexity:

1. Native browser affordances: Direct, effective, and performant motion.
2. JS/Framework powered: Orchestrated complex 2D motion.
3. Specialist technologies: 3D and specialist motion patterns.

Crank up the volume… I mean… tiers!

Combining our target user ‘venue’ goal, our planning expectations, and collaboration boundaries, we’ve arranged motion volume into five progressing tiers. Each tier has an appropriate use and an appropriate set of technology to achieve it.

There are two main groups: Augmentative and Integral with 5 tiers in total.

Tier 1: Augmentative / Targeted Browser Native Features

‘Targeted’ doesn’t mean NO motion, but rather restricting it to effective motion patterns. This tier focuses on using effective and direct means to convey information.

• Good for: Direct motion, basic system state indication.
• Technology: Primarily CSS transitions and animations.
• Ballpark Effort Mix: 1-7%
• Recommended for: Informationally dense experiences where too much motion could be a distraction

Tier 2: Augmentative / Advanced Browser Native Features

This tier remains in the native feature set but pushes up against the upper edges of what’s possible. Some of the newer APIs like WAAPI, Scroll-Driven Animations, and View Transitions make the boundary between this tier and the next tier a bit fuzzy.

• Good for: Simple dynamic interactions
• Technology: CSS + JS with Native APIs (Web Animations API, Scroll-Driven Animations, etc.)
• Ballpark Effort Mix: 5-15%
• Recommended for: Content and marketing experiences

Tier 3: Augmentative / JS assisted

Here we’ve moved into motion frameworks, allowing us to animate more properties and orchestrate more complex interactions.

• Good for: Orchestrating complex, multi-step animations, creating emotive interactions.
• Technology: JS Motion Frameworks (GSAP, Framer, etc)
• Ballpack Effort Mix: 10-25%
• Recommended for: Dynamic content, product, or company sites; experiences that reinforce brand ideals beyond the purely visual.

Tier 4: Integral / JS powered

While we’re still using motion frameworks in this tier, this boundary is marked by the point when motion becomes integral to the experience, typically requiring more complex motion patterns.

• Good for: Motion-driven experiences, seamless integrations
• Technology: JS Motion Frameworks (GSAP, Framer, etc)
• Ballpark Effort Mix: 20-35%
• Recommended for: Advanced product and promotional websites where ‘feel’ needs to be imparted quickly.

Tier 5: Integral / Specialist Technologies

This tier indicates we’re going all-in on a specific pattern or method that may require a specialist’s skill set, such as 3D modeling and animation.

• Good for: Complex motion with interacting pieces, or a high volume of interacting parts.
• Technology: Specialist Frameworks (ThreeJS, D3, Phaser, etc.)
• Ballpark Effort Mix: 30-50+%
• Recommended for: Highly specific promotions; highly immersive experiences; purpose-built games.

Exceptions and Loopholes

These tiers are not intended to cover all situations, but to serve as a best-fit shorthand to help shape the conversation around motion.

If we create a time-intensive, integral-style experience using just CSS animations, where does it fit? What about animation formats with editing tools and runtimes like After Effects + Lottie or Rive?

It is possible with enough effort to cross these tier boundaries with technology other than what’s specified — but that’s the exception, not the norm. If we have an opportunity to go deep on something, the goal would be to adjust the planned effort to match the expected outcome.

So, that integral CSS animation experience might wind up requiring something more like a Tier 4 effort even though it uses a different technology set.

Likewise, the runtime-based interactions (Lottie/Rive) can also span multiple tiers based on how much motion we’re attempting to create, but the time for these efforts may shift to time spent in After Effects and Rive rather than in the development implementation. The effort is similar, it’s just a difference in where the time is spent.

Planning with Cheat Codes

Like we introduced at the beginning of this series, being able to name something, classify it, and standardize expectations around its meaning helps create a shared understanding that can be used like a cheat code. Consider the following brief using our measures from this and the previous post:

“We want to create a Motion Tier 3 experience with several custom set-piece animations and a high degree of emotive functional animation patterns.”

We now know it’s likely that:

• We’re using a motion framework to build interactions, but they will be augmentative, rather than integral.
• We’ll be creating several custom, illustrative, but self-contained, animations that help convey editorial meaning.
• The elements as a whole are expected to move in a way that goes beyond simple on/off states and carry some aesthetic (abstract/emotional) impact in HOW they move.
• We expect somewhere between 10-25% of the design and development effort to be spent toward these goals.

All from a single sentence! Not quite Konami-level cheat codes, but we’re getting there!

In the next part of this series on motion, we’ll outline some techniques for the actual work of collaborating on motion as well as what types of artifacts are helpful (and a bit of what’s not!)