A Cat That Doesn't Perform

In a folder on my machine there is a screenshot of Clippy, kept as a warning.

Microsoft's Office Assistant is the most famous failed character in the history of software, and the usual explanation, that it was annoying, is true but shallow. Plenty of annoying software survives and thrives. What killed Clippy was structural, and the structure is worth naming precisely because it is easy to rebuild by accident.

Clippy's presence was conditional on its performance.

It had to do something to justify occupying the screen. And because the only thing it could do was interrupt, it interrupted. Take away the interruptions and you are left with a paperclip in the corner doing nothing, which, from the perspective of anyone reviewing the feature, looks like a component that is not working.

That is the trap. A character that must demonstrate value will eventually demonstrate it at your expense.

Fig. 1. Macintosh 128K, 1984. The desktop metaphor arrived with a promise that things would stay where you put them. Photograph by Sailko, CC BY 3.0, via Wikimedia Commons.

The other tradition, which almost nobody cites

There is a second lineage for characters in interfaces, and it is the one JEFIELD's cat descends from. It is not the assistant. It is the environment.

Think about the desktop of an operating system from the late eighties or nineties, and specifically about the parts that were not tools. Things inhabited it. They had positions. You put a thing somewhere and it was there later, and the environment did not ask you to confirm, organise, or acknowledge anything about it.

The character-in-the-interface idea, at its best, was never about assistance. It was about inhabitation: the sense that the screen is a place with things in it rather than a surface displaying results.

From that reading I extracted five properties and wrote them into the standard.

Table 1. Five properties of a character that inhabits rather than assists.

Interruptibility turned out to be an implementation constraint

The fifth property looked like a sentiment when I wrote it. It became the most technically consequential line in the document.

An animation that plays back a prepared sequence cannot be interrupted gracefully. You have two options: cut it dead, which looks broken, or let it finish, which makes the person wait for a decoration. Both are failures, and both are what happens when a character is built the ordinary way.

So JEFIELD's cat does not play animations. It follows a rule, continuously, frame by frame, as a pure function of current state.

// Not a timeline. A rule evaluated every frame.

lean      = f(pointer position, cat position)
squash    = f(is pressed, pressure duration)
walk      = f(time, bounds of the rule above the collection)
stillness  = f(time since last arrival)

// There is no "currently playing" state to cancel,
// because there is nothing playing. There is only
// a position, recomputed.

// Not a timeline. A rule evaluated every frame.

lean      = f(pointer position, cat position)
squash    = f(is pressed, pressure duration)
walk      = f(time, bounds of the rule above the collection)
stillness  = f(time since last arrival)

// There is no "currently playing" state to cancel,
// because there is nothing playing. There is only
// a position, recomputed.

// Not a timeline. A rule evaluated every frame.

lean      = f(pointer position, cat position)
squash    = f(is pressed, pressure duration)
walk      = f(time, bounds of the rule above the collection)
stillness  = f(time since last arrival)

// There is no "currently playing" state to cancel,
// because there is nothing playing. There is only
// a position, recomputed.

The consequence is that there is never a moment where the cat is mid-something and your click has to wait behind it. Interruptibility is not handled. It is structurally impossible to violate.

This is a pattern I have started looking for elsewhere. The best way to guarantee a property is usually not to enforce it but to choose a representation in which violating it cannot be expressed.

What the cat is forbidden to do

Written down, so the rules survive my enthusiasm:

• It never reads what you wrote. This is verified two separate ways in the test suite, because it is exactly the sort of promise that rots quietly when someone adds a helpful feature eighteen months later.

• It is never a status indicator. Not for sync, not for saving, not for network state. The moment a character becomes a spinner it stops being a character and becomes a progress bar with a face, and the person watching learns to read it for information rather than presence.

• It never expresses an emotion the record does not support. No manufactured loneliness after an absence. No celebration of a streak, because there are no streaks.

• It never takes a consequential action on your behalf. Capability is not authority. A component that can act is not thereby permitted to act, and the gap between those two is where most of the recent unpleasantness in software lives.

The honest status: confounded

Here is where I have to be careful, because this is the part where a founder normally reports a success.

On the current evidence I cannot prove the cat earns its place. In my own logs it is by an enormous margin the most-touched thing in the product, several hundred interactions, around two thirds of every event ever recorded. And I have to discount essentially all of it, because I was the person building the cat during that same window. A maker prodding his own toy is not a user forming a habit, and treating those two as the same data is how projects convince themselves they have traction.

So the cat sits in the scorecard as confounded: not proven, not disproven, and explicitly not to be cited as a success in any report.

It stays for a reason that has nothing to do with metrics. It stays because it is honest. It makes no promise the system cannot keep. And there is a free experiment already instrumented and waiting: once I stop building, do the pokes continue? That costs nothing, requires no new code, and will answer the question better than any survey could, because it observes a behaviour rather than asking about one.

The design principle underneath

Apple's reintroduced design principles put the relevant test under Delight, and it is the most self-aware sentence on that page: "don't let pursuit of delight for its own sake get in the way of your product's core purpose."

The test that implies is not is this charming. It is does this charm sit between the person and what they came for.

The cat passes only because it occupies no path. Nothing must be dismissed to get past it. You can work for an hour without registering it and lose nothing. The moment it requires an interaction, it has failed, and the correct response would be removal rather than refinement.

A character that has to perform will eventually perform at your expense. I would rather have one that is simply there.

Sources

• Macintosh 128K, 1984. Photograph by Sailko, CC BY 3.0, via Wikimedia Commons. commons.wikimedia.org/wiki/File:Computer_macintosh_128k,_1984_(all_about_Apple_onlus).jpg

• Apple. Design principles, Human Interface Guidelines. Reintroduced 8 June 2026. developer.apple.com/design/human-interface-guidelines/design-principles

Related reading

• Observed, Derived, Interpreted

• Persistence Is Not Continuity

• The Grasshopper Was Already There

• The Power of Specific Numbers

More from the Moc Mallen Studio journal