# Editor tabs: configuration in tabs, design on the canvas Date: 2026-08-31 Branch: `feat/editor-tabs-restructure` Status: awaiting review ## The problem The editor has four tabs — סוג טופס, עיצוב, שדות, אוטומציות — and they are cut along two different lines at once. Three of them name a *kind of thing* (a form type, a design, a field), while the work an author actually does moves between them constantly: pick a template in עיצוב, add a field in שדות, colour that field back in עיצוב, set where the form appears in סוג טופס. Two specific complaints follow from that: - **סוג טופס holds too much.** It carries how the form shows itself, its step configuration, and its whole submission setup. Only the first is a *type*. - **עיצוב is a tab for something that is already on screen.** Styling a field means finding that field in a list in one tab and its colours in another, when the field is right there in the canvas being pointed at. ## The shape Three tabs, and design reached by clicking the thing being designed. ``` ┌─────────┬────────┬──────────┐ │סוג טופס │הגדרות │אוטומציות │ └─────────┴────────┴──────────┘ ``` | Tab | Holds | |---|---| | **סוג טופס** | מיקום (inline / popup), טריגר, תדירות, ניתן לסגירה, היכן מופיע (URLs) | | **הגדרות** | טופס בשלבים, שליחה (endpoint, method, on success, on error, custom values) | | **אוטומציות** | unchanged — mailing list, redirect, email | Neither fields nor design has a tab. Both are reached from the canvas: - **Click a field** → that field's panel takes over the settings column: its label, its rules (required, מוסתר, key) and its design (font, colour, size, alignment, width). - **Click the card**, meaning card background rather than any field → the card's panel takes over the same column: פריסה, כיוון, פינות, רקע, גודל, תמונה, גופנים וצבעים, כפתור פתיחה, and beneath those the outline of every field the form holds. The tabs are then purely configuration, and everything visual is edited by pointing at it. ## Why this split `סוג טופס` answers "what kind of form is this, and when does a visitor meet it" — placement, trigger, frequency, dismissibility, and which pages it lives on all answer that. `הגדרות` answers "how is it wired up" — steps and submission. That is the separation the client asked for, and it moves the two heaviest blocks out of a tab that had become a catch-all. Card design goes on the canvas rather than into a tab for the same reason field design does: it is the one thing in the editor whose result is already visible next to the control, and the canvas already carries card handles for width, height, padding and corner radius. Putting the rest beside them keeps one way to do one job. ## Adding a field `+ הוספה` opens the field picker **as a panel in the settings column**, not as the popover it hangs under the toolbar today. This is not cosmetic. A row in the picker is draggable onto the canvas, and `FieldPicker.tsx:141` explains why only one variant allows it: *"The panel sits beside the canvas, so a row can be carried over to it. The popover under the toolbar's Add button hangs over the canvas itself, where a drag would start on top of the thing it is aiming at, so it stays a menu."* So `drag` is wired to the panel variant and switched off for the popover. That drag is not a convenience. The same file calls it *"the only way to say 'this field goes there', and the only way to put two fields on one row from here."* With the fields tab gone, the panel variant loses its only caller, and adding through the toolbar popover would have quietly taken both capabilities away. Moving Add into the column keeps them, and makes the column consistent: every takeover in it — picker, field, card — works the same way. Nothing then uses `variant='popover'`, so that variant and the `AddMenu` wrapper around it go, and `FieldPicker` loses a branch instead of gaining one. ## What already exists Four pieces of this are moves rather than builds: - **Click-to-edit a field.** `EditingView.tsx:110` already selects an item and switches tabs when the canvas reports a click, and `PopupContent.tsx:1466` already reports which item was clicked. - **The card's own click.** That same handler reports `null` for a click on empty card space, described in its comment as clearing the selection. That is exactly the signal "the card itself was clicked", so card design needs no renderer change — only a different reading of a message already being sent. - **The takeover.** `FontBrowser` already takes over the full height of the settings column, locking that column's scroll and anchoring itself to the top, with a back chevron and a done button. The field and card panels use the same mechanism rather than a new one. - **The panel itself.** `ContentItemsEditor` is already a three-state column — the picker, the selected item's settings, or otherwise the outline of what the form holds, swapped with a slide. The field panel and the picker panel are that component relocated, not new work. What the restructure adds is a fourth state for the card, and a rule about which state a click selects. ## Components | Component | Becomes | |---|---| | `SettingsEditor` | Splits. The תצוגה group stays as `סוג טופס`; steps and submission move to a new `הגדרות`. | | `DesignEditor` | Stops being a tab. Its four groups become the card panel's contents. | | `ContentItemsEditor` | Splits. The per-item editor becomes the field panel; the list and its step switcher are dealt with below. | | `EditingView` | Loses two tab entries, gains a panel state: none, a field id, or the card. | | `AutomationsSection` | Unchanged. | ## What the field list was doing The list carried five jobs, and all five survive the tab going away: | Job | After | |---|---| | Open a field's settings | Click it in the canvas | | Reorder | Drag in the canvas (`dragSort`, already there) | | Delete | The item's own canvas toolbar, already there | | Add | `+ הוספה`, now opening the picker panel | | See every field at once | The outline, in the card panel | The fifth is the one that nearly went. Pointing is a poor way to find a field scrolled out of a tall card, or one faded to 0.4 because it is private, and the canvas is the only place left to point. Keeping the outline costs almost nothing — it is already `ContentItemsEditor`'s third state — so it stays. It lives in the card panel because the card *is* the form: a panel about the whole card listing what the whole card contains needs no explaining, and it is one click from anywhere rather than behind a tab. It keeps the list's own affordances, so an item can still be reordered and removed from it, which is what makes it an alternative to pointing rather than a picture of the form. ## Steps `טופס בשלבים` configuration moves to `הגדרות`, but *switching* which step the canvas shows is a canvas concern, not a settings one: an author editing step 2's fields cannot be sent to another tab to get there. The step switcher therefore moves to the canvas toolbar, beside `+ הוספה`, and only appears when a form has more than one step. ## Navigation - Opening a panel remembers which tab was showing. The back chevron returns to it, so clicking a field from `הגדרות` and pressing back lands on `הגדרות`. - Clicking a different field while a field panel is open switches the panel rather than closing and reopening it. - Esc closes the panel, matching the font browser. - Clicking the canvas outside the card closes the panel. That is a new handler in the builder's canvas area; the renderer's own handler never fires there. - Switching tabs closes any open panel — a tab is a deliberate move away. ## Accessibility - The panel is a labelled region with focus moved to its heading on open, and focus returned to nothing in particular on close, since the trigger was a click on a canvas element that is still there. - The canvas already exposes items as clickable; card background needs a role and a name so a keyboard user can reach card design at all. Today card design is reachable through a tab, and this removes that route — so the card gains a keyboard-focusable affordance rather than losing the capability. ## Non-goals - No change to the schema. This is entirely an editor information-architecture change; the JSON a host gets is identical. - No change to `אוטומציות`. - No change to the renderer beyond what the canvas already reports. - No visual redesign of the controls themselves — they move, they do not change. ## Risks 1. **Discoverability of card design.** A tab is visible; a click target is not. Mitigation: the card panel is what opens when nothing else is selected, so the default state of the column after opening a form still shows it. 2. **The card panel doing two jobs.** Design plus the field outline is a lot in one panel, and the outline is the part an author reaches for more often. It goes below the design groups and inside its own collapsible group, so the panel opens on design and the outline is one scroll or one click away rather than competing for the top. 3. **Two click targets close together.** A card with little padding leaves a thin strip of card background between fields; clicking it opens card design when a field was meant. Mitigation: card design opens from the card's own padding and background, and the item hit areas already extend to their grid cell. 4. **Muscle memory.** Anyone using the current four tabs has to relearn. This is a client-requested change, so it is accepted rather than mitigated. ## Testing - The tab list is three entries, in order, with the right ids. - `סוג טופס` renders the תצוגה controls and not submission; `הגדרות` renders submission and steps and not תצוגה. - A canvas click carrying an item id opens the field panel for that id. - A canvas click carrying `null` opens the card panel. - Back returns to the tab that was showing when the panel opened. - Switching tabs closes an open panel. - The step switcher appears only above one step. Pure functions get node tests as usual; the panel-state machine is worth extracting from `EditingView` precisely so it can be tested without a DOM.