Click-to-play

For a complete journey of the object, click on it 21 times.

It follows a predefined path that guides where the object will move. Each click advances the object one step along this path (Per-click-Per-move), and the current click count is displayed on the object itself.

The journey is designed around basic geometric shapes:

• Rectangular path - moving along straight edges and corners.
• Diagonal path - cutting across at an angle.
• Diamond shape - a rotated square for a distinct movement pattern.
• Circular path - a smooth loop that emphasizes continuity.
• Each click moves the object one step (Per-click-Per-move).
• The current number of clicks will be displayed on the object.

This setup demonstrates how interaction can be broken into predictable, step-based movements, making the experience both visual and measurable. It's not just about moving an object, but about understanding how different path structures affect the sense of motion and interaction.

Case study:

From Choppy to Smooth - Tuning Our Animation Engine

Context / Problem

We set out to build a custom animation system for the web. The vision was simple: fluid motion that feels natural, no jitter, no lag.

Our first implementation used setInterval(), and while it technically moved things, it quickly became clear it wasn't keeping in rhythm with the browser's rendering cycle. Motion looked stuttered, like a record skipping on the turntable.

On top of that, we had to keep reaching for manual adjustments - adding +3 here, subtracting -24 there - just to make the timing or positioning feel right. It worked, but it felt more like patching leaks than steering the ship.

Approach

We experimented with a few strategies:

• Using timestamps with requestAnimationFrame instead of setInterval().
• This gave us frame-by-frame control and let the animation sync perfectly with the browser's repaint cycle.
• Smoothness immediately improved, like swapping a cheap metronome for a tight jazz drummer.
• Refining position updates with time deltas.
• Instead of moving elements a fixed step each tick, we calculated movement based on elapsed time.
• This made motion speed consistent even if frame rates fluctuated.
• Manual offsets became seasoning, not survival.
• We still used occasional pixel nudges (+3, -24) - but now they acted as fine-tuning to style the motion, rather than bandaids to fix broken timing.

Result

The new system produced animation that was buttery smooth, consistent across devices, and more responsive to interaction.

• Performance win: Less CPU usage, because the browser wasn't fighting with setInterval().
• Cleaner workflow: We no longer dreaded manually tweaking numbers; most of the math flowed naturally from the time-based logic.
• Better visuals: Motion became expressive instead of robotic, more in line with our creative goals.

Reflection / Learning

Timestamps beat setInterval(). The key was realizing animation isn't about firing code every N milliseconds - it's about syncing with the browser's paint rhythm.

Manual adjustments are like jazz improvisation. They still have their place, but they should embellish the structure, not hold it up.

Building smooth animation is part art, part engineering. The tech gave us the precision, and the fine-tuning gave us the vibe.