Why We Rebuilt the Builder (Again)

Rebuilding a tool that's in active use is uncomfortable. Users have learned workflows. Mental models are established. A redesign disrupts all of that, and it had better be worth it. We've redesigned the builder twice now. Here's why we did it both times.

Version One: Inline Everything

The first builder was inline. Click a component to edit it, and controls appeared directly on the component. Click a button label to type a new one. Click a column to configure it. Everything happened in place.

This was elegant in demos. It felt direct and intuitive — you're touching the thing you're changing. But in practice, it created problems.

Inline controls limited how much configuration was accessible. A text input works fine for a label. A date picker works for a default value. But configuring a complex filter, defining a relation, or managing a list of columns needs more space than the component itself affords. We found ourselves designing controls that were perpetually cramped.

Nested components were harder still. Click a component inside a column inside a panel inside a tab — what selected? What did the controls apply to? The inline model worked cleanly for flat pages and broke down on complex ones.

Version Two: Sidebar for Properties

The second version introduced a sidebar for configuration. Select a component; its properties appear in a dedicated panel. This gave us the space we needed. Controls could be detailed without being cramped.

But the sidebar created its own problem: the page wasn't really the canvas anymore. The sidebar took up a third of the screen. As we added more configuration options, the sidebar scrolled. Switching between components required navigating the sidebar back to the top.

We were hiding the page to show the controls for the page. That's backwards.

What the Canvas Model Gets Right

The current redesign starts from a different premise: the page is the canvas, and it should be as large as possible. The sidebar is a panel that appears only when needed and stays compact.

The canvas shows the page at full fidelity. What you see in the builder is what users will see. The sidebar holds the controls for whatever is selected, and it's designed to be concise — the most important settings are at the top, advanced options are in expandable sections.

This balance — maximum visibility of the result, minimal intrusion from the controls — took time to find. We had to be ruthless about which controls surface prominently and which stay collapsed by default.

What We Learned

Every version of the builder taught us something about what people actually do when they build pages. They're not exploring the configuration space abstractly — they're trying to produce a specific page they already have in mind. The builder should accelerate that process, not require learning its own model first.

A builder that shows you the page clearly while making changes is faster to use than one that requires mental translation between controls and results. The canvas model is the best implementation of that principle we've found.

We'll rebuild again if we find a better one.