Programmer and UI design writer Niki Tonsky has put a sharp name to a problem users feel before they can describe it: interfaces that look fine at rest, then fall apart during the frames in between.
In a post titled “Every Frame Perfect,” Tonsky borrows a stated Wayland design goal and applies it to application UI. Wayland’s concern is the display stack: controlling presentation so a compositor does not show broken or half-finished frames. Tonsky’s argument is broader. If someone captures an app at any instant, the team behind it should be able to account for what appears on screen.
That is a stricter bar than checking the first and last state of an animation. Tonsky says users infer software quality from the interface because they cannot inspect the code. A polished UI is not proof of a solid implementation, but he treats it as a reasonable signal that developers spent time on the product rather than shipping whatever the toolkit happened to produce.
What “perfect” means in practice
Tonsky lists several failure modes that make an interface feel careless: white flashes between screens, partially loaded content, layout shifts during loading, inconsistent status messages and imprecise animations. His example of inconsistency is straightforward: one part of an app saying an update is available while another still says it is checking for updates.
The post spends most of its time on animation because that is where many apps hide their mess. Tonsky argues that designers and engineers often validate only the start and end positions. The transition itself can contain frames where elements overlap oddly, move from different origins or imply a relationship that is not actually present.
He points to Safari as one example. In the case he shows, placeholder text moves from the center while the cursor animates from the left. Tonsky says the mismatch creates the impression that the two components were not designed together, which can make the interface feel less trustworthy.
Apple’s Photos app gets a similar critique. Tonsky says that when switching between Crop and Adjust modes, the picture snaps into place immediately while the crop border animates. His complaint is not that the transition is catastrophic. It is that the animation suggests something has subtly changed when, by his account, the UI should act like a precise instrument rather than an ornamental toy.
He also calls out transitions meant to clarify motion that instead make it harder to follow, including an example centered on a magnifying glass, and a YouTube animation where a rectangle does not move cleanly between two positions. Tonsky speculates that the YouTube case may come from earlier DOM architecture choices, but he is careful to present that as a guess. The visible result, he says, is still a bad frame.
The tooling is not an excuse
The useful part of Tonsky’s argument is that it refuses to let implementation details launder bad UI. Browser layout constraints, platform widgets and animation frameworks can all produce awkward intermediate states. Users do not experience the dependency graph. They see the frame on screen.
That makes the screenshot test a practical review method. Pause the transition. Slow it down. Capture the middle. If the team cannot explain why every visible element is where it is, the animation is doing work nobody designed.
Tonsky closes with another jab at Apple, citing an “unprovoked” zoom animation in Preview. The larger point is consistent: application quality is visible not only in the clean mockup or the final resting state, but in the messy temporal space between them.
This story draws on original reporting from tonsky.me.