The Silent Cat Principle of UI Design

• By Matt Stephens
• February 16, 2006

Yesterday's blog entry was about the mysteriously unfunny Garfield cartoon, and how a small tweak (obliterating all of Garfield's "too-obvious-to-be-funny" thought bubbles) transformed it, engaging the brain and magically making some of the cartoon strips quite amusing (not to say surreal).

My blog entry then segued (if lurching around a series of hairpin S-bends can be called a segue) into a brief discussion about applying the same "less is more" principle to learning materials (books, e-learning CDs/websites etc).

Let's call this the "silent cat principle", in honor of the unfunny cartoon that the same principle magically made funny.

Question is, could the same principle also be applied to UI design?

At first glance, it would seem not... The vast majority of application UIs are rather unhelpful already. The occasional tooltip or label beneath a cryptic icon seems to be the cutting-edge of UI helpfulness these days.

In fact, it's possible to pinpoint some quite specific ways in which modern UIs actively confound their users:

Modal interfaces are perhaps the epitome of unhelpfulness - where a button or keyboard action does something different depending on what state the UI is in.

Then again, there's also the "magic wall" interface, where menu options are disabled - without any hint as to how they may be switched on. I call it the "magic wall" because it's as if an invisible wall sits in front of the UI, preventing you from clicking certain parts of it.

So UIs already tax the user's brain, but not in the right way: cryptic icons, modal interfaces and magic walls are more like illogical puzzles in adventure games -- no fun at all. The result is software that puts the user off instead of getting their brain more involved.

So applying the "silent cat principle" to existing UIs would be a bad, bad thing. By actively removing even more of the helpful elements that help a user to navigate an illogical UI, you'd basically make the software even more difficult to use.

Of course, this is all making the assumption that software is even supposed to be teaching the user -- because that's when the silent cat principle really comes into its own. When the user is learning, you really want them to "think, already!" - to switch on their brain, in effect.

In the days when all software had a printed manual, it was assumed that you learn to use the software someplace else (e.g. ask someone how to print a document, or *even* (gasp) read the manual); and only then do you use the software to do something.

But that said, why can’t the software pro-actively teach you as it goes along? It worked pretty well for Kai, back in his day.

In the interests of “saying less to engage the reader’s brain” (and also because my dinner’s ready), I’ll leave that as a cliffhanger question... more in the next day or two.