Buttons Are Evil

This page concerns itself with button widgets used in the standard way. Non-standard buttons used in palettes are not considered at this point.

Buttons access operations, procedures, commands or functions. In other words, buttons provide access to verbs. Or alternatively, a button is a verb. So let's take a look at those buttons that are littered like so many rat droppings in the typical application.

A button has a certain solidity. Does this make any sense? No. Only BusinessObjects, things which are objects in the user's mind, should have physicality. These objects are called nouns and verbs are not nouns! The most important thing to accept is that humans do extremely poorly when they can't distinguish between verbs and nouns, or when they're forced to use primarily verbs, doubly so in Western countries. It's the reason why functional programming isn't that popular.

(Languages based on nouns are easier to process than those based on verbs. They're more common globally. Expecting people who were raised on the former to handle an interface based on the latter is idiocy.)

A button also has a specific location. Does this make any sense? No. After all, verbs operate on nouns (things like documents, text, songs or movies) and the nouns are over there. So how does it make sense for something over here to have any effect over something that's over there? The terms for this kind of behaviour include: non-locality, action at a distance, and most descriptively, magic. It's completely aphysical behaviour. And given that buttons ostensibly exist to lend physicality to UIs, it follows that buttons are a perversion.

Real-world buttons are often aPhysical. The keys on your keyboard and mouse are all buttons that affect something intangible over-there. The buttons on a mobile phone, the buttons on your TV remote. Real-world buttons can have variable functionality, operate at a distance, and are movable.

There are two more aspects to buttons, both of which are evil.

Buttons are frequently associated with icons, and of course IconsAreEvil?. Icons are itty bitty useless images that provide strictly less, less learnable, less useful, and less accessible information than context menu actions distinguished by 1) text, 2) colour, and 3) standard slots.

Then there're buttons that set modes. Setting aside the fact that button feedback (whether it's up/down/lit/unlit) is redundant at best and provides an excuse to not provide better feedback at worst, there remains the fact that ModesAreEvil?. And in the rare cases where modes are acceptable (eg, to set fonts) it's still the case that button feedback is intrinsically poor. A bold or italicized cursor provides infinitely better associated feedback than the position of some abstract on/off switch half a screen away.

If you don't have buttons, what's to replace them? WheelMenus.

-- RichardKulisz

Complete nonsense. I use buttons inside EclipseIde and other applications as well (but EclipseIde is one that I use the most). Quite a few of them. For debug, run, unit tests. Some are a combination between Button and Menu. Think about "business objects"? Sure. But non-dumb users also think about processes, and buttons are an ideal metaphor to associate with starting or stopping a process. By the time it takes to navigate to the proper "business object" and find the right process in the context menu, I can hit the "Run" button a thousand times. Maybe a CategoryRichardKulisz? should be in order. -- CostinCozianu

Buttons are not my favorite UI mechanism, but they're sometimes serviceable, and it's certainly possible to place them so that they're visually associated with objects that they act on. What I'm curious about, especially since Richard has brought it up before in other contexts, is what support there is for this anti-verb, pro-noun argument, and whether the argument really applies in such a strict, comprehensive manner to the kinds of things that people do with computers. -- DanMuller

Calling it anti-verb, pro-noun, does my position a disservice. I'm for complete segregation of verbs and nouns. You know, separate but equal? :) WheelMenus take care of verbs, so it's not like they go away. -- RK

OK. I was thinking back to some exchanges we had regarding CLOS, in which you seemed to extol objects as the preferred organizing principle of thinking -- and some of the above smacks of this, too. I have been, and remain, skeptical of such general claims. But I'll take you at your word and expect you to treat verbs with equal respect. :) Now, how would your UI styles deal with verbs that require more than one object? I sense the myopia of the most common object model (to which Smalltalk adheres, along with most OO languages) creeping into the UI. Since this single-mindedness does not seem to be a characteristic of natural languages or thinking, this seems inappropriate. Think back on our discussions about CLOS and multi-methods for a contrasting model.

I'll warn you up front that there's probably a limit to how far I'll be able to contribute substantively to this discussion. User interfaces are not an area that I've studied or thought about deeply. I usually avoid UI implementation work, except to occasionally express an opinion based on my personal likes and dislikes of particular program features. (I've always found that there's plenty for me to do in other parts of systems I've worked on.) -- DanM

Actions operate on an environment which includes:

You need access to the hand in order to change, for example, your footprint. (The radius of nodes within which other users see you, assuming the nodes are writable by you.) But these actions are reflexive actions upon the hand, so they're in the hand-reflexive menu, as opposed to the action and navigation menus.

Sort blocks take two arguments, but they're also used continuously, so they're really one argument actions with the sort block as the sole argument. They're in the navigation menu.

Every meaningful general action I've come up with takes either 0 (implicit), 1 or 2 arguments. The ones that take 2 arguments operate on the selection stack.

So we're really talking about special-purpose object actions, ones that operate on an object's contents. And I haven't spent any serious time on that; it's too wide a topic.

I'm actually gathering the suspicion that DirectManipulation precludes anything like multimethods. The human locus of attention is too narrow to handle several objects simultaneously.

The only thing that doesn't fit into the above framework is object naming, which seems to require a soft dialog of some sort. But that's a topic which only now occurred to me. -- RK


"The most important thing to accept is that humans do extremely poorly when they can't distinguish between verbs and nouns."

How true. This page is a good example, since it fails to distinguish between buttons that are the ability to do something, which is therefore a noun, and the doing itself, which is a verb.


See also WimpIsBroken, WindowsAreEvil, IconsAreEvil?, MenusAreEvil and PointersAreEvil.

CategoryInteractionDesign CategoryUserInterface


EditText of this page (last edited March 24, 2006) or FindPage with title or text search