Widgets of the Week

Archive Notice: This page is part of the Jef Raskin historical archive, preserved for its academic and historical significance.

An unpublished essay by Jef Raskin

Software releases have a problem that product managers rarely discuss and marketing departments actively encourage: each new version of an application tends to have more interface elements than the previous one. More buttons. More panels. More toolbar icons. More menu items. More preference settings. More options dialogs with more tabs containing more checkboxes.

This proliferation is presented as progress. In Raskin’s analysis, it is frequently the opposite.

A widget — in Raskin’s use, any visible interface element that users interact with or must process visually — costs something. The cost is not financial. It is cognitive.

Every widget on screen must be processed by the user’s visual system, even if the user has no interest in it. The eye sweeps across the toolbar and evaluates each icon: is this the one I need? No. Is this one? No. This evaluation happens quickly and below full conscious attention, but it happens. It takes time, and it uses cognitive resources.

This is Raskin’s version of Fitts’s law applied not to motor tasks but to visual search. A toolbar with twenty icons takes longer to search than a toolbar with five. A menu with thirty items takes longer than a menu with ten. Every added widget degrades the performance of every other widget by increasing the search time and the visual noise.

The conventional response to this problem is to organize widgets into groups, to separate toolbars by function, to put rarely-used items in submenus. These are mitigations, not solutions. They acknowledge the problem and add more structure to manage it. The underlying question — why are all these widgets here? — goes unasked.

Why Widgets Accumulate

Software interfaces accumulate widgets because the incentives for adding a widget are immediate and visible, while the costs are diffuse and invisible.

Adding a button for a new feature takes a few hours of engineering time and produces something demonstrable: here is the button, here is the feature, here is the screenshot for the press release. The people who asked for the feature see it and are satisfied. The product manager can point to it as evidence of progress.

The cognitive cost — the marginal increase in interface noise, the slight additional difficulty every user will experience searching for the controls they need, the learning curve increment imposed on every new user who must now process one more element — falls on millions of users who will never connect their experience to this specific decision. No one will file a bug report saying “the toolbar is 2% more cluttered than last version.” The cost is real. It is simply not visible to the people making the decision.

Raskin observed this pattern across decades of software development and concluded that it was structural. Without a measurement framework for interface costs, and without organizational processes for retiring features as well as adding them, the accumulation would continue. And it has.

The Canonical Counter-Example: LEAP

The Canon Cat, which Raskin designed at Canon in the mid-1980s, had no toolbar. It had almost no visible controls at all beyond the keyboard. The keyboard had a small number of special keys, including the LEAP keys.

LEAP replaced, by Raskin’s estimate, more than fifty menu items and toolbar buttons that a comparable word processor of the era would have included. Any piece of text could be found by holding LEAP and typing characters. Any command could be executed through the same mechanism. Navigation, search, command execution — all handled by one consistent mechanism, learned once, applied everywhere.

The Cat’s interface was, in widget terms, extraordinarily sparse. Whether this sparseness was attractive or alienating depended partly on prior computing experience. Users who had never used a word processor found it approachable. Users who had extensive experience with menus found the absence of menus disorienting. This is the familiar paradox of interface improvement: people who have habituated to a flawed interface often prefer it to a better one, because they have already paid the learning cost of the flawed version.

Raskin described what he saw as a trap that mature software products fall into. Early versions are lean — there are few features, few interface elements, and the interface is relatively coherent. As the product matures, features are added, each justified on its own merits. The interface accommodates each addition. At some point, the weight of accumulated features makes the interface difficult for new users to learn and difficult for experienced users to use efficiently.

The response is usually a redesign — which strips out some of the accumulated complexity and reorganizes the rest. The stripped-down redesign alienates experienced users who have habituated to the old interface and resent the disruption. The cycle begins again.

Raskin’s argument was that this cycle is not inevitable. It can be broken by taking interface costs seriously at the point of feature addition — requiring that new widgets be justified against a measurable interface budget, and retiring old features when new ones replace them.

This requires organizational will that most software companies lack. Features are added by teams with an interest in their features. Features are removed by no one, because retirement has no champion. The asymmetry produces accumulation.

Implications

This essay, though unpublished, reads as a companion to Raskin’s broader critique of interface design practice. Its specific target is not any one product but the incentive structure that produces widget proliferation industry-wide.

The argument has not become less relevant. Modern software — desktop, web, and mobile — continues to accumulate controls in each release. The frameworks differ (ribbon toolbars replaced icon toolbars; hamburger menus emerged in mobile; floating action buttons briefly appeared and faded). The pattern remains: each version has more than the last, and the costs of addition are rarely weighed against the costs of accumulation.

This page is part of the Jef Raskin Archive, preserving the unpublished writings of the creator of the Macintosh project at Apple.

The Raskin Center