On Bret Victor's Magic Ink

There’s an incredible amount of astonishing, illuminating, and important information in Bret Victor’s 2006 Magic Ink paper. Over the course of some 26 000 words, Bret paints for us the current anachronistic state of software design (or lack thereof), why interaction is considered hazardous, and how little thought is put into how a person interacts with software.

He then offers a different perspective, a way of viewing the majority of software as a graphic design problem, and how that might be implemented.

Throughout the paper, he discusses and builds a conceptual framework for how true software design could be performed, and what a system built around this might be like.

Merlin had it easy—raising Stonehenge was a mere engineering challenge. He slung some weighty stones, to be sure, but their placement had only to please a subterranean audience whose interest in the matter was rapidly decomposing. The dead are notoriously unpicky.

Today’s software magicians carry a burden heavier than 13-foot monoliths—communication with the living. They often approach this challenge like Geppetto’s fairy—attempting to instill the spark of life into a mechanical contraption, to create a Real Boy. Instead, their vivified creations often resemble those of Frankenstein—helpless, unhelpful, maddeningly stupid, and prone to accidental destruction.

This is a software crisis, and it isn’t news. For decades, the usability pundits have devoted vim and vitriol to a crusade against frustrating interfaces. Reasoning that the cure for unfriendly software is to make software friendlier, they have rallied under the banner of “interaction design,” spreading the gospel of friendly, usable interactivity to all who would listen.

Yet, software has remained frustrating, and as the importance of software to society has grown, so too has the crisis. The crusade marches on, with believers rarely questioning the sacred premise—that software must be interactive in the first place. That software is meant to be “used.”

I suggest that the root of the software crisis is an identity crisis—an unclear understanding of what the medium actually is, and what it’s for. Perhaps the spark of life is misdirected magic.

Bret argues the majority of the time, we’re better off not interacting with software, because interaction is mechanical, and instead what we want is to solve an information problem. Engineers have defaulted to the mechanical because we:

  1. Are accustomed to it and can do so deftly, and
  2. Are solving entirely wrong problems. Our software isn’t answering what the user is asking.

Bret elaborates:

Much current software fulfilling these needs presents mechanical metaphors and objects to manipulate, but this is deceiving. People using this software do not care about these artificial objects; they care about seeing information and understanding choices—manipulating a model in their heads.

For example, consider calendar or datebook software. Many current designs center around manipulating a database of “appointments,” but is this really what a calendar is for? To me, it is about combining, correlating, and visualizing a vast collection of information. I want to understand what I have planned for tonight, what my friends have planned, what’s going on downtown, what’s showing when at the movie theater, how late the pizza place is open, and which days they are closed. I want to see my pattern of working late before milestones, and how that extrapolates to future milestones. I want to see how all of this information interrelates, make connections, and ultimately make a decision about what to do when. Entering a dentist appointment is just a tedious minor detail, and would even be unnecessary if the software could figure it out from my dentist’s confirmation email. My goal in using calendar software to ask and answer questions about what to do when, compare my options, and come to a decision.

There are countless other paragraphs I’d love to pull from the paper, but you’d really be better suited to read it yourself. Though the paper is lengthy, it’s extremely well-written. Bret explores concepts fully without belabouring his argument.

It took me about five lengthy sessions to digest the essay (which is par for the course of a Victor essay) but it was worth every second. And, the paper reads exceptionally well in Instapaper on an iPad.

The ideas presented in this paper are challenging, both to an Engineer living in 2012 who’s been trained with paradigms from 1984, and to an Engineer who sees how daunting some of these challenges might be to implement. But this Engineer sees that as an important challenge, as a way to move the state of the art forever forward into a realm of new possibilities. Bret’s epilogue, a quote from Richard Hamming sums it up well:

In the early days, I was solving one problem after another after another; a fair number were successful and there were a few failures. I went home one Friday after finishing a problem, and curiously enough I wasn’t happy; I was depressed. I could see life being a long sequence of one problem after another after another. After quite a while of thinking I decided, “No, I should be in the mass production of a variable product. I should be concerned with all of next year’s problems, not just the one in front of my face.” By changing the question I still got the same kind of results or better, but I changed things and did important work. I attacked the major problem—How do I conquer machines and do all of next year’s problems when I don’t know what they are going to be? How do I prepare for it? How do I do this one so I’ll be on top of it? How do I obey Newton’s rule? He said, “If I have seen further than others, it is because I’ve stood on the shoulders of giants.” These days we stand on each other’s feet!

You should do your job in such a fashion that others can build on top of it, so they will indeed say, “Yes, I’ve stood on so and so’s shoulders and I saw further.” The essence of science is cumulative. By changing a problem slightly you can often do great work rather than merely good work. Instead of attacking isolated problems, I made the resolution that I would never again solve an isolated problem except as characteristic of a class.

Speed of Light