Skip to content

Design Engine and Interaction Model

rbiswas5888 edited this page Oct 23, 2026 · 1 revision

Design Engine and Interaction Model

Purpose

The Design Engine is the authoritative editable design domain. It provides predictable object creation, selection, transforms, layout, styling, components, and document mutations. The interaction specification is inspired by established professional editors while retaining DesignForge’s own visual identity.

Workspace anatomy

  • Application header: project name, save status, menus, mode navigation, preview/play, export and command access.
  • Left panel: Pages, Layers, Assets/Components and optional flow or design-system navigation.
  • Canvas: document-space scene graph, frames, objects, rulers, guides, grids, selection handles, snap lines and contextual overlays.
  • Right inspector: context-sensitive Design, Prototype, Inspect/Code, Export and other supported properties.
  • Tool dock: select, frame, shapes, pen/vector, text, hand/pan, comments and other implemented tools.
  • Status bar: coordinates, zoom, snapping/grid state, diagnostics and local/online status where supported.

Panels should resize and collapse without changing document geometry. Workspace layout preferences should persist independently of the design document.

Canonical document rules

Every design node should have a stable ID, type, name, parent relationship, ordering, geometry, and supported properties. The document model must represent editable semantics; a screenshot or flattened image is not an adequate substitute for editable structure.

Typical node types include pages, sections, frames, groups, components, component sets, instances, text, shapes, vectors, images, connectors, and supported boolean operations.

Section, frame, and group semantics

  • A Section is a page-level organizer. It can contain eligible content but does not impose layout or clipping on its children.
  • A Frame has its own bounds and may support clipping, constraints, layout, grids, and prototype settings.
  • A Group derives its bounds from children and does not itself provide frame layout or clipping semantics.
  • A frame may be independent on a page, inside a section, or nested within another frame.
  • A section cannot be nested inside a frame or another section.
  • Reparenting preserves visual position by converting coordinates, except where layout rules intentionally reposition the object.
  • Invalid hierarchy drops must be rejected before commit and must not show misleading drop targets.

These constraints belong in domain validation, not just in the Layers UI.

Selection and layer synchronization

Canvas selection and layer-tree selection must be two-way synchronized. Selecting a layer reveals and selects its canvas object; selecting an object selects its layer. Hover highlighting must not accidentally change selection.

Support single and multiple selection, marquee selection, parent/child navigation, hidden/locked state, inline rename, reorder, reparent, duplicate, delete, and z-order changes. Tree drag-and-drop should clearly distinguish insertion before/after a sibling from nesting inside a container.

Geometry and canvas

The canvas is a viewport into document space, not the document itself. Pan, zoom, fit-to-screen, zoom-to-selection and 100% zoom must not modify object coordinates.

Use a consistent transform model and preserve subpixel precision. Selection overlays should be rendered in screen space so handles remain usable at different zoom levels. Hit-testing, clipping, z-order, and visible rendering must agree.

Snapping and layout

  • Snap to relevant edges, centers, frame boundaries, grids, and compatible guides.
  • Display smart guides and spacing measurements during movement.
  • Keep snapping deterministic and allow supported modifier-key overrides.
  • Resolve auto layout, constraints, grid behavior, and responsive sizing through a shared layout contract.
  • Prevent contradictory layout settings or report them clearly.
  • Resizing a panel must never resize document objects.

Inspector behavior

The right inspector changes according to selection count, object type, editing mode, and supported capabilities.

  • No selection: page/canvas properties, variables, guides, and page export where supported.
  • Single selection: geometry, appearance, typography, image/vector settings, layout, component properties, and export settings as applicable.
  • Multiple selection: common values, mixed-value indicators, bulk changes, alignment, distribution and grouping actions.
  • Prototype mode: triggers, actions, destinations, animations, overlays and flow settings.
  • Inspect/Code mode: read-only implementation details, tokens, geometry, component metadata and copy/export actions.

Inputs should support precise numeric entry and appropriate scrubbing. Enter commits, Escape cancels, invalid values are rejected or normalized with feedback, and batch edits are one undoable transaction.

Command and undo contract

Every document mutation passes through one command/transaction engine. It must support validation, atomic updates, undo/redo, grouped gestures, event emission, and recovery where practical. Canvas gestures, property edits, imports, and approved AI changes must converge on the same pipeline.

Keyboard and accessibility

Use one platform-aware shortcut registry. macOS conventions use Command/Option; Windows and Linux use Ctrl/Alt where appropriate. Do not fire editor shortcuts while the user is typing into a text field. Provide discoverable shortcut help, visible focus states, keyboard-accessible controls, meaningful labels, and reduced-motion support.

Performance

Use viewport culling, incremental rendering, indexed hit testing, and virtualized layer trees where appropriate. Profile representative documents and record results. A target such as 60 FPS should be treated as a measured acceptance goal, not a blanket guarantee.

Clone this wiki locally