JEF · UBIQUITY INTERVIEW WITH JEF RASKIN
Editorial Notice: This page is editorial commentary about Jef Raskin's work at raskincenter.org. We do not claim authorship of, or rights to, Raskin's writings — his estate retains all such rights.
Ubiquity Interview with Jef Raskin

This page covers a Ubiquity magazine interview with Jef Raskin, which originally appeared in ACM’s Ubiquity; the earlier raskincenter.org site also referenced it. The interview covered the arc of his career, his thinking on interface design, and his views on where computing was headed.

Background: Who Is Jef Raskin?

Jef Raskin joined Apple Computer in 1978 and within a year was writing internal memos proposing what would become the Macintosh project. He named it. He hired its first engineers. He articulated its design philosophy: a computer so easy to use that people who had never touched a computer could use it without instruction.

By the time the Mac shipped in 1984, Raskin had left Apple, pushed out by the same energy that eventually made the project famous. He spent the following years working on information appliances at Canon, where he designed the Canon Cat, and then establishing the Raskin Center for Humane Interfaces, where he built Archy and wrote The Humane Interface.

The Ubiquity interview captures him in mid-career reflection, explaining his ideas to an audience that was beginning to take them seriously.

On the Macintosh

Raskin was clear-eyed about the Macintosh: he was proud of originating it and critical of what it became. The machine that shipped in 1984 violated several of his core principles. It had modes — notably the difference between modal and modeless dialog boxes, the behavior of different tools in the paint program, and the conceptual distinction between the desktop and open applications that confused novice users.

The price point he had specified — under $1000, ideally much less — was not achieved. The Mac shipped at $2495. Raskin thought this priced out the very users the computer was supposed to serve. He had imagined an appliance; he got a premium product.

These criticisms were not dismissals. He acknowledged that Jobs and the Mac team built something historically significant. His point was that significance and correctness are different things — that a product can be influential precisely because it moved things in the right direction while still falling short of the destination.

On Modes

The interview’s most substantive section covers modes — Raskin’s central preoccupation. His definition was careful: a mode is a state in which the same user action produces a different result than it would in another state. Not different results from different actions — that is ordinary functionality. Different results from the same action, depending on state the user may or may not be aware of.

Raskin offered the example of vi, the Unix text editor, which has separate insert and command modes. In command mode, pressing “i” enters insert mode. In insert mode, pressing “i” inserts the letter i. Same key, two completely different behaviors. The error this creates is predictable: a user types a command thinking they are in command mode, and instead inserts characters into their document.

He extended the argument beyond text editors to graphical interfaces: dialog boxes that block all other input create a mode. The difference between clicking to select an object and clicking to activate it can be a mode. The difference between how the mouse behaves over a menu versus a document is a mode.

His position was not that modes should be eliminated by brute force, but that designers should take mode creation seriously as a harm that requires justification. The default should be modeless design. Modes should be introduced only when there is no good alternative, and when introduced, should be as visible and obvious as possible.

On the Canon Cat

The Canon Cat (1987) was Raskin’s most complete implementation of his ideas before Archy. It was a dedicated word processor — not a general-purpose computer — with a built-in keyboard, a small screen, and no application model. You turned it on and you were in your document. There was one document space. You navigated it using the LEAP keys.

LEAP allowed you to search for any text string instantly. Holding the LEAP key while typing characters jumped to the nearest match. This single mechanism replaced the entire apparatus of menus, dialog boxes, and file browsers. Commands were accessed through LEAP. Files were found through LEAP. Everything was found through LEAP.

Raskin described the Cat’s reception: many users, especially secretaries who had never used a computer before, adapted to it quickly and found it comfortable. Users who had previously used conventional word processors sometimes found the LEAP model disorienting — they kept looking for the menus and found them absent. This confirmed something Raskin had long suspected: the difficulty of learning interfaces is partly the difficulty of unlearning previous interfaces.

The Cat was discontinued after a few months. The decision was corporate, not market-driven — Canon’s consumer division absorbed the project from the professional division that had developed it, and decided not to continue. Raskin never received a good explanation. He moved on.

On What Interfaces Should Be

Raskin’s ideal interface was one that users would not notice while using it. The interface should be transparent — not visually, but cognitively. The user should be able to work on their content without devoting conscious attention to the mechanics of the interface.

He cited the example of reading and writing with pen and paper. An experienced writer does not think about how to hold the pen, does not consciously decide to move the hand, does not attend to the mechanics of letter formation. The tool is invisible. The writing is what matters.

Most computer interfaces, he argued, were nowhere near this transparency. They demanded continuous conscious attention — to find menu items, to remember keyboard shortcuts, to track which mode the system was in, to interpret error messages, to decide how to answer confirmation dialogs. This overhead was treated as normal. Raskin thought it was a massive, ongoing design failure.

On the Future

At the time of the interview, Raskin was most optimistic about the possibility of computing becoming genuinely learnable. He distinguished between an interface being easy to start using (low initial learning curve) and being easy to master (good total learning curve). These are often in tension. Interface design had, in his view, consistently prioritized the first at the expense of the second.

His preferred model was a system that was learnable in the sense that it had consistent underlying principles. Once you understood the principles, you could deduce how the system worked in any situation. This was different from a system that was easy to start using because each operation was independently simple — the kind of simplicity that doesn’t compound into capability.

He pointed to LEAP as an example of the latter kind of learnability. LEAP is a single principle applied consistently everywhere. Once learned, it gives the user access to everything. It is not easier to learn than a menu, initially. But it scales better, and it leaves the user knowing something general rather than a collection of specific cases.

This page is part of the Jef Raskin Reference, providing editorial commentary on the published works of the creator of the Macintosh project at Apple.