Skip to content
← Writing

20 January 2024·6 min read

Creative Coding: From a Bouncing Ball to Motion With Purpose

How a beginner's exercise turned into the way I think about motion on the web, the phase where I put animations on everything, and what I actually reach for today.

The first interactive thing I ever put on a web page was a ball. I was following a tutorial to learn how code could move something on a screen, and the exercise at the end was to make a circle travel across a canvas and bounce off the edges. That was it. A position, a speed, and a check at each side.

The exercise, running: exactly the code below. Click or tap anywhere and the ball heads there.

I remember how much fun it was. I had written a small rule, and the screen kept following it after I stopped typing. Most of what I have made since that moves on a screen started with that feeling: things are simply nicer when they respond to you.

The exercise

In p5.js, the library the tutorial used, the whole thing fits on a few lines. setup runs once and makes the canvas. draw runs about sixty times a second, moves the ball, and turns it around when it reaches an edge. mousePressed runs when you click, or tap on a phone, and sends the ball toward that spot.

let x = 100;
let y = 80;
let vx = 3;
let vy = 2;

function setup() {
  createCanvas(600, 300);
}

function draw() {
  background(245, 242, 235);
  x += vx;
  y += vy;
  if (x < 20 || x > width - 20) vx = -vx;
  if (y < 20 || y > height - 20) vy = -vy;
  circle(x, y, 40);
}

function mousePressed() {
  vx = (mouseX - x) / 20;
  vy = (mouseY - y) / 20;
}

What I did not see then is that this is already the whole idea. Nearly every animation I build has the same shape: some state, a small rule that updates it every frame, and a picture drawn from the state. The rules get more interesting over time. The shape stays.

When I got carried away

I should be honest about the stretch that followed, because it shaped everything after it. Once I could make things move, I wanted everything to move. The tool that pulled me in was Hydra, a small language for live-coded visuals, the kind people improvise on stage while musicians play. You type a line and an oscillator begins to breathe colour across the screen; you chain a modulator to it and the picture folds into itself like liquid. It is hard to describe how absorbing that is until you have lost an evening to it. I lost quite a few.

The trouble began when I carried those visuals back to my everyday work. I now had all these beautiful, shifting backgrounds, and I put them on pages. Behind text, behind forms, behind things that were only ever meant to be read. Nothing was allowed to hold still. I had learned something new and was eager to use it everywhere, which is a lovely way to learn and a poor way to design.

Two things brought me back. The first was watching people use those pages: they were looking past my visuals, trying to find the button. The second was noticing that the sites I admired did the opposite. They were calm, and they moved in one place, at the right moment, and that single movement said more than my whole screen of them. So I began taking things away. Most of the backgrounds went. The ones that stayed were given a purpose: a cursor that reacts, a field of threads that welcomes you in and then steps aside, a row that lights up when it is yours.

I still catch myself now and then. There is a folder of Hydra sketches on my laptop that no client will ever see, and I open it more often than I would admit.

What stayed with me

Mostly this: interfaces are more enjoyable when they feel alive, and the feeling comes from restraint, not from volume. A cursor that reacts, a line that drifts, a page that answers a scroll with a little motion. None of it is necessary, and all of it makes a thing nicer to use, as long as it stays calm.

There is a bit of maths behind the nice ones, and I do enjoy that part. A sine wave makes a very good sway, and a noise function makes a line wander in a way that looks natural rather than random. You do not need much of it, and you notice quickly when there is too much.

Two habits came from all this. One is respect for the frame: sixty times a second is not a lot of time, and a sketch that stutters tells you where the cost is. The other is keeping things small. The sketches I like best are a couple of simple rules that interact, and when something looks busy the fix is nearly always to take a rule away. Motion as an accent, sleek and placed with care, not as wallpaper.

What I actually use

I want to be honest here, because lists of tools are easy to inflate. This site is where most of my creative coding lives right now, and it uses a small set of things:

  • The canvas API, plain, for anything that is a bunch of shapes changing every frame: the counter in the intro, the figures in my articles, the ball above.
  • Raw WebGL with a small shader for the thread field that moves through the site. No library, one fragment shader, a handful of values passed in. It looked intimidating until I tried it; then it felt like the canvas again, only faster.
  • Framer Motion for the everyday choreography of a page: things arriving, leaving, and easing into place.
  • The Web Audio API, which I picked up for this site: small sounds that follow the cursor, and the page's soundtrack running backwards when you scroll up.

p5.js is where I started and it is still what I would hand to anyone who wants to begin. Hydra is the one I love and rarely get to use, which is probably for the best. I have used Three.js when a project needed real 3D, and I keep it in reach, but I do not use it every day and I would rather say that than pretend.

If you want to try

Open the p5.js web editor, which runs in the browser and needs no setup, and make the ball. Then change one thing at a time: give it a trail, let it follow the mouse, add a second ball, make them repel each other. Each change is a small rule, and each one teaches you something about the last.

That ball is still bouncing somewhere in most things I make.

More notes
from the work.

All writing→