Skip to the content

#HeyInternet

Live numbers, moving dots, and the animation that can’t keep up

When something changes faster than it can animate, stop animating it

11-minute read

Welcome back to #HeyInternet, where the questions come from you and the answers get written where anyone can read them. This one is about a map, a score, and a delivery rider who’s never quite where the app says.

We hear this one often, from anyone who’s ever built a screen that updates on its own:

We built a screen that updates live: a rider on a map, a running score, a list that re-sorts as new orders come in. Every change is animated, and it looks lovely in the demo. But people keep telling us it feels laggy and “a bit off,” and one of them said the dot on the map is never where the rider actually is. What are we doing wrong?

Abraham, design engineer at Internet Labs, about to spend two thousand words defending things that hold still:

Hey,

Good question, and your tester is right: the dot isn’t where the rider is. Short answer: your animations are longer than the gaps between your updates, so most of what’s on screen is a picture of the past. When something changes faster than it can animate, stop animating it: show the newest value the instant it arrives, and save the motion for when the pace drops. One caveat, since I haven’t seen your screen: this is the general case, but I’d bet on this cause before any other.

Think of a radio commentator calling a football match. The good ones have a rule they never say out loud: describe the ball where it is, not where it was. When play is fast, the sentences get short. “Wide left. Cross. Cleared. Corner.” When the pace drops, because someone is standing over a penalty, the sentences get long and the voice gets low, and you can hear the whole ground holding its breath. (The replay comes after the play. Never during it.)

A bad commentator is the one still describing the lovely pass while the goal is being scored. You’re hearing the past, beautifully described, while the present happens without you. That’s what a slow animation on a live screen is, and I think it’s the most common motion mistake we see: commentary that can’t keep up with the game.

A block behind

Here’s the moment your tester meant. Say the rider’s phone sends a new position every two seconds, and the dot on your map glides toward each new spot over three seconds. Sounds gentle, doesn’t it? I’d have said so too. Before the glide has finished, the next position has already arrived, so the dot turns and starts gliding toward that one, and it never gets there either. The dot is permanently en route to a place the rider has already left.

You won’t see this in the demo, where the rider is a test file that moves politely. You, waiting for your dinner, see it every time: the dot rounds the corner a few seconds after the bike does, and you learn, without being able to say why, that the map is a bit of a liar. Is that a small thing? I think it’s the whole thing. A live screen has one job, which is to be true now, and an animation longer than the gap between updates makes it untrue by design.

How this goes wrong: say the connection hiccups for ten seconds, then delivers five positions at once. If every position gets its three-second glide, the dot now zigzags across the map for fifteen seconds after the rider has knocked on the door. That’s a commentator describing a pass from three plays ago.

How fast is fast?

Our rule of thumb is one comparison, and it’s the first thing we’d ask. How long does the animation take, and how long is the gap between changes? If the animation is longer than the gap, it can never finish, and what’s on screen is never the truth. If it’s shorter, you’re probably fine. That’s it, and I’d write it on the wall.

A few numbers make the comparison easier. A phone screen redraws about 60 times a second, so one frame lasts roughly a sixtieth of a second (the newer phones redraw 120 times a second, so half that); the Wikipedia page on refresh rates has more. Anything that happens inside about a tenth of a second feels instant to you; the Nielsen Norman Group’s three response-time limits have said so since the nineties. And a gentle glide tends to run a third of a second or more, which is where the trouble starts.

So which things change slowly enough to move? A score in a football match changes a handful of times in ninety minutes; animate it however you like. But a “likes” counter on a livestream can change several times a second, a rider’s position changes every couple of seconds, and a finger on a slider changes position dozens of times a second. Those three can’t afford a glide, because the glide would always be describing the last play.

Jump, then decorate

What does “stop” look like in practice? Three things, and I’d pick by pace.

For anything that changes in bursts (the counter, the list, the badge), the rule is simple: if the last change came less than one animation ago, skip the animation and just set the new value. The first change in a quiet minute still gets its little movement, so the screen isn’t dead. The tenth change in a busy second gets none, so the screen isn’t lying. Nobody notices the difference, which is exactly the compliment I’d want.

For anything where you’d like a bit of life, separate the value from the decoration. The number itself jumps to the new figure. What animates is something that can’t be wrong: a soft highlight behind it that fades over half a second, say. If the next change arrives before the highlight has faded, the highlight simply restarts, and no one is ever shown a stale number.

For anything continuous, the dot on the map, the needle on a gauge, don’t travel to the new value; be at the new value, with a whisker of smoothing at most. A car’s speedometer needle does this: it follows the speed rather than making a trip to it. We’d build every live dot the same way.

Nothing on the screen should ever be animating toward a value that’s already out of date.

How this goes wrong: say a livestream shows a rolling counter of hearts, digits spinning like an old car’s mileage counter. On a quiet stream it’s charming, and I understand why someone drew it. The moment the stream gets popular, the digits never stop spinning, and a number that’s always in motion is a number nobody can read. The stream is a hit and the counter can’t tell you by how much!

Under the thumb

There’s one updater faster than anything your server sends, and I’d treat it as the strictest case: the person’s own hand. Think about the volume slider on your phone. Your thumb moves, the knob moves, and they’re the same movement; you’re not asking the knob to go somewhere, you’re holding it. Now imagine a slider that eases toward your thumb, always a little behind. You’d say it felt slippery, or heavy, or just wrong, and you’d be right! (It’s a bit like dragging a spoon through honey.)

While a finger is on the screen, the control should be under the finger, full stop, with no animation between the two. Where does motion belong, then? At the moment you let go. Release a slider halfway between two stops and it can settle to the nearer one; release the scrubber on a film and the playhead can catch up to your thumb, because now nothing is waiting on it. It’s the one moment in a drag where the play has paused and the commentator can finish a sentence, and the only moment we’d let a drag animate.

Hold the list still

This one hides in search boxes, and it’s the one I’d check first. Picture typing into a search box that filters a list as you go, and the list re-sorts after every letter, with rows sliding up and down into their new places. Under your fingers it’s a list that’s never still while you’re using it, and reading a moving list is like reading a noticeboard while someone shakes it.

What’s happening is the same sum from earlier. Letters arrive several times a second (nobody types slowly to be kind to the animation), each sort takes a third of a second to play, and so the rows are always mid-slide when the next letter lands. Should the rows ever slide? Nope, not while the typing continues. When the person pauses long enough to look, maybe, and I’d be honest about that “maybe”: most search lists are better with no sliding at all, because you’re looking for a name, not admiring the choreography.

How this goes wrong: say the row you want is third from the top, and by the time your hand gets there another letter has landed and the row has slid to fifth. You tap the wrong one, and the list has taught you not to trust it.

When the play slows, say something

Is the lesson just “less motion”? Not quite, and I’d want to be clear about that. It’s motion at the pace of the thing, which is what the commentator does too: the fast passages get short words, and the penalty gets the long sentence.

Live screens have penalties. The order is confirmed. The payment has gone through. The rider has arrived, and the dot that’s been creeping around the map for twenty minutes stops on your street. Nobody is waiting for the next update, and a longer, warmer piece of motion is exactly right there: the dot can settle, the card can rise, the number can take a breath. Half a second, even a whole one! Disney’s animators put exaggeration on their list of twelve principles and used it on the moment that matters rather than on every frame.

Think of the old split-flap departure boards at railway stations, clattering through letters before settling on the next train. Each flip takes real time, and it’s fine, because departures change every few minutes and the clatter is the point: it tells the whole concourse that something changed. Would anyone build a split-flap speedometer? Of course not. And yet a spinning hearts counter on a livestream is a split-flap speedometer (a beautiful one, which is how it got approved). Match the pace and almost any motion is fine; mismatch it and almost none is.

Cut what can’t keep up

Here’s the part we’d insist on. A live animation that’s right most of the time and a beat behind the rest of the time doesn’t read as “nearly polished.” It reads as broken, because the one time the dot lies is the time you remember. So our standard for anything on a live screen, your map included, is that it keeps up every time: on a slow phone, on a bad connection, in a burst of ten updates at once. If it can’t meet that, we’d take it out and leave the value on its own. A number that’s plainly right beats one that’s beautifully wrong, and I’d ship the plain one.

How do you find out before your customers do? Not in a demo. Here’s an afternoon, as a hypothetical, for the screen in your question:

  1. Slow the connection down on purpose. A browser’s dev tools can pretend you’re on a poor mobile connection (Chrome’s guide to its network panel says where), and a phone can go into a lift.
  2. Spam it. Tap the button that adds to the order twenty times as fast as you can, and see whether the total is readable at any point.
  3. Watch it slowly. The same dev tools have an animations panel that plays motion at a tenth of its speed, the fastest way we know to catch a dot heading somewhere the rider has already left.
  4. Turn motion down and see what you miss. Phones have a setting that asks apps to reduce motion, and websites can respect the same request. Whatever the screen loses when the motion goes was decoration.

Not a flattering afternoon, and I wouldn’t expect to pass it first time (I wouldn’t expect anyone to). But it takes a few hours, and it saves a few months of people quietly not trusting your map!

Back to the commentary box

So, you, with the live screen that looks lovely and feels wrong: nothing in the app needs to get faster. What’s wrong is that you’ve hired a commentator who describes every pass in full sentences, and the game has left them behind.

Give them shorter words. Let the dot be where the rider is, let the total be the total, let the list hold still while someone’s typing, and when the game finally pauses, on the confirmed order, the arrived rider, the paid bill, let them take a breath and say something worth hearing. Will people call the app fast? I think they will, and they’ll be wrong about why, and that’s fine. It is not faster. It’s just never behind.

In one breath: compare the animation’s length with the gap between changes, skip the motion when the changes outrun it, jump to the value and animate only the decoration, keep the control under the finger, hold the list still while someone types, spend the long motion on the slow moments, and cut anything that can’t keep up every time.

That’s all of it. I hope the next person waiting for dinner watches your dot round the corner at the same moment the bike does.

Hope this helps.

Cheers,
— Abraham

Abraham is the founder of Internet Labs and a design engineer. He has worked for Netflix, Meta, Microsoft, Airbnb, Uber, Canal+, and Chanel, and on Stranger Things. He’s on X as @0xOrkward, though he’d rather you went and watched a delivery dot for a minute and asked whether it’s telling the truth.

Next question, anyone? #HeyInternet runs on whatever you send: a sheet that doesn’t feel right under the thumb, what full-stack means when the whole team fits at one table, which AI tools have earned a place on our desks, or the words on a button that nobody taps. Send it to hi@internetlabs.ai and put “Hey Internet” as the subject so we can find it, or tag it #HeyInternet on X. Your name goes in only if you say so.

P.S. The best commentators say the least during the fastest play. There’s a career’s worth of advice about animation in that, and I’ve just spent two thousand words on it.

Details on steroids

An independent AI studio, infinitely crazy about functional, emotional and agentic interfaces on the internet.