Skip to content

Prototyping Engine

rbiswas5888 edited this page Oct 23, 2026 · 1 revision

Prototyping Engine

Goal

Provide an approachable prototype workflow for simple click-throughs while supporting complex, realistic interactions for advanced designers. Prototype behavior should be defined as structured data and interpreted by a runtime, not implemented as ad hoc UI callbacks tied to individual editor components.

Core concepts

  • Flow: a connected experience with one or more starting points.
  • Node/screen: a design frame or supported runtime destination.
  • Interaction: a trigger, action, target, and optional condition/transition configuration.
  • Runtime state: variables, navigation history, overlay stack, scroll state, and mock data.
  • Player: the environment where the prototype is experienced.
  • Diagnostics: graph, target, variable, expression, and runtime issues.
  • Scenario test: a repeatable sequence of actions and expected outcomes.

Interaction model

Triggers may include supported forms such as click/tap, hover, press, drag, keyboard input, timer, or variable change. Actions may include navigation, opening or closing an overlay, back navigation, scrolling to a target, setting a variable, conditional branching, or opening a URL. The actual supported trigger/action list must be maintained as a versioned capability contract.

Each interaction should have explicit source, trigger, action, destination/target where applicable, conditions, and transition configuration.

Make prototyping easy to start

  • A selected layer exposes a clear Add interaction action.
  • Start with a small guided flow: choose trigger → choose action → choose destination or value → preview.
  • Show sensible defaults and progressively reveal advanced controls.
  • Provide an obvious play/preview action and a way to return to editing without losing selection.
  • Show connected-flow indicators on canvas and in a flow overview.
  • Warn about missing destinations, unreachable screens, conflicting triggers, and unsupported runtime behavior.
  • Keep interaction settings in a contextual inspector with clear labels and inline validation.

Advanced prototype capabilities

Where implemented, the runtime may support:

  • State variables and typed values
  • Expressions and conditional branches
  • Mock data and data-driven content
  • Overlay stacks and nested modal contexts
  • Fixed and sticky elements
  • Nested scrolling and scroll-to behavior
  • Transition animations, easing, delay, and supported spring behavior
  • Responsive device viewport preview
  • Back/forward navigation history
  • Time-travel debugging and event inspection
  • Scenario tests and flow coverage
  • Runtime diagnostics and reproducible bug reports

These are planned capabilities unless confirmed by implementation and tests.

Canonical prototype model

A prototype should reference stable document node IDs and store interaction definitions separately from transient player state. A runtime session may track:

  • Active flow and current screen
  • Navigation history
  • Variable values
  • Open overlays
  • Scroll positions
  • Active timers and transitions
  • Event trace and diagnostics

The runtime must not mutate the design document merely because a user clicks through a prototype. Editing interaction definitions is a document mutation; playing a prototype is a runtime session.

Animation contract

Animations should define a supported transition type, duration, easing, direction or parameters, and any delay. The player must provide predictable interruption and completion behavior. Honor reduced-motion preferences and avoid leaving the runtime in a half-transitioned state after cancellation or navigation.

Realistic player

The player should provide device/viewport selection, scaling, navigation controls where useful, restart, and a clear exit back to the editor. The runtime should use the same layout semantics as the design/preview system where possible, so behavior does not diverge silently.

Testing and diagnostics

Test both individual interactions and complete user journeys. Include valid and invalid destinations, missing variables, condition branches, overlay dismissal, nested scrolling, navigation history, animation interruption, viewport changes, and runtime errors.

Compiler/export diagnostics must identify prototype features that cannot be represented in the target output rather than silently dropping them.

Clone this wiki locally