Juice it

Game developers have a word for something web developers mostly skip: juice.

A game can work perfectly and still feel dead. You press jump, the character jumps, nothing else happens. Juice is everything you add on top: a little squash when the character lands, a puff of dust, a sound, a screen shake when something explodes. None of it changes how the game works. All of it changes how the game feels.

The best-known description comes from the Experimental Gameplay Project, a Carnegie Mellon student team that included Kyle Gabler, who later co-created World of Goo. From their 2005 article How to Prototype a Game in Under 7 Days:

"Juice" was our wet little term for constant and bountiful user feedback. A juicy game element will bounce and wiggle and squirt and make a little noise when you touch it.

In 2012 Martin Jonasson and Petri Purho gave a talk called Juice it or lose it. They start with a plain Breakout clone and add one small effect at a time. The rules never change. By the end it's a game you want to keep playing.

We don't do this on the web

Most websites have almost no juice, and for good reasons.

The first is time. Web teams are measured on problems solved. A button that works is shippable. A button that works and gives a satisfying little press is the same ticket plus an afternoon nobody budgeted for. When there's a backlog of real problems, the afternoon goes to the backlog.

The second is that a website isn't a game. People come to read something, buy something or get something done. Animation that makes them wait is worse than no animation. A page that bounces and plays sounds while you try to read it is annoying, not fun.

So the line is narrower than in games. Juice on the web should respond to something you did, finish quickly, and never stand between you and what you came for.

Why I think this changes

With AI doing more of the work, solving the user's problem takes less of the time. The afternoon nobody budgeted for is suddenly cheap. I think we'll start spending it on polish, the way game teams always have, and I think users will notice which sites did.

It also helps that polish is easy to describe and easy to check. "When I copy code, flash the block like Vim does" is a complete spec. You can see in five seconds whether it's right.

Juicing this blog

This blog is styled like a terminal, so its juice should feel like a terminal too. Here's what I added:

• The name types itself. Hover over akdarrah in the top left and it gets retyped, one letter at a time, behind a block cursor.
• Yank flashes the code. When you copy a code block, the block flashes for a moment, the way Neovim highlights yanked text.
• The status bar follows you. The bottom bar already says READ on a post. Click into the comment box and it turns blue and says INSERT. Scroll to the end and the position reads EOF.
• The signal fires. Press the ↯ button at the end of a post and the bolt jolts, throws a few ASCII sparks, and the new count rolls up into place.

Each one responds to something you did, and each is over in under half a second. All of them switch off if your system asks for reduced motion. Two are pure CSS, and the whole change was about 50 lines. No sounds. Sound is where I think the web line really is: nobody wants a blog making noise in an open office.

Try them: the ↯ button is just below this post. None of these change what the blog does. You can read, comment and copy code exactly as before. I just want it to feel like someone was paying attention.