I rebuilt my portfolio so it would draw less attention

I've followed Emil Kowalski's work for a good while. If the name doesn't ring a bell, let me introduce him: he's a design engineer at Linear, spent time on Vercel's design team, and is the author of Sonner and Vaul. They're the toast that shows up in the corner of the screen and the drawer that slides up on your phone. Together, the two pass 50 million downloads a week on npm. Without knowing it, you've probably used something he made today.

He also writes, and writes well. Short pieces about the part of the interface nobody can put in a ticket: how a thing looks, how it reacts, why a button makes you want to click it again.

I started thinking about him again while building this portfolio from scratch.

The pattern I wanted to avoid

There's a way of making a portfolio that has become the default: over-production. Scroll that fires an effect, a number that counts itself up, a transition between sections, a custom cursor. It's pretty and it's a lot of work. Except in the end the portfolio becomes the product. You remember the site, not what the person built.

I didn't want that. I wanted the products to show: the flashcards app, the festival site, the things I actually do day to day. The site is the frame, not the painting.

The problem is that "less" is harder to decide than it sounds. That's where a piece by Emil helped me.

The idea

The piece is called You Don't Need Animations, and the argument goes roughly like this: animation isn't decoration, it's communication. If it isn't explaining anything, it's just making you wait.

Sounds obvious written that way. It isn't. Because we don't test animation the way people actually use it. When I'm deciding on a transition, I open it, close it, open it again, think it looks nice, and move on with my life. In that test, almost everything passes. 240ms on a soft curve feels good — once.

Except nobody uses anything once.

Animation doesn't cost you per time it happens. It costs you per time it happens times how many times it happens. Three hundred milliseconds on a screen someone opens once a month? Go for it. The same three hundred on a gesture repeated eighty times in a row becomes twenty-four seconds of waiting, chopped into pieces too small for anyone to complain about. Nobody files a ticket saying "your transition is slow." They just think the app feels heavy and can't explain why.

Where I chose to spend

Here comes the part that looks like a contradiction: there is one slow thing on this site.

The home page has a field of pixels that reacts to your mouse. 650ms after your cursor passes, the glow of the trail is still at a third of what it was. Extremely slow by interface standards.

It gets to be slow because it happens once, right on the first screen, and it isn't in front of anything. But "gets to be slow" isn't "anything goes": it's capped at 24 fps, it freezes on mobile, and it loses opacity near text so it doesn't fight with reading. I picked one place to have some charm and made sure it didn't get in the way of the rest.

And the rest is fast. Every hover on the site lasts 150ms, because hover is the thing that happens most around here.

What stuck

These days, before I write transition, I write a number: how many times is this going to happen? Once or twice, it can have some charm. Twenty or so, only enough to explain itself. Fifty or more, nearly invisible.

The annoying part is that none of this shows. An interface without animation looks less worked-on when you look at the commit. Nobody compliments what doesn't move. But that was exactly what I wanted from this place: to step out of the shop window and let the products talk.

Anyway, go read Emil's site. It's better than this.