Powers of Ten as Interface Pattern

In 1977, Charles and Ray Eames made a nine-minute film that starts on a couple picnicking in Chicago and zooms out — one power of ten per ten seconds — until the frame contains the observable universe. Then it zooms back in, past the couple, into the man’s hand, through skin and cells and molecules, down to a single proton.

The film is usually discussed as science education or as visual poetry. It might also be one of the clearest articulations of an interface pattern that barely exists in software.

The pattern

Two dimensions controlled by a single gesture — zoom. As you zoom out, quantity increases and resolution decreases. As you zoom in, quantity decreases and resolution increases. At any given zoom level, you see exactly as much detail as you need, no more and no less.

The information is always the same. The level of detail you’re seeing changes. This is obvious when stated directly, but it’s not how most software works.

Google Maps is the clearest implementation. Zoom out: you see continents, major bodies of water, country boundaries. Zoom in a bit: cities appear, then highways, then local roads. Zoom in further: buildings appear, then addresses, then the shapes of individual structures. The data doesn’t change as you zoom — all of it exists at all times. Your perspective on it does.

The genius of Maps is that you never feel lost. You always know where you are in relation to the whole. Zoom out, and you see your city in the context of your country. Zoom in, and you see your street in the context of your neighborhood. The context is continuous. The thread never breaks.

Most software doesn’t work this way. Most software has discrete views — a list view, a detail view, a dashboard view, a settings view — and you navigate between them with clicks. The mental model is pages, not space. You’re moving through a document, not exploring a territory.

Pages versus space

The page metaphor comes from documents. A book has pages. A website has pages. You click a link, you go to a new page. The back button exists because forward navigation breaks context — you need a way to return to where you were.

This metaphor made sense when websites were mostly text. A page of text is a reasonable unit. You read it, you click to another page, you read that. The discontinuity between pages is acceptable because text is sequential anyway.

But most modern software isn’t text. It’s data — complex, hierarchical, interconnected data. An organizational chart. A codebase. A knowledge graph. A project management system. A social network. These aren’t documents with pages. They’re structures with relationships.

The page metaphor forces these structures into an unnatural form. You see one level at a time. You click to drill down. You click again to drill back up. Each click is a context switch — you lose sight of the whole to see the part, then lose sight of the part to see the whole again.

The spatial metaphor — the Eames approach — treats the data as a continuous territory. You don’t click to a new page; you zoom to a new level. The context is always visible, just at different resolutions. You never lose the thread because the thread is always there.

An experiment with the pattern

A concept for a network state homepage uses the Eames structure explicitly. The design challenge: a homepage that serves two goals — promoting the philosophy of a decentralized community and enabling NFT purchases for various initiatives. The solution: “A universe of digital nodes; adventure in magnitudes.”

Four data entities at four zoom levels:

The layout uses TreeMap visualization with force-directed graph algorithms for node positioning. The user starts zoomed all the way out, seeing archipelagos as large regions of color. Zoom in, and the archipelagos subdivide into islands. Zoom further, and islands reveal their initiatives. Zoom to the deepest level, and you’re looking at individual NFTs with purchase options.

The navigation model mirrors Google Maps. Zoom to increase resolution and detail while decreasing the number of entities shown. Zoom out to decrease resolution while increasing quantity. At every level, you know where you are in relation to the whole. The archipelago you’re exploring is always visible in context.

The description references the Eames film directly: “Inspired by Powers of Ten — each zoom level reveals a more detailed story.”

Why this matters for complex systems

Consider a codebase. A large software project might have thousands of files, organized into hundreds of directories, implementing dozens of modules. The standard way to explore this is a file tree — a hierarchical list that you expand and collapse, one directory at a time.

This works, barely. But it forces you to hold the structure in your head. You expand a directory, see its contents, remember what you’re looking for, expand another directory, compare, collapse, try again. The interface shows you one level at a time. The context is in your memory, not on the screen.

A spatial approach would show the entire codebase as a territory. Zoomed out: major modules as regions. Zoomed in: packages within modules. Further: files within packages. Deepest level: functions within files. At every zoom level, you see the current focus in context — this function, in this file, in this package, in this module, in this codebase.

Some code visualization tools approximate this — code maps, dependency graphs, treemaps of file sizes. But they’re typically separate from the editing experience. You look at the visualization to get oriented, then switch to the editor to work. The spatial view and the page view remain separate.

The Eames pattern suggests they could be unified. The visualization is the navigation. You zoom into the territory until you’re at the level where you can edit. The context never breaks because the context is the interface.

Why it’s rare

Technical difficulty, probably. Rendering continuous zoom smoothly requires either pre-generating every zoom level (expensive in storage) or computing the appropriate level of detail on the fly (expensive in compute). Maps solved this with tile servers — pre-rendered image tiles at multiple zoom levels, fetched on demand. It took years of engineering and massive infrastructure investment.

Most applications can’t justify that investment. A file browser doesn’t need Google’s tile servers. So it falls back to the simpler approach: discrete views, click navigation, broken context.

The compute problem is getting easier. GPUs are faster, browsers are more capable, WebGL makes smooth rendering accessible. But the technical barrier is still real, especially for data that changes frequently. Maps data is relatively static — roads don’t move often. A project management system changes constantly. Keeping a spatial visualization synchronized with changing data is harder than rendering a static tile set.

Conceptual difficulty, also. The discrete-view model maps cleanly to web architecture. Pages have URLs. Database queries return objects. REST endpoints serve resources. The entire mental model of web development assumes you’re building pages, not spaces.

The continuous-zoom model requires thinking about data as a spatial territory with varying resolution. This isn’t how most backends are structured. You’d need an API that returns different levels of detail based on a zoom parameter, aggregating entities at low zoom and expanding them at high zoom. Most data models don’t support this natively. You’d have to build it.

And maybe habit. We’ve been building page-based interfaces for thirty years. The mental model is deeply embedded in how designers and developers think about software. Proposing a spatial alternative feels like proposing a different metaphor for what software is — not a document you read but a place you explore.

Metaphor shifts are hard. They require rethinking tools, patterns, and assumptions. Most of the time, it’s easier to use the existing metaphor even when it doesn’t quite fit. So we build pages when we should build spaces, and we accept the context breaks as the cost of doing business.

Places where it might work

Not everywhere. Some data really is sequential — a blog post, a conversation, a timeline. The page metaphor fits because the data is page-shaped. You don’t need continuous zoom for a document that’s meant to be read from top to bottom.

But hierarchical data seems like an obvious fit. Organizational charts. File systems. Taxonomies. Ontologies. Any data where entities contain other entities, where the whole is made of nested parts. The current approach — expand/collapse trees, drill-down/drill-up navigation — works, but it constantly breaks context. The spatial approach would preserve it.

Network data might fit too, though less obviously. Social graphs. Citation networks. Dependency graphs. These aren’t strictly hierarchical — they have cross-cutting relationships that don’t fit neatly into a tree. But you could still apply the pattern: zoomed out, show clusters; zoomed in, show individual nodes and edges. The challenge is computing the right clustering at each zoom level, which is algorithmically hard but not impossible.

Knowledge management seems particularly promising. A personal wiki, a note-taking system, a second brain. These are often structured as pages with links, which is the document metaphor. But the underlying structure is a graph — notes reference other notes, ideas connect to other ideas. A spatial representation could show the shape of your knowledge: clusters of related ideas, bridges between domains, isolated notes that don’t connect to anything.

The existing tools for this — graph view in Obsidian, the backlink explorer in Roam — gesture toward the pattern without fully implementing it. They show you a static graph at one level of detail. The Eames approach would let you zoom into any cluster, see its internal structure, then zoom back out to see how it relates to everything else.

The Eames insight

The film’s power isn’t the facts it conveys — the scale of the universe, the scale of subatomic particles. The facts are interesting, but they’re available in any astronomy textbook. The power is the continuous journey between them.

The same couple is always at the center. At every zoom level, from 10^25 meters to 10^-16 meters, you can locate the picnic blanket in Chicago. The context never breaks. You never lose the thread. You travel forty-one orders of magnitude, and you always know where home is.

That continuity is the insight worth importing into interface design. Not just “show different levels of detail” — every hierarchical interface does that. The insight is “show them as a continuous space that the user moves through.” The data is the territory. The interface is the lens. Zoom is the only navigation you need.

The back button becomes unnecessary because you never leave. You just change your perspective on where you already are. The breadcrumb trail becomes unnecessary because the context is visible, not just listed. The “you are here” marker becomes unnecessary because here is always the center of the view.

This is how physical space works. You don’t click to enter a room; you walk into it, maintaining awareness of the building around you. You don’t click to read a book on a shelf; you look at the shelf, see the book in context, pull it out. Physical navigation is continuous. Digital navigation is usually discontinuous. The Eames film suggests it doesn’t have to be.

What it would take

New primitives. The page is a primitive in web development — URL routing, component trees, navigation state. A spatial interface needs different primitives. A camera with position and zoom. A viewport that renders what’s visible. Level-of-detail logic that swaps representations based on zoom. Data structures that support multi-resolution queries.

New tools. Design tools assume pages. Figma has frames, which are page-like. A spatial design tool would need something different — a canvas that you design at multiple zoom levels simultaneously, with different content visible at each level.

New patterns. The UX patterns we’ve developed over decades assume click navigation. Breadcrumbs, tabs, back buttons, drill-down lists. These would need to be rethought for continuous navigation. What does a “save” action look like when there are no pages to save? What does “undo” mean when navigation and editing happen in the same spatial context?

It’s a lot. Probably too much for most projects, most of the time. The page metaphor works well enough for most purposes. The switching cost to a new paradigm is high, and the benefits are speculative.

But the pattern exists. The Eames proved it works for understanding the universe. Google proved it works for understanding geography. Someone should try building more software that way — not as a curiosity, but as a serious alternative to the page-based interfaces we’ve accepted as inevitable.

The data is already spatial. The relationships are already structured. The only thing missing is a lens that shows them continuously.