Up and Down the Ladder of Abstraction

Up and Down the Ladder of Abstraction

A Systematic Approach to Interactive Visualization

Bret Victor / October, 2011

"In science, if you know what you are doing, you should not be doing it. In engineering, if you do not know what you are doing, you should not be doing it. Of course, you seldom, if ever, see either pure state."

—Richard Hamming, The Art of Doing Science and Engineering

How can we design systems when we don't know what we're doing?

The most exciting engineering challenges lie on the boundary of theory and the unknown . Not so unknown that they're hopeless, but without enough theory to predict the results of our decisions. Systems at this boundary often rely on emergent behavior — high-level effects that arise indirectly from low-level interactions.

When designing at this boundary, the challenge lies not in constructing the system, but in understanding it. In the absence of theory, we must develop an intuition to guide our decisions. The design process is thus one of exploration and discovery.

How do we explore? If you move to a new city, you might learn the territory by walking around. Or you might peruse a map. But far more effective than either is both together — a street-level experience with higher-level guidance.

Likewise, the most powerful way to gain insight into a system is by moving between levels of abstraction. Many designers do this instinctively. But it's easy to get stuck on the ground, experiencing concrete systems with no higher-level view. It's also easy to get stuck in the clouds, working entirely with abstract equations or aggregate statistics.

This interactive essay presents the ladder of abstraction , a technique for thinking explicitly about these levels, so a designer can move among them consciously and confidently.

I believe that an essential skill of the modern system designer will be using the interactive medium to move fluidly around the ladder of abstraction.

Standing on Concrete

We'll start with an in-depth example — designing the control system for a simple car simulation . Our goal is to write a set of rules that allows the car to navigate roads, such as the one to the right.

What inputs does our system have? Let's say that our car has a very simple sensor which can only detect three states: the car is on the road, left of the road, or right of the road.

How do we design the rules for the car to follow? We don't understand this system well enough to predict its behavior, so we need to prototype. We start with the simplest possible design, and thoroughly explore it. As we develop a feel for how it works, we'll get ideas for improvements. We try an idea, explore again, and keep iterating. Our design and our intuition should grow side-by-side.

The simplest possible rule here might be to turn right when off-road to the left, and turn left when off-road to the right.

To the right is an algorithm which encodes this strategy.

At each step:

Move forward 1 pixel.

If left of the road, turn right by °.

If right of the road, turn left by °.

Click Tap to the right to find out how this algorithm behaves.

I suspect we all know someone whose driving is accurately modeled by this algorithm.

Controlling Time

Above, we watched the system evolve in real time. A realtime view is useful for getting a direct, visceral sense of a system's behavior, especially for systems that are meant to be experienced by humans, such as visual effects.

However, real time is also quite limiting. Imagine a film editor who has to watch the entire film from the beginning with every edit, and cannot even pause or rewind. That would be absurd. Yet, most of our interactive systems are designed in this fashion.

To understand a system, we must be able to explore it. To explore, we must be able to move freely, under our own control.

Mouse over Drag the slider at the right to control time explicitly. Notice that we can easily simulate realtime playback simply by moving the mouse over dragging the slider at a steady rate. But we also have the ability to quickly skim over it, or stop at interesting events and examine them carefully, or quickly jump between interesting events and compare them.

A designer needs direct, interactive control over the independent variables of the system. We must not be slaves to real time.

At each step:

Move forward 1 pixel.

If left of the road, turn right by °.

If right of the road, turn left by °.

Controlling the Algorithm

In this algorithm, the car turns at a rate of 2° per step. Why 2°? Because we needed to choose some value, and with no understanding of the system's behavior yet, we made a wild guess.

Wild guesses are okay! We need to start somewhere. But we also need a way to easily and fluidly adjust our guesses, see the consequences, and develop a sense for how they affect the behavior.

The turning rate should be a parameter of our algorithm. And like time, we must be able to...