Tech Visualizer

Tech Visualizer

Create stunning, interactive visualizations that turn complex technical concepts into intuitive, explorable experiences. Every visualization should make the viewer think "now I finally get it."

When to Read Reference Files

Before building, read the appropriate reference:

• references/patterns.md — Visualization component patterns, layout strategies, and interaction blueprints. Always read this first.

Design Philosophy

The "Aha Moment" Principle

Every visualization must have a clear aha moment — the single interaction or animation that makes the concept click. Identify it before writing any code.

Examples:

• HMAC-SHA: Seeing the inner and outer padding XOR with the key, then watching data flow through the two hash rounds
• AES-CBC: Watching the XOR chain where each block's ciphertext feeds into the next block's encryption — showing WHY changing one plaintext block cascades
• ORB keypoints: Seeing the FAST corner detector sweep across an image, lighting up detected corners, then watching BRIEF descriptors form as binary comparison patterns

Visual Identity

Every visualization should feel like a premium interactive textbook illustration, not a generic flowchart. Think: 3Blue1Brown meets an interactive data dashboard.

Core aesthetic principles:

• Dark theme by default with vibrant, high-contrast accent colors for data flow
• Monospace fonts for data/hex values, clean sans-serif for labels
• Purposeful animation — every motion represents actual data transformation
• Depth through layering — use subtle shadows, glassmorphism, or gradients to separate conceptual layers (e.g., application layer vs transport layer)
• Color encodes meaning — establish a color legend early: input data, keys, intermediate state, output. Keep it consistent throughout

Output Format Decision

Choose based on complexity:

When in doubt, use React — it handles state management for interactive controls more cleanly.

Building a Visualization

Step 1: Decompose the Concept

Break the technical concept into stages that can be individually visualized:

Concept → [ Stage 1 ] → [ Stage 2 ] → ... → [ Stage N ]
                ↓              ↓                    ↓
           Visual repr    Visual repr          Visual repr

Each stage should have a clear input/output shown visually, transform data in a way that can be animated, and connect to the previous stage with a visible data flow line.

Step 2: Design the Interaction Model

Layer these interaction types (use ALL that apply):

1. Step-by-step controls: Play/pause, step forward/back, speed slider. This is the primary navigation. Use a prominent step indicator (e.g., "Step 3 of 7: XOR with round key").

2. Live input fields: Let users type their own plaintext, key, URL, etc. The entire visualization should reactively update. Use debounced inputs to avoid jank.

3. Hover/click inspection: Hovering over any data block, wire, or intermediate value should show a tooltip or panel with the raw data, hex representation, or explanation. Clicking can "pin" the inspection panel.

4. Side-by-side comparison: When the concept has variants (ECB vs CBC, HTTP/1.1 vs HTTP/2), show them simultaneously with synchronized step controls.

Step 3: Implement with Polish

Read references/patterns.md for detailed layout templates, animation patterns, and data representation strategies for each concept category.

Key principles:

• Top-to-bottom or left-to-right flow mirroring the algorithm's mental model
• Staggered reveals: Animate data blocks appearing 30-50ms apart
• Active element highlighting: Pulse/glow for current, dim for completed, base opacity for upcoming
• Data flow lines: Animate SVG paths with stroke-dashoffset for "drawing" effects
• Transition duration: 300-500ms for state changes, 150ms for hover effects

Step 4: Add Context & Learning

• Step descriptions: Each step must have a 1-2 sentence plain-English explanation visible alongside the visualization (not just in tooltips)
• "Why does this matter?" callouts: At key stages, add a subtle info box explaining the security/performance/correctness implication
• Edge case demonstrations: Add buttons like "What if the key is all zeros?" or "What happens with identical plaintext blocks?" that demonstrate important properties

Step 5: Responsive & Accessible

• Works at 768px+ width (optimized for desktop, functional on tablet)
• aria-label on interactive elements
• Keyboard navigation for step controls (arrow keys)
• Color is not the only differentiator (use shape/pattern too)

Quality Checklist

Before delivering, verify:

• Dark theme with consistent color coding throughout
• Step-by-step controls (forward, back, play/pause, reset)
• At least one live input field that reactively updates
• Hover inspection on data elements
• Step descriptions visible and accurate
• Smooth animations (no layout shifts or flicker)
• Color legend present
• The "aha moment" is clearly delivered
• Google Fonts loaded for typography
• No hardcoded magic numbers without comments

Anti-Patterns to Avoid

• ❌ Static flowcharts with no interactivity
• ❌ Walls of text explaining the algorithm — the visualization IS the explanation
• ❌ Generic bootstrap/material UI appearance
• ❌ Tooltips as the only information pathway — key details should be always visible
• ❌ Animations that don't map to real data transformations
• ❌ Light theme with muted pastels (dark + vibrant is the default)
• ❌ Skipping the decomposition step — always plan stages before coding