Whyday August 19

Where Whimsy Belongs

The spirit the day celebrates was whimsical in a specific way: cartoon foxes in a programming manual, a framework whose tagline advertised that it was full of gags, error messages that were jokes. It worked, and it worked so well that people have been trying to reproduce it in products ever since, usually badly.

Badly is worth understanding, because the failure is not a matter of taste. There is a fairly reliable line, and it has nothing to do with how funny the joke is.

When a team tests this kind of practice during paid work, the 7-minute payroll rule provides one concrete reference for how time and activity can be recorded around the experiment.

The line

Whimsy belongs where the user is not trying to accomplish anything urgent, and where they cannot be harmed by a delay.

That is the whole rule. Everything below is an application of it.

The reason the poignant guide could be relentlessly strange is that its reader had chosen to spend an afternoon learning something for pleasure. Nobody was reading it at two in the morning trying to work out why the payment failed. The stakes were zero and the time was voluntary, which is the only condition under which an unexpected digression is a gift rather than an obstruction.

For broader programming and making context related to this topic, openFrameworks is an independent reference worth comparing with the material here.

Where it works

Empty states. The user has nothing yet, is not blocked, and has a moment. This is the single best place for personality in any product, and it is almost always wasted on a grey box saying "No items."

Onboarding, in small doses. Voluntary, exploratory, low stakes.

Documentation. Deeply underrated, and the guide is the standing proof. A person reading docs is trying to learn, and learning is exactly the activity where a strange example is more memorable than a bland one. foo and bar have taught nobody anything. This is where the guide's actual technique lives — interleave something genuinely unexpected and let curiosity carry the reader through the necessary boring parts.

Long waits you cannot shorten. If something honestly takes ninety seconds, entertaining the person is a kindness. If it takes two seconds, animating a mascot to fill the time is theft.

Anything the user found rather than needed. Easter eggs, --help footers, the credits screen. Optional depth rewards curiosity without taxing anyone who is in a hurry.

Where it does not

Errors. The strongest case and the most frequently violated. Someone hitting an error is already frustrated, and a jokey error message tells them the people who built this find their problem amusing. Worse, jokes displace information: "Oops! Something went wrong 🙈" is not funnier than a message that says what went wrong, it is just less useful.

If you want personality in errors, put it in the tone — plain, human, apologetic, non-robotic — and put the entire budget into being specific about what happened and what to do next.

Money, health, safety, security, legal. Anywhere being wrong costs the user something real. Confirmation dialogues for destructive actions. Anything a person will read while frightened.

Anything a person does fifty times a day. A joke read once is charming. Read on every save, it is an obstruction with a smile on it. Frequency is the underrated variable here: whimsy has a half-life measured in exposures.

Accessibility surfaces. Decorative flourishes that a screen reader announces, animations that trigger motion sensitivity, mascots that push the actual content below the fold. If the playful thing degrades the experience for people who navigate differently, it is not playful, it is exclusionary. Anything decorative should be aria-hidden and should respect a reduced-motion preference.

Why the bad version is so common

Because it is imitating the surface.

What made the guide work was not that it contained jokes. It was that the jokes were doing structural work — holding the reader's attention through a subject that is genuinely tedious in the middle, and demonstrating that the author was enjoying themselves, which is contagious. The strangeness was load-bearing.

Product whimsy usually inverts this. The joke is applied to a surface that was already working, to make a company seem approachable. It carries no load. And because it carries no load, it is pure cost the moment the user is in a hurry — which, in a product, they usually are.

The test: if you removed the playful element, would anything get worse other than the vibe? If the answer is no, and the user is ever in a hurry, remove it.

The honest tension

There is a real argument on the other side, and this site's whole premise concedes it: software made only from justified decisions is worse software, and delight is not a rounding error. A product with no personality at all is forgettable, and forgettable has a cost that does not appear in any metric.

So the position is not "no whimsy in products." It is that whimsy is a real design element with a real cost, deployed where the user has slack and withdrawn where they do not — rather than a personality layer sprayed evenly over everything.

And on August 19, none of this applies, because the thing you are making tonight has no users. Put the foxes wherever you like.

The short version