Across 7 audit stories on the LitJS Flow Designer canvas, three underlying patterns recur. Each section below shows the current implementation next to the proposed standard. Hover the examples to feel the difference.
Tip: hover (and tab) into the examples below. The tooltip and button behavior is only visible on interaction.
Buttons across the canvas are custom-built rather than the shared component that maps to the Horizon library. Because nothing enforces the standard, each surface drifts a little differently. Below are three places where this shows up.
Current — looks disabled at rest
Icons sit at 30% opacity at rest. Affordance is only discoverable on hover — fails on touch, bad for keyboard navigation. Tap target is ~20×20, below WCAG 2.5.8 minimum.
Proposed — Horizon icon button
Full opacity at rest — clearly interactive. Larger tap target (28×28). Consistent destructive treatment via the shared component. Themed tooltip on hover and focus.
Both delete buttons use a red icon, but underneath they're completely different implementations. The node toolbar trash is a custom hand-rolled button that paints its own red hover background. The variable menu trash uses a DaisyUI button — same red icon, but the hover background is DaisyUI's default neutral gray. Two surfaces, same destructive action, two different button systems. Both deviate from a single Horizon destructive button. (Hover each trash to see the hover-background difference.)
Current · Node toolbar
Three gray siblings, one red trash. Why is delete singled out and nothing else?
Current · Variable menu
Variable menu uses a DaisyUI button — red icon, but the hover background is DaisyUI's default gray. Underneath: an entirely different implementation than the node toolbar.
Proposed · One rule, applied everywhere
Option A (shown): treat delete identically to other actions. Or Option B: keep an intentional destructive treatment, but define it once and apply it everywhere. Either way, the shared component owns the decision.
The destructive primary button is currently rendered as an outline red button in multiple places — the Deactivate Flow button in the flow header and the Delete button in the delete confirmation modal both share this treatment. Neither matches a Horizon destructive button. The proposed fix is the Horizon soft red filled destructive variant, applied to both surfaces (and any other destructive-primary action on the canvas).
Current — outline red (Deactivate Flow modal shown)
Are you sure you want to deactivate the flow?
Your flow will not run even if the trigger conditions are met. Any executions for this flow that are in progress will continue running.
Don't show me this again
Outline red button — transparent fill, red border, red text. Used here (Deactivate Flow modal), in the flow-header Deactivate button, and in the Delete confirmation modal. None of these match a Horizon destructive button.
Proposed — Horizon soft red filled
Are you sure you want to deactivate the flow?
Your flow will not run even if the trigger conditions are met. Any executions for this flow that are in progress will continue running.
Don't show me this again
One Horizon destructive button, applied everywhere. Swapping the component fixes the Deactivate header button, the Deactivate modal, the Delete confirmation modal, and every other destructive-primary action in one place.
The node action toolbar uses the native HTML title attribute, which renders as a light OS-styled rectangle after a ~1.5s delay and is invisible to keyboard and touch. The rest of the canvas uses the DaisyUI tooltip component — a dark themed bubble with an arrow, instant on hover.
Current — native title
Hover and wait. OS-styled rectangle, no arrow, slow, unstyleable, not focus-accessible. Inconsistent with the rest of the canvas.
Proposed — DaisyUI tooltip
Hover or tab in. Themed bubble with arrow, instant, focus-accessible. Matches every other tooltip on the canvas.
Step reorder uses green for a valid drop target. Variable reorder uses blue for the same action. Two different semantic colors used for the same neutral interaction across two surfaces.
Underneath the inconsistency is a category error: a reorder indicator isn't a success state. Green carries semantic weight on the platform — it means "success" or "positive outcome" (status badges, success toasts, valid form states). Using it on a drop indicator implies the user has "gotten it right," when really they're just being shown where the item will land. Blue has the same problem — typically reserved for info or links, used here as an action marker.
The right color is the brand primary teal — not because teal means success, but because primary is the platform's value-neutral interaction color. It says "this is a platform interaction in progress" without claiming the user succeeded or failed. Green stays reserved for actual success states; blue stays reserved for info and links. The reorder indicator inherits the same primary already used canvas-wide for affordance.
Current — green for steps, blue for variables
Two semantic colors (green, blue) used for the same neutral interaction across two surfaces. Both borrow meaning from elsewhere in the platform's color language.
Proposed — primary teal everywhere (brand interaction color)
One canvas-wide rule: primary teal for valid (neutral interaction), destructive token for invalid. Green stays reserved for actual success states; blue stays reserved for info / links. Applied to drag-and-drop steps, variable reordering, and any future reorder surface.